Diese Seite wurde von der Cloud Translation API übersetzt.

Build-Flag deklarieren und verwenden

Build-Flags sind Build-Zeitkonstanten und können während der Laufzeit nicht geändert werden. Diese Flags werden verwendet, wenn keine aconfig-Flags 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:

Zu WORKING_DIRECTORY/build/release/flag_declarations/ navigieren
Erstellen Sie eine Datei mit dem Namen RELEASE_MY_FLAG_NAME.textproto.
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, 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-Prüfer zusammenarbeiten, um Ihren Namespace zu bestimmen. Wenn Sie Feature Launch-Flags verwenden, um die Stabilität Ihres eigenen AOSP-Spiegels aufrechtzuerhalten, können Sie Namespace beliebig verwenden.
- value ist der anfängliche Typ und der anfängliche 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 nicht angegeben, ist der Wert ein leerer String. 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 Make-Datei ist ein Build-Flag eine schreibgeschützte Variable vom Typ "Make". Das folgende Makefile-Beispiel greift auf ein Build-Flag namens RELEASED_PACKAGE_NFC_STCK zu:

# 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.