Vor Android 7.0 verwendete Android ausschließlich GNU Make, um 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 Google-Gruppe android-building, 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 Ninja-Buildsystemkomponente, 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).
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 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 seine quellebasierten Pendants haben. So kann es beispielsweise eine cc_prebuilt_binary
mit dem Namen foo
geben, wenn bereits eine cc_binary
mit demselben 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, gibt der Flag-Wert prefer
in der Definition des vorgefertigten Moduls an, welche Version Vorrang hat.
Einige vordefinierte Module haben Namen, die nicht mit prebuilt
beginnen, z. B. android_app_import
.
Namespace-Module
Bis Android vollständig von Make zu Soong umgestellt ist, muss in der Make-Produktkonfiguration ein PRODUCT_SOONG_NAMESPACES
-Wert angegeben werden. Sein Wert sollte eine durch Leerzeichen getrennte Liste von Namespaces sein, die Soong nach Make exportiert und mit dem Befehl m
erstellt wird. 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 Struktur ein Namespace zugewiesen.
Jedes Soong-Modul befindet sich im Namespace, der durch den soong_namespace
definiert ist, der in einer Android.bp
-Datei im aktuellen Verzeichnis oder im übergeordneten Verzeichnis gefunden wird. 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.
- Wenn D ein voll qualifizierter Name vom Typ
//namespace:module
ist, wird nur im angegebenen Namespace nach dem angegebenen Modulnamen gesucht. - Andernfalls sucht Soong zuerst nach einem Modul namens D, das im Namespace N deklariert ist.
- Wenn dieses Modul nicht vorhanden ist, sucht Soong in den Namespaces I1, I2, I3 usw. nach einem Modul mit dem Namen „D“.
- Zuletzt sucht Soong im Stamm-Namespace.