Soong-Build-System

Vor der Veröffentlichung von Android 7.0 wurde ausschließlich GNU Make verwendet, um die Build-Regeln zu beschreiben und auszuführen. Das Make-Buildsystem wird weithin unterstützt und verwendet, war aber aufgrund der Größe von Android langsam, fehleranfällig, nicht skalierbar und schwer zu testen. Das Soong-Buildsystem bietet die für Android-Builds erforderliche Flexibilität.

Aus diesem Grund sollten Plattformentwickler so bald wie möglich von Make zu Soong wechseln. Senden Sie Fragen an die Android-Entwicklung Google-Gruppe, um Support zu erhalten.

Was ist Soong?

Das Soong-Build-System wurde in Android 7.0 (Nougat) als Ersatz für Make eingeführt. Es nutzt das GNU-Klontool Kati und die Build-Systemkomponente Ninja, um Android-Builds zu beschleunigen.

Eine allgemeine Anleitung und Informationen zu den Änderungen, die für die Umstellung von Make auf Soong erforderlich sind, finden Sie in der Beschreibung des Android Make-Build-Systems im Android Open Source Project (AOSP).

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 der Make-Konfiguration mit der Soong-Konfiguration in 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)

Soong-Beispiel

cc_library_shared {
     name: "libxmlrpc++",

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

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

Beispiele für testspezifische Soong-Konfigurationen finden Sie 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 einzigartige Merkmale.

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 sein quellenbasierte Gegenstücke. So kann es beispielsweise eine cc_prebuilt_binary mit dem Namen foo geben, wenn bereits eine cc_binary mit demselben 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, gibt der Flag-Wert prefer in der Definition des vorgefertigten Moduls an, welche Version Vorrang 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 Tab "Make" exportiert. wird mit dem Befehl m erstellt. Nach Abschluss der Umstellung von Android auf Soong können sich die Details zur Aktivierung von Namespaces ändern.

Soong ermöglicht es, für Module in verschiedenen Verzeichnissen denselben Namen anzugeben, sofern jedes Modul in einem separaten Namespace deklariert ist. Ein Namespace kann so deklariert werden:

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

Hinweis: Ein Namespace hat keine Name-Eigenschaft. Sein Pfad wird automatisch als Name zugewiesen.

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. Wenn kein solches soong_namespace-Modul gefunden wird, wird davon ausgegangen, dass sich das Modul im impliziten Stamm-Namespace befindet.

Beispiel: Soong versucht, die Abhängigkeit D aufzulösen, die vom Modul M im Namespace N deklariert wurde und die Namespaces I1, I2 und 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 N deklariert ist.
3. Wenn dieses Modul nicht vorhanden ist, sucht Soong in den Namespaces I1, I2, I3 usw. nach einem Modul mit dem Namen „D“.
4. Zuletzt sucht Soong im Stamm-Namespace.