Soong Build-System

Vor der Veröffentlichung von Android 7.0 verwendete Android GNU Make ausschließlich zur Beschreibung und Ausführung seiner Build-Regeln. Das Make-Build-System wird weitgehend unterstützt und verwendet, wurde jedoch im Android-Maßstab langsam, fehleranfällig, nicht skalierbar und schwer zu testen. Das Soong-Build-System bietet die für Android-Builds erforderliche Flexibilität.

Aus diesem Grund wird von Plattformentwicklern erwartet, dass sie schnellstmöglich von Make auf Soong umsteigen und Soong übernehmen. Senden Sie Fragen an die Google-Gruppe , die Android entwickelt, um Unterstützung zu erhalten.

Was ist Soong?

Das Soong-Build-System wurde in Android 7.0 (Nougat) eingeführt, um Make zu ersetzen. Es nutzt das Kati GNU Make-Klontool und die Ninja- Build-Systemkomponente, um die Erstellung von Android-Geräten zu beschleunigen.

Allgemeine Anweisungen finden Sie in der Beschreibung des Android Make Build Systems im Android Open Source Project (AOSP) und Build System Changes for Android.mk Writers , um mehr über die erforderlichen Änderungen für die Anpassung von Make an Soong zu erfahren.

Definitionen wichtiger Begriffe finden Sie in den Build-bezogenen Einträgen im Glossar und in den Soong-Referenzdateien für vollständige Details.

Make- und Soong-Vergleich

Hier ist ein Vergleich zwischen Make-Konfiguration und Soong, der dasselbe in einer Soong-Konfigurationsdatei (Blueprint oder .bp ) erreicht.

Machen Sie 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)

Kurzes Beispiel

cc_library_shared {
     name: "libxmlrpc++",

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

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

Testspezifische Soong-Konfigurationsbeispiele 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 weisen einzigartige Eigenschaften auf.

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. Beispielsweise kann es eine cc_prebuilt_binary mit dem Namen foo geben, wenn es bereits eine cc_binary mit demselben Namen gibt. Dies gibt Entwicklern die Flexibilität zu wählen, welche Version sie in ihr Endprodukt aufnehmen möchten. Wenn eine Build-Konfiguration beide Versionen enthält, bestimmt der Wert des prefer Flags in der Definition des vorgefertigten Moduls, welche Version Priorität hat. Beachten Sie, dass einige vorgefertigte Module Namen haben, die nicht mit prebuilt beginnen, z. B. android_app_import .

Namespace-Module

Bis Android vollständig von Make zu Soong konvertiert, 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, um mit dem Befehl m erstellt zu werden. Nachdem die Umstellung von Android auf Soong abgeschlossen ist, können sich die Details zur Aktivierung von Namespaces ändern.

Soong bietet Modulen in verschiedenen Verzeichnissen die Möglichkeit, denselben Namen anzugeben, sofern jedes Modul in einem separaten Namensraum deklariert wird. Ein Namespace kann wie folgt deklariert werden:

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

Beachten Sie, dass ein Namespace keine Namenseigenschaft hat. Sein Pfad wird automatisch als Name zugewiesen.

Jedem Soong-Modul wird basierend auf seiner Position im Baum ein Namespace zugewiesen. Jedes Soong-Modul wird als in dem Namensraum liegend betrachtet, der durch den soong_namespace definiert wird, der in einer Android.bp Datei im aktuellen Verzeichnis oder im nächstgelegenen Vorgängerverzeichnis gefunden wird. Wenn kein solches soong_namespace Modul gefunden wird, wird davon ausgegangen, dass sich das Modul im impliziten Root-Namespace befindet.

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

  1. Wenn D dann ein vollständig qualifizierter Name der Form //namespace:module ist, wird nur der angegebene Namespace nach dem angegebenen Modulnamen durchsucht.
  2. Andernfalls sucht Soong zunächst nach einem Modul namens D, das im Namespace N deklariert ist.
  3. Wenn dieses Modul nicht existiert, sucht Soong in den Namespaces I1, I2, I3 ... nach einem Modul namens D.
  4. Zuletzt sucht Soong im Root-Namespace.