Build-Flag deklarieren und verwenden

Build-Flags sind Build-Zeit-Konstanten und können während der Laufzeit nicht geändert werden. Diese Flags werden in Fällen verwendet, in denen keine Aconfig-Flags verwendet werden können, z. B.

  • Sie haben einen vorkompilierten oder vorgefertigten Code, den Sie optional in einen Build einfügen möchten.
  • Sie möchten Änderungen am Build-System selbst vornehmen.
  • Sie möchten Flags für Abhängigkeiten setzen, um die Codegröße zu verwalten.
  • Sie möchten die Einführung einer Funktion verwalten, müssen aber den Wert des Flags prüfen, bevor Aconfig-Flags vom System zur Verfügung gestellt werden.

Build-Flag deklarieren

Build-Flags werden in Textproto-Dateien deklariert. So deklarieren Sie ein Build-Flag:

  1. Zu WORKING_DIRECTORY/build/release/flag_declarations/ navigieren
  2. Erstellen Sie eine Datei mit dem Namen RELEASE_MY_FLAG_NAME.textproto.

  3. Bearbeiten Sie die Datei und fügen Sie einen Eintrag wie den folgenden hinzu:

    name: "RELEASE_MY_FLAG_NAME"
namespace: "android_UNKNOWN"
description: "Control if we should read from new storage."
workflow: LAUNCH
containers: "product"
containers: "system"
containers: "system_ext"
containers: "vendor"

    Dabei gilt:

    • name enthält den Namen des Flags, dem RELEASE_ vorangestellt ist. Es sind nur Großbuchstaben und Unterstriche zulässig.
    • namespace enthält den Namespace für Beiträge. Sie müssen mit dem zugewiesenen Google-Prüfer zusammenarbeiten, um Ihren Namespace zu ermitteln. Wenn Sie Launch-Flags verwenden, um die Stabilität Ihres eigenen AOSP-Mirrors zu gewährleisten, können Sie den Namespace beliebig verwenden.
    • value ist der ursprüngliche Typ und Wert für das Flag. Der Typ kann bool_value oder string_value sein. Wenn der Typ string_value ist, muss der Wert in Anführungszeichen stehen. Wenn nichts angegeben ist, ist der Wert eine leere Zeichenfolge. Boolesche Werte werden als true oder als leerer String für „false“ dargestellt.
    • workflow ist entweder LAUNCH oder PREBUILT. Verwenden Sie LAUNCH für boolesche Flags, die von false zu true wechseln, ähnlich wie bei Flags für die Einführung von Funktionen. Verwenden Sie PREBUILT für Flags, mit denen eine Version festgelegt wird, in der Regel eine vordefinierte Version.
    • containers der Typ des Codes, den Sie schreiben, z. B. „vendor“ für Anbietercode oder „product“ für Produktcode. Wenn Sie sich nicht sicher sind, welchen Wert Sie verwenden sollen, verwenden Sie alle vier Containertypen, wie im vorherigen Beispiel gezeigt.

Build-Flag in einer Soong-Datei verwenden

Verwenden Sie in der Build-Datei und dem Modul, in dem Sie den Flag-Wert abfragen möchten, eine Bedingung, um basierend auf dem Flag-Wert zu verzweigen. Im folgenden Snippet wird beispielsweise der Wert des Flags RELEASE__READ_FROM_NEW_STORAGE abgefragt:

cc_defaults {
  name: "aconfig_lib_cc_shared_link.defaults",
  shared_libs: select(release_flag("RELEASE_READ_FROM_NEW_STORAGE"), {
    true: ["libaconfig_storage_read_api_cc],
    default: [],
  }),
}

Wenn der Wert dieses Flags true ist, wird das Modul libaconfig_storage_read_api_cc dynamisch in das Modul cc_defaults eingebunden.

Wenn der Wert dieses Flags false ist, passiert nichts (default: [],).

Build-Flag in einem Makefile verwenden

In der Make-Datei ist ein Build-Flag eine schreibgeschützte Make-Variable. Im folgenden Makefile-Beispiel wird auf ein Build-Flag namens RELEASED_PACKAGE_NFC_STCK zugegriffen:

# NFC and Secure Element packages
PRODUCT_PACKAGES += \
    $(RELEASE_PACKAGE_NFC_STACK) \
    Tag \
    SecureElement \
    android.hardware.nfc-service.st \
    android.hardware.secure_element@1.0-service.st \
    NfcOverlayCoral

Die Deklaration dieses Flags hat ein Feld workflow, das in RELEASE_PACKAGE_NFC_STACK.textproto auf PREBUILT gesetzt ist, und einen Stringwert von com.android.nfcservices RELEASE_PACKAGE_NFC_STACK.textproto in der Datei mit den Flag-Werten für die Entwicklungskonfiguration trunk_staging.