A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
I flag di lancio delle funzionalità vengono utilizzati da Google come approccio per garantire branche di codice stabili. Questi flag sono obbligatori anche per determinati tipi di contributi
all'AOSP. Prima di implementare l'indicazione del lancio di funzionalità, determina se è necessario un indicatore per la modifica. Inoltre, se è necessario un flag, devi determinare il tipo di flag da utilizzare.
Determinare l'utilizzo dei flag
Per determinare quando utilizzare un flag di lancio della funzionalità, segui queste linee guida:
Se apporti una modifica che potrebbe causare l'instabilità della base di codice AOSP, come l'aggiunta di una nuova funzionalità o la correzione di un bug particolarmente complesso, utilizza un flag di lancio della funzionalità.
Al contrario, se apporti una modifica al codice che non è suscettibile di causare l'instabilità della base di codice, ad esempio la modifica dei commenti, non è necessario utilizzare un flag di lancio della funzionalità.
Determina il tipo di flag
Esistono due tipi di flag: flag aconfig e flag di compilazione.
Flag Aconfig
I flag Aconfig vengono utilizzati per separare l'esecuzione del codice non rilasciato dal codice rilasciato durante la procedura di test e rilascio. I flag Aconfig possono essere di lettura/scrittura o di sola lettura:
I flag aconfig di lettura/scrittura sono variabili booleane che puoi attivare (impostate su true) o disattivare (impostate su false) in fase di esecuzione. Utilizza un flag di lettura/scrittura per testare
e rilasciare le modifiche senza influire sulla stabilità di un ramo principale.
I flag aconfig di sola lettura sono costanti booleane che non puoi modificare in fase di esecuzione. Puoi convertire i flag aconfig di lettura/scrittura in flag aconfig di sola lettura per il codice stabile e pronto per il rilascio.
Inoltre, a seconda del compilatore utilizzato, quando viene utilizzato un flag di sola lettura, il codice non eseguito potrebbe essere escluso dalla compilazione. Pertanto, puoi utilizzare gli indicatori di sola lettura per nascondere qualsiasi codice che non è pronto per far parte di una release.
Flag di compilazione
I flag di compilazione sono costanti (stringhe) di compilazione e non puoi modificarli durante il tempo di esecuzione. Utilizza questi flag nelle circostanze in cui non puoi utilizzare i flag aconfig, come ad esempio:
Hai un codice precompilato o predefinito che vuoi includere nella compilazione.
Vuoi apportare modifiche al sistema di compilazione stesso.
Vuoi inserire flag nelle dipendenze per gestire le dimensioni del codice.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-27 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\"`)."]]
