Soong-Build-System

Vor Android 7.0 verwendete Android ausschließlich GNU Make, um Build-Regeln zu beschreiben und auszuführen. Das Make-Build-System wird häufig unterstützt und verwendet, aber im großen Maßstab von Android wurde es langsam, fehleranfällig, nicht skalierbar und schwer zu testen. Das Soong-Build-System bietet die erforderliche Flexibilität für Android-Builds.

Aus diesem Grund sollten Plattformentwickler so schnell wie möglich von Make und Soong umstellen. Senden Sie Fragen an die Google-Gruppe android-building, um Support zu erhalten.

Was ist Soong?

Das Soong-Build-System wurde mit Android 7.0 (Nougat) eingeführt und ersetzt „Make“. Dabei werden das Kati-Klontool GNU Make und die Build-Systemkomponente Ninja verwendet, um Android-Builds zu beschleunigen.

Eine allgemeine Anleitung finden Sie in der Beschreibung Android Make Build System im Android Open Source Project (AOSP). Unter Build System Changes for Android.mk Writers finden Sie Informationen zu Änderungen, die für die Anpassung von „Make to Soong“ erforderlich sind.

Definitionen wichtiger Begriffe finden Sie in den build-bezogenen Einträgen im Glossar. Ausführliche Informationen finden Sie in den Soong-Referenzdateien.

Vergleich zwischen Make-and-Song

Hier sehen Sie einen Vergleich, wie die Konfiguration mit Soong in einer Soong-Konfigurationsdatei (Blueprint oder .bp) funktioniert.

Beispiel erstellen

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux

LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src

LOCAL_SRC_FILES := $(call \
     all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)

Beispiel für einen Song

cc_library_shared {
     name: "libxmlrpc++",

     rtti: true,
     cppflags: [
           "-Wall",
           "-Werror",
           "-fexceptions",
     ],
     export_include_dirs: ["src"],
     srcs: ["src/**/*.cpp"],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

Testspezifische Beispiele für die Soong-Konfiguration finden Sie unter Einfache Build-Konfiguration.

Eine Erklärung der Felder in einer Android.bp-Datei finden Sie unter Android.bp-Dateiformat.

Spezielle Module

Einige spezielle Modulgruppen haben besondere Eigenschaften.

Standardmodule

Mit einem Standardmodul können dieselben Eigenschaften in mehreren Modulen wiederholt werden. Beispiel:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

Vordefinierte Module

Bei einigen vordefinierten Modultypen kann ein Modul denselben Namen wie seine quellbasierten Gegenstücke haben. So kann es beispielsweise eine cc_prebuilt_binary namens foo geben, wenn bereits eine cc_binary mit diesem Namen vorhanden ist. So können Entwickler flexibel auswählen, welche Version in ihr Endprodukt aufgenommen werden soll. Wenn eine Build-Konfiguration beide Versionen enthält, bestimmt der Flag-Wert prefer in der vordefinierten Moduldefinition, welche Version Priorität hat. Einige vorgefertigte Module haben Namen, die nicht mit prebuilt beginnen, z. B. android_app_import.

Namespace-Module

Bis Android vollständig von Make-up zu Soong konvertiert wird, muss in der Make-Produktkonfiguration ein PRODUCT_SOONG_NAMESPACES-Wert angegeben sein. Sein Wert sollte eine durch Leerzeichen getrennte Liste von Namespaces sein, die Soong in Make zur Erstellung mit dem Befehl m exportiert. Nachdem die Umwandlung von Android in Soong abgeschlossen ist, können sich die Details zum Aktivieren von Namespaces ändern.

Soong können Module in verschiedenen Verzeichnissen denselben Namen verwenden, solange jedes Modul in einem separaten Namespace deklariert ist. Ein Namespace kann so deklariert werden:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

Beachten Sie, dass ein Namespace kein Namensattribut hat. Sein Pfad wird automatisch als sein Name zugewiesen.

Jedem Soong-Modul wird basierend auf seiner Position in der Baumstruktur ein Namespace zugewiesen. Jedes Soong-Modul befindet sich in dem Namespace, der durch die soong_namespace definiert ist, die sich in einer Android.bp-Datei im aktuellen Verzeichnis oder im nächsten Ancestor-Verzeichnis befindet. Wenn kein entsprechendes soong_namespace-Modul gefunden wird, wird davon ausgegangen, dass sich das Modul im impliziten Stamm-Namespace befindet.

Hier ein Beispiel: Soong versucht, die Abhängigkeit D aufzulösen, die vom Modul M im Namespace N deklariert wurde und die Namespaces I1, I2, I3 importiert...

1. Wenn D dann ein voll qualifizierter Name der Form //namespace:module ist, wird nur der angegebene Namespace nach dem angegebenen Modulnamen gesucht.
2. Andernfalls sucht Soong zuerst nach einem Modul namens D, das im Namespace N deklariert ist.
3. Wenn dieses Modul nicht vorhanden ist, sucht Soong in den Namespaces I1, I2, I3 nach einem Modul mit dem Namen D.
4. Zuletzt sucht Soong im Stamm-Namespace.