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.
Google utiliza las marcas de lanzamiento de funciones como un método para garantizar las ramas de código estables. Estas marcas también son necesarias para ciertos tipos de contribuciones al AOSP. Antes de implementar las marcas de lanzamiento de funciones, determina si una marca es necesaria para el cambio que realizas. Si es así, debes determinar el tipo de marca que debes usar.
Cómo determinar el uso de marcas
Para determinar cuándo usar una marca de lanzamiento de funciones, sigue estos lineamientos:
Si vas a hacer un cambio que podría causar que la base de código del AOSP sea inestable, como agregar una nueva función o corregir un error particularmente complejo, utiliza una marca de lanzamiento de funciones.
De lo contrario, si vas a hacer un cambio de código que no puede causar que la base de código sea inestable, como modificar comentarios, no necesitas usar una marca de lanzamiento de funciones.
Cómo determinar el tipo de marcas
Existen dos tipos de marcas: Las marcas de aconfig y las marcas de compilación.
Marcas de aconfig
Las marcas de aconfig se utilizan para separar la ejecución de código sin lanzar del código lanzado durante el proceso de prueba y lanzamiento. Las marcas de aconfig pueden ser de lectura y escritura o de solo lectura:
Las marcas de aconfig de lectura y escritura son variables booleanas que puedes habilitar (configurar en true) o inhabilitar (configurar en false) durante el tiempo de ejecución. Usa una marca de lectura y escritura para probar y lanzar cambios sin afectar la estabilidad de una rama principal.
Las marcas de aconfig de solo lectura son variables booleanas que no puedes cambiar durante el tiempo de ejecución. Puedes convertir las marcas de aconfig de lectura y escritura a marcas de aconfig de solo lectura para el código que ya es estable y está listo para el lanzamiento.
Además, en función del compilador que utilices, cuando se use una marca de solo lectura, el código no ejecutado podría excluirse de la compilación. Por lo tanto, puedes usar marcas de solo lectura para ocultar código que no esté listo para formar parte de una versión.
Marcas de compilación
Las marcas de compilación son constantes de tiempo de compilación (cadenas) y no se pueden cambiar durante el tiempo de ejecución. Usa estas marcas en casos en los que no puedas utilizar marcas de aconfig, como en los siguientes casos:
Tienes código precompilado que quieres incluir en la 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.
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,["# Determine flag usage and type\n\nFeature launch flags are used by Google as an approach to ensuring stable\ncode branches. These flags are also required for certain types of contributions\nto AOSP. Before implementing feature launch flagging, determine if\na flag is necessary for your change. And, if a flag is necessary, you should\ndetermine the type of flag to use.\n\nDetermine flag usage\n--------------------\n\nTo determine when to use a feature launch flag, follow these guidelines:\n\n- If you are making a change that could cause the AOSP codebase to be unstable,\n such as adding a new feature or fixing a particularly complex bug, use a feature\n launch flag.\n\n- Conversely, if you are making a code change that isn't apt to cause the\n codebase to be unstable, such as modifying comments, you don't need to use a\n feature launch flag.\n\nDetermine flag type\n-------------------\n\nThere are two types of flags: *aconfig flags* and *build flags*.\n\n### Aconfig flags\n\nAconfig flags are used to separate the execution of unreleased code from\nreleased code during the testing and release process. Aconfig flags can be\nread-write or read-only:\n\n- *Read-write aconfig flags* are boolean variables that you can enable (set to\n `true`) or disable (set to `false`) at runtime. Use a read-write flag to test\n and release changes without affecting the stability of a main branch.\n\n- *Read-only aconfig flags* are boolean constants that you can't change at\n runtime. You can convert read-write aconfig flags to read-only aconfig flags\n for code that is stable and ready to release.\n\n Additionally, depending on the compiler you're using, when a read-only flag\n is used, the code that isn't executed might be excluded\n from the build. Therefore, you can use read-only flags to hide any code that\n isn't ready to be part of a release.\n\n### Build flags\n\nBuild flags are build-time constants (strings) and you can't change them during\nruntime. Use these flags in circumstances where you can't use aconfig flags,\nsuch as:\n\n- You have a precompiled or prebuilt piece of code that you want to include in the build.\n- You want to make changes to build system itself.\n- You want to put flags around dependencies to manage code size.\n\n| **Note:** Build flags have special encodings for boolean values (`false: {empty string}, true: \"true\"`)."]]
