Build-Flag deklarieren und verwenden

Build-Flags sind Konstanten zur Buildzeit und können während der Laufzeit nicht geändert werden. Diese Flags werden in Situationen verwendet, in denen aconfig-Flags nicht verwendet werden können, z. B.

  • Sie haben einen vorkompilierten oder vordefinierten Code, den Sie optional in einen Build einbinden möchten.
  • Sie möchten Änderungen am Build-System selbst vornehmen.
  • Sie möchten Abhängigkeiten mit Flags versehen, 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 verfügbar gemacht 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 ähnlich dem 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, gefolgt von RELEASE_. 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-Rezensenten zusammenarbeiten, um Ihren Namespace zu bestimmen. Wenn Sie Flags für die Einführung von Funktionen verwenden, um die Stabilität Ihres eigenen AOSP-Mirrors aufrechtzuerhalten, 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 gesetzt werden. Wenn keine Angabe erfolgt, ist der Wert eine leere Zeichenfolge. Boolesche Werte werden entweder als true oder als leerer String für „falsch“ dargestellt.
    • workflow ist entweder LAUNCH oder PREBUILT. Verwenden Sie LAUNCH für boolesche Flags, die von false zu true fortschreiten, ä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.
    • containers die Art des Codes, den Sie schreiben, z. B. „vendor“ für den Anbietercode oder „product“ für den 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 im Modul, in dem Sie den Flag-Wert abfragen möchten, eine Bedingung, um nach 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 libaconfig_storage_read_api_cc-Modul dynamisch in das cc_defaults-Modul eingebunden.

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

Build-Flag in einem Makefile verwenden

In der Makefile ist ein Build-Flag eine schreibgeschützte Make-Variable. Im folgenden Beispiel für ein Makefile 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 in RELEASE_PACKAGE_NFC_STACK.textproto ein Feld workflow mit dem Wert PREBUILT und einen Stringwert von com.android.nfcservices RELEASE_PACKAGE_NFC_STACK.textproto in der Flag-Wertdatei für die trunk_staging-Entwicklungskonfiguration.