A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
As flags de lançamento de recursos são usadas pelo Google como uma garantia de manter as ramificações
de código estáveis. Além disso, elas têm uso obrigatório em determinados tipos de contribuições
do AOSP. Antes de implementar flags de lançamento de recursos, determine se
isso é necessário para sua mudança. Caso uma flag seja necessária,
determine o tipo de flag que será usado.
Determinar o uso de flags
Para determinar quando usar uma flag de lançamento de recurso, siga estas diretrizes:
Se a mudança que você está fazendo for do tipo que pode desestabilizar a base de código do AOSP,
como a adição de um novo recurso ou correção de um bug particularmente complexo, use uma flag
de lançamento de recurso.
Por outro lado, se você estiver fazendo uma mudança de código que provavelmente não vai
desestabilizar a base de código, como a modificação de comentários, não será necessário usar uma
flag de lançamento de recurso.
Determinar o tipo de flag
Existem dois tipos de flag: flags aconfig e flags de build.
Flags aconfig
As flags aconfig são usadas para separar as execuções de código não lançado e
código lançado durante os testes e o processo de lançamento. Esse tipo de flag pode ser
de leitura e gravação ou somente leitura:
Flags aconfig de leitura e gravação são variáveis booleanas que você pode ativar (definir como
true) ou desativar (definir como false) durante a execução. Use uma flag de leitura e gravação para testar
e lançar mudanças sem afetar a estabilidade da ramificação principal.
Flags aconfig somente leitura são constantes booleanas que não podem ser alteradas
durante a execução. É possível converter flags aconfig de leitura e gravação para somente leitura
em códigos estáveis e prontos para o lançamento.
Além disso, dependendo do compilador usado, quando uma flag somente leitura
é aplicada, um código não executado pode ser excluído
do build. Você pode usar flags somente leitura para ocultar códigos que
não estão prontos para fazer parte de um lançamento.
Flags de build
As flags de build são constantes do tempo de build (strings) e não podem ser alteradas durante
a execução. Use essas flags quando não for possível usar flags aconfig,
como nestes exemplos:
Você tem um código pré-compilado ou pré-criado que quer incluir
no build.
Você quer fazer mudanças no sistema de build em si.
Você quer adicionar flags em volta de dependências para controlar o tamanho do código.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-03-26 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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\"`)."]]
