À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Présentation du flag de lancement de la fonctionnalité
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Lorsque vous ajoutez du code dans AOSP, utilisez des options de lancement de fonctionnalités pour isoler le code non testé du code testé. Activez les indicateurs de lancement de fonctionnalités pour exécuter et tester votre code.
À l'inverse, désactivez les indicateurs de lancement de fonctionnalités pour vous assurer que le code non testé ne s'exécute pas.
Les indicateurs de lancement de fonctionnalités sont principalement utilisés de deux manières:
Si vous contribuez à AOSP, l'examinateur de votre modification peut vous demander d'implémenter un indicateur de lancement de la fonctionnalité afin qu'elle soit testée correctement.
Pour en savoir plus sur les branches, consultez la section Cycle de vie des versions.
Google utilise des indicateurs de lancement de fonctionnalités pour s'assurer que la dernière branche de la version Android (android16-release) est stable pour tous. Si votre entreprise conserve un miroir d'AOSP et travaille à partir de ce miroir, utilisez le flag de lancement de la fonctionnalité pour que votre miroir du code AOSP reste stable pour votre équipe de développement.
Voici les grandes étapes à suivre pour mettre en œuvre le signalement du lancement d'une fonctionnalité:
Pour une modification de code donnée, déterminez si vous avez besoin d'un indicateur et, le cas échéant, déterminez le type d'indicateur.
Déclarez l'indicateur.
Encapsulez votre modification de code dans l'indicateur.
Définissez la valeur de l'indicateur.
Créez et testez votre code.
Modifiez les valeurs des indicateurs au moment de l'exécution.
Code de test qui utilise des indicateurs de version de fonctionnalités
Les pages de cette section vous expliquent comment effectuer chacune de ces étapes.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Feature launch flag overview\n\nWhen adding code into AOSP, use *feature launch flags* to isolate\nuntested code from tested code. Enable feature launch flags to execute and\ntest your code.\nConversely, disable feature launch flags to ensure untested code doesn't\nexecute.\n\nFeature launch flags are used primarily in these two ways:\n\n- If you're contributing to AOSP, you might be asked by your change's reviewer to implement a feature launch flag so that the feature is tested properly. For further information on branches, see [Release lifecycle](/docs/setup/contribute/release-lifecycle).\n- Google uses feature launch flags to ensure the Android latest release branch (`android16-release`) is stable for everyone. If your company keeps a mirror of AOSP and works from that mirror, use feature launch flagging to keep your mirror of AOSP code stable for your development team.\n\n| **Note:** Feature launch flagging is part of a new development process called *Trunk Stable* whereby all official AOSP releases are snapped from a single internal main development branch. To achieve this goal, the main development branch must remain stable at all time. Trunk Stable requires all updates and new features to be flagged so they can, on a case-by-case basis, be included or excluded from the internal main branch before snapping a release. For more on the AOSP release process, see [Release\n| lifecycle](/docs/setup/contribute/release-lifecycle).\n\nThe high-level steps for implementing feature launch flagging are:\n\n1. For a given code change, determine if you need a flag and, if so, determine the flag type.\n2. Declare the flag.\n3. Wrap your code change in the flag.\n4. Set the flag's value.\n5. Build and test your code.\n6. Change flag values at runtime.\n7. Test code that uses feature release flags\n\nThe pages in this section teach you how to perform each of these steps."]]
