Soong-Build-System

Vor der Veröffentlichung von Android 7.0 nutzte Android GNU-Marke um die Build-Regeln zu beschreiben und auszuführen. Das Make-Build-System weit verbreitet ist, aber im großen Maßstab von Android langsam, fehleranfällig sind nicht skalierbar und schwer zu testen. Die Soong-Build-System bietet die erforderliche Flexibilität für Android-Builds.

Deshalb sollten Plattformentwickler von Make-up-Entwicklern So schnell wie möglich. Senden Sie Fragen an die Android-Entwicklung Google-Gruppe, um Support zu erhalten.

Was ist Soong?

Das Soong-Build-System wurde mit Android 7.0 (Nougat) eingeführt und ersetzt „Make“. Dabei werden die Kati GNU Klontool und Ninja-Build-System erstellen Komponente zur Beschleunigung von Android-Builds.

Weitere Informationen finden Sie in der Android-Build-System für Android-Geräte im Android Open Source Project (AOSP) für allgemeine Anleitung und Systemänderungen für Android.mk-Autoren erstellen , um zu erfahren, welche Änderungen für die Umstellung von Make to Soong erforderlich sind.

Siehe die build-bezogenen Einträge in der Glossar mit Definitionen wichtiger Begriffe und Detaillierte Informationen findest du in den Titel-Referenzdateien.

Vergleich zwischen Make-and-Song

Hier sehen Sie einen Vergleich, bei dem mit Soong einer Soong-Konfigurationsdatei (Blueprint oder .bp)

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 findest du unter Einfache Build-Konfiguration.

Eine Erläuterung 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 das quellenbasierte Gegenstücke. Beispiel: cc_prebuilt_binary Namen foo, wenn bereits eine cc_binary mit diesem Namen vorhanden ist. Dadurch erhalten Sie können Entwickelnde flexibel wählen, welche Version sie in ihre Produkt. Wenn eine Build-Konfiguration beide Versionen enthält, hat das Flag prefer in der vordefinierten Moduldefinition bestimmt, 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, ist die Make-Produktkonfiguration muss einen PRODUCT_SOONG_NAMESPACES-Wert angeben. Das Der Wert sollte eine durch Leerzeichen getrennte Liste von Namespaces sein, die Soong in den Befehl "Make" exportiert. wird mit dem Befehl m erstellt. Nach der Umwandlung von Android in Soong können sich die Details zum Aktivieren von Namespaces ändern.

Soong kann für Module in verschiedenen Verzeichnissen festgelegt werden, denselben Namen haben, solange jedes Modul in einem separaten Namespace deklariert ist. A Namespace kann folgendermaßen deklariert werden:

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

Beachten Sie, dass ein Namespace kein Attribut „name“ hat. ist sein Pfad automatisch als Namen zugewiesen wird.

Jedem Soong-Modul wird basierend auf seiner Position in der Baumstruktur ein Namespace zugewiesen. Es wird davon ausgegangen, dass sich jedes Soong-Modul in dem Namespace befindet, der durch das soong_namespace in einer Android.bp-Datei im aktuellen Verzeichnis gefunden oder dem nächstgelegenen Ancestor-Verzeichnis. Wird kein entsprechendes soong_namespace-Modul gefunden, gibt der wird davon ausgegangen, dass sich das Modul im impliziten Stamm-Namespace befindet.

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

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