A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Las marcas de compilación son constantes de tiempo de compilación y no se pueden cambiar durante el tiempo de ejecución. Estas marcas se usan en circunstancias en las que las marcas de aconfig no se pueden utilizar, por ejemplo, en los siguientes casos:
Tienes código precompilado que quieres incluir de forma opcional en una compilación.
Quieres realizar cambios en el sistema de compilación en sí.
Quieres colocar marcas alrededor de dependencias para administrar el tamaño del código.
Quieres administrar el lanzamiento de una función, pero necesitas verificar el valor de la marca antes de que el sistema ponga a disposición las marcas de aconfig.
Cómo declarar una marca de compilación
Las marcas de compilación son archivos textproto declarados. Para declarar una marca de compilación, haz lo siguiente:
Navega a WORKING_DIRECTORY/build/release/flag_declarations/.
Crea un archivo llamado RELEASE_MY_FLAG_NAME.textproto.
Edita el archivo y agrega una entrada similar a la siguiente:
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"
En la que:
name contiene el nombre de la marca precedido por RELEASE_. Solo se permiten letras en mayúscula y guiones bajos.
namespace contiene el espacio de nombres para las contribuciones. Para determinar tu espacio de nombres, debes trabajar con tu revisor de Google designado. Si utilizas marcas de lanzamiento de funciones para mantener la estabilidad de tu propia duplicación de AOSP, puedes usar el espacio de nombres como lo desees.
value es el valor y tipo inicial de la marca. El tipo puede ser bool_value o string_value. Si el tipo es string_value, la marca debe estar entre comillas. Si no se especifica, el valor es una cadena vacía. Los valores booleanos se representan como true, o bien con la cadena vacía correspondiente a "false".
workflow es LAUNCH o PREBUILT. Usa LAUNCH para las marcas booleanas que avanzan de false a true, similares a las marcas de lanzamiento de funciones.
Usa PREBUILT para las marcas que configuran una versión, en general de una compilación previa.
containers es el tipo de código que estás escribiendo, como "proveedor" para el código del proveedor o "producto" para el del producto. Si no sabes qué valor usar, utiliza los cuatro tipos de contenedores, como se mostró en el ejemplo anterior.
Cómo usar una marca de compilación en un archivo de Soong
En el archivo y módulo de compilación en los que quieres consultar el valor de la marca, usa un condicional para hacerlo. Por ejemplo, en el siguiente fragmento, se consulta el valor de la marca RELEASE__READ_FROM_NEW_STORAGE:
Si el valor de esta marca es true, el módulo libaconfig_storage_read_api_cc se vincula de manera dinámica al módulo cc_defaults.
Si el valor de esta marca es false, no ocurre nada (default: [],).
Cómo usar una marca de compilación en un archivo de Make
En el archivo de Make, una marca de compilación es una variable de Make de solo lectura. El siguiente archivo de Make de ejemplo accede a una marca de compilación llamada RELEASED_PACKAGE_NFC_STCK:
# NFC and Secure Element packagesPRODUCT_PACKAGES+=\
$(RELEASE_PACKAGE_NFC_STACK)\
Tag\
SecureElement\
android.hardware.nfc-service.st\
android.hardware.secure_element@1.0-service.st\
NfcOverlayCoral
La declaración de esta marca tiene un campo workflow configurado en PREBUILT en RELEASE_PACKAGE_NFC_STACK.textproto y un valor de cadena de com.android.nfcservicesRELEASE_PACKAGE_NFC_STACK.textproto, el archivo de valores de la marca para la configuración de desarrollo de trunk_staging.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-03-26 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-03-26 (UTC)"],[],[],null,["# Declare and use a build flag\n\nBuild flags are build-time constants and can't be changed during runtime. These\nflags are used in circumstances where aconfig flags can't be used, such as\n\n- You have a precompiled or prebuilt piece of code that you want include optionally in a build.\n- You want to make changes to build system itself.\n- You want to put flags around dependencies to manage code size.\n- You want to manage the launch of a feature, but you need to check the value of the flag before aconfig flags are made available by the system.\n\nDeclare a build flag\n--------------------\n\nBuild flags are declared in textproto files. To declare a build flag:\n\n1. Navigate to \u003cvar translate=\"no\"\u003eWORKING_DIRECTORY\u003c/var\u003e`/build/release/flag_declarations/`\n2. Create a file called `RELEASE_`\u003cvar translate=\"no\"\u003eMY_FLAG_NAME\u003c/var\u003e`.textproto`.\n3. Edit the file and add an entry similar to the following:\n\n name: \"RELEASE_MY_FLAG_NAME\"\n namespace: \"android_UNKNOWN\"\n description: \"Control if we should read from new storage.\"\n workflow: LAUNCH\n containers: \"product\"\n containers: \"system\"\n containers: \"system_ext\"\n containers: \"vendor\"\n\n Where:\n - `name` contains the name of the flag preceded by `RELEASE_`. Only uppercase letters and underscore are allowed.\n - `namespace` contains the namespace for contributions. You must work with the assigned Google reviewer to determine your namespace. If you are using feature launch flags to maintain stability of your own AOSP mirror, you can use namespace however you like.\n - `value` is the initial type and value for the flag. The type can be `bool_value` or `string_value`. If type is `string_value` then the value must be in quotes. If not specified, the value is an empty string. Boolean values are represented as either `true` or the empty string for false.\n - `workflow` is either `LAUNCH` or `PREBUILT`. Use `LAUNCH` for boolean flags that advance from `false` to `true`, similar to feature launch flags. Use `PREBUILT` for flags that set a version, typically of a prebuilt.\n - `containers` the type of code you are writing, such as \"vendor\" for vendor code or \"product\" for product code. If you are in doubt of the value to use, use all four containers types as shown in the previous sample.\n\nUse a build flag in a Soong file\n--------------------------------\n\nIn the build file and module where you want to query the flag value, use a\nconditional to branch on the flag value. For example, in the following snippet,\nthe `RELEASE__READ_FROM_NEW_STORAGE` flag's value is queried: \n\n cc_defaults {\n name: \"aconfig_lib_cc_shared_link.defaults\",\n shared_libs: select(release_flag(\"RELEASE_READ_FROM_NEW_STORAGE\"), {\n true: [\"libaconfig_storage_read_api_cc],\n default: [],\n }),\n }\n\nIf this flag's value is `true`, the `libaconfig_storage_read_api_cc` module is\ndynamically linked into the `cc_defaults` module.\n\nIf this flag's value is `false`, nothing (`default: [],`) happens.\n\nUse a build flag in a makefile\n------------------------------\n\nIn the make file, a build flag is a read-only make variable. The following\nmakefile sample accesses a build flag called `RELEASED_PACKAGE_NFC_STCK`: \n\n # NFC and Secure Element packages\n PRODUCT_PACKAGES += \\\n $(RELEASE_PACKAGE_NFC_STACK) \\\n Tag \\\n SecureElement \\\n android.hardware.nfc-service.st \\\n android.hardware.secure_element@1.0-service.st \\\n NfcOverlayCoral\n\nThis flag's declaration has a `workflow` field set to `PREBUILT` in\n[`RELEASE_PACKAGE_NFC_STACK.textproto`](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/release/flag_declarations/RELEASE_PACKAGE_NFC_STACK.textproto?q=%22RELEASE_PACKAGE_NFC_STACK%22&ss=android%2Fplatform%2Fsuperproject%2Fmain)\nand a string value of\n`com.android.nfcservices` [`RELEASE_PACKAGE_NFC_STACK.textproto`](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/release/flag_values/ap3a/RELEASE_PACKAGE_NFC_STACK.textproto)\nthe flag values file for the `trunk_staging` development configuration.\n| **Note:** Flags whose `workflow` field is set to `LAUNCH` should always be compared to an empty string, for example if `flag == true` is written `ifneq (,$(RELEASE_MY_FLAG))` and if `flag == false` is written `ifeq (,$(RELEASE_MY_FLAG))`."]]