Vor der Android Version 7.0, verwendet Android GNU Make ausschließlich zu beschreiben und führen ihre Build - Regeln. Das Make-Build-System wird weithin unterstützt und verwendet, aber im Umfang von Android wurde es langsam, fehleranfällig, nicht skalierbar und schwer zu testen. Das Soong Build - System bietet die Flexibilität , die für Android aufbaut.
Aus diesem Grund wird von Plattformentwicklern erwartet, dass sie so schnell wie möglich von Make wechseln und Soong übernehmen. Bitte senden Sie Fragen zu der Android-Aufbau Google - Gruppe Unterstützung zu erhalten.
Was ist Soong?
Das Soong Build - System wurde in Android 7.0 (Nougat) eingeführt Fabrikat zu ersetzen. Es nutzt die Kati GNU Make Klonwerkzeug und Ninja - Build - System - Komponente Builds von Android zu beschleunigen.
Sehen Sie sich die Android Make - Build - System Beschreibung im Android Open Source Project (AOSP) für allgemeine Anweisungen und Build - Systemänderungen für Android.mk Writers über Änderungen lernen müssen von Make zu Soong anzupassen.
Siehe die Build-bezogenen Einträge im Glossar für Definitionen von Schlüsselbegriffen und die Soong Referenzdateien für alle Details.
Make-and-Soong-Vergleich
Hier ist ein Vergleich von Make - Konfiguration mit Soong das gleiche in einer Soong - Konfiguration (Blueprint oder das Erledigen .bp
) Datei.
Mach ein Beispiel
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)
Bald Beispiel
cc_library_shared {
name: “libxmlrpc++”,
rtti: true,
cppflags: [
“-Wall”,
“-Werror”,
“-fexceptions”,
],
export_include_dirs: [“src”],
srcs: [“src/**/*.cpp”],
target: {
darwin: {
enabled: false,
},
},
}
Siehe Einfache Build - Konfiguration für testspezifischen Soong Konfigurationsbeispiele.
Android.bp-Dateiformat
Durch Design, Android.bp
sind Dateien einfach. Sie enthalten keine Bedingungen oder Kontrollflussanweisungen; die gesamte Komplexität wird durch in Go geschriebene Build-Logik gehandhabt. Wenn möglich, die Syntax und Semantik von Android.bp
sind Dateien , ähnlich wie Bazel BUILD - Dateien .
Module
Ein Modul in einer Android.bp
Datei beginnt mit einem Modultyp , gefolgt von einer Reihe von Eigenschaften in name: "value",
Format:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Jedes Modul muss einen haben name
- Eigenschaft und der Wert muss für alle eindeutig sein Android.bp
Dateien, mit Ausnahme der name
Eigenschaftswerte in Namensräumen und vorgefertigte Module, die wiederholen kann.
Die srcs
Eigenschaft gibt die Quelldateien verwendet , um das Modul zu bauen, als eine Liste von Strings. Sie können die Ausgabe anderer Module verweisen , die Quelldateien erzeugen, wie genrule
oder filegroup
, indem Sie das Modul Referenz - Syntax ":<module-name>"
.
Eine Liste der gültigen Modultypen und deren Eigenschaften finden Sie in der Soong - Module Referenz .
Typen
Variablen und Eigenschaften sind stark typisiert, wobei Variablen dynamisch auf der ersten Zuweisung basieren und Eigenschaften statisch durch den Modultyp festgelegt werden. Die unterstützten Typen sind:
- Boolesche Werte (
true
oderfalse
) - Ganze Zahlen (
int
) - Strings (
"string"
) - Listen von Zeichenketten (
["string1", "string2"]
) - Karten (
{key1: "value1", key2: ["value2"]}
)
Maps können Werte jeden Typs enthalten, einschließlich verschachtelter Maps. Listen und Karten können nach dem letzten Wert Kommas haben.
Kugeln
Eigenschaften , die eine Liste von Dateien nehmen, wie srcs
können auch glob Muster nehmen. Glob - Muster können die normale UNIX Platzhalter enthalten *
, zum Beispiel *.java
. Glob - Muster können auch ein einzelnes enthalten **
Wildcard als Pfadelement, das entspricht null oder mehr Pfadelemente. Zum Beispiel java/**/*.java
passt sowohl die java/Main.java
und java/com/android/Main.java
Muster.
Variablen
Eine Android.bp
Datei kann auf oberster Ebene Variablenzuweisungen enthalten:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Variablen gelten für den Rest der Datei, in der sie deklariert sind, sowie für alle untergeordneten Blueprint-Dateien. Variablen sind mit einer Ausnahme unveränderlich: sie können mit einem bis angefügt +=
Zuweisung, aber nur , bevor sie verwiesen worden sind.
Kommentare
Android.bp
Dateien können enthalten C-Stil mehrzeilige /* */
und C ++ Stil einzeiligen //
Kommentare.
Betreiber
Strings, Stringlisten und Maps können mit dem Operator + angehängt werden. Ganze Zahlen können bis mit dem summiert +
Operator. Das Anhängen einer Map erzeugt die Vereinigung der Schlüssel in beiden Maps, indem die Werte aller Schlüssel angehängt werden, die in beiden Maps vorhanden sind.
Bedingungen
Soong nicht unterstützt conditionals in Android.bp
Dateien. Stattdessen wird die Komplexität von Buildregeln, die Bedingungen erfordern würden, in Go behandelt, wo High-Level-Sprachfeatures verwendet werden können und implizite Abhängigkeiten, die durch Bedingungen eingeführt werden, verfolgt werden können. Die meisten Bedingungen werden in eine Karteneigenschaft konvertiert, bei der einer der Werte in der Karte ausgewählt und an die Eigenschaften der obersten Ebene angehängt wird.
Um beispielsweise architekturspezifische Dateien zu unterstützen:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Formatierer
Soong enthält eine kanonische Formatierer für Blueprint - Dateien, ähnlich wie gofmt . Rekursiv umformatieren alle Android.bp
Dateien im aktuellen Verzeichnis, führen:
bpfmt -w .
Das kanonische Format umfasst Einrückungen mit vier Leerzeichen, neue Zeilen nach jedem Element einer Liste mit mehreren Elementen und ein abschließendes Komma in Listen und Karten.
Sondermodule
Einige spezielle Modulgruppen haben einzigartige Eigenschaften.
Standardmodule
Ein Standardmodul kann verwendet werden, um dieselben Eigenschaften in mehreren Modulen zu wiederholen. Zum Beispiel:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Vorgefertigte Module
Bei einigen vorgefertigten Modultypen kann ein Modul denselben Namen haben wie seine quellbasierten Gegenstücke. Zum Beispiel kann es sein , cc_prebuilt_binary
namens foo
, wenn es bereits cc_binary
mit dem gleichen Namen. Dies gibt Entwicklern die Flexibilität zu wählen, welche Version sie in ihr Endprodukt aufnehmen möchten. Wenn eine Build - Konfiguration beiden Versionen enthält, die es prefer
, Flag - Wert in der vorgebauten Moduldefinition diktiert , welche Version Priorität hat. Beachten Sie, dass einige vorgefertigte Module Namen haben , die mit nicht starten prebuilt
, wie android_app_import
.
Namespace-Module
Bis Android voll von Make zu Soong umwandelt, muss die Make Produktkonfiguration einen angeben PRODUCT_SOONG_NAMESPACES
Wert. Sein Wert sollte eine durch Leerzeichen getrennte Liste von Namensräumen sein , dass Soong Exporte durch den eingebauten machen zu m
- Befehl. Nachdem die Konvertierung von Android zu Soong abgeschlossen ist, können sich die Details zum Aktivieren von Namespaces ändern.
Soong bietet Modulen in verschiedenen Verzeichnissen die Möglichkeit, denselben Namen anzugeben, solange jedes Modul in einem separaten Namespace deklariert wird. Ein Namespace kann wie folgt deklariert werden:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Beachten Sie, dass ein Namespace keine name-Eigenschaft besitzt; sein Pfad wird automatisch als Name zugewiesen.
Jedem Soong-Modul wird basierend auf seiner Position im Baum ein Namespace zugewiesen. Jede Soong - Modul wird als im Namensraum durch dem definiert sein soong_namespace
in einer gefundenen Android.bp
Datei im aktuellen Verzeichnis oder am nächsten Vorfahren Verzeichnis. Wenn keine solche soong_namespace
Modul gefunden wird, wird das Modul in der impliziten Stammnamespace angesehen werden.
Hier ist ein Beispiel: Soong versucht, die von Modul M deklarierte Abhängigkeit D im Namensraum N aufzulösen, der die Namensräume I1, I2, I3 importiert…
- Dann , wenn D ein vollständig qualifizierter Name des Formular ist
//namespace:module
, nur der angegebene Namespace wird für die angegebenen Modulnamen gesucht. - Andernfalls sucht Soong zuerst nach einem Modul namens D, das im Namensraum N deklariert ist.
- Wenn dieses Modul nicht existiert, sucht Soong nach einem Modul namens D in den Namensräumen I1, I2, I3…
- Schließlich sucht Soong im Root-Namespace.