Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Wenn Sie Code in AOSP einfügen, verwenden Sie Flags für die Einführung von Funktionen, um nicht getesteten Code von getestetem Code zu isolieren. Aktivieren Sie Flags für die Einführung von Funktionen, um Ihren Code auszuführen und zu testen.
Deaktivieren Sie dagegen die Flags für die Einführung von Funktionen, damit nicht getesteter Code nicht ausgeführt wird.
Flags für die Markteinführung von Funktionen werden hauptsächlich auf zwei Arten verwendet:
Wenn Sie Beiträge zu AOSP leisten, werden Sie vom Prüfer Ihrer Änderung möglicherweise aufgefordert, ein Flag für die Einführung der Funktion zu implementieren, damit die Funktion ordnungsgemäß getestet werden kann.
Weitere Informationen zu Branches finden Sie unter Release-Lebenszyklus.
Google verwendet Flags für die Einführung von Funktionen, um sicherzustellen, dass der aktuelle Release-Branch von Android (android16-release) für alle stabil ist. Wenn Ihr Unternehmen einen AOSP-Mirror verwaltet und von diesem aus arbeitet, verwenden Sie die Markierung für die Einführung von Funktionen, um den AOSP-Code für Ihr Entwicklungsteam stabil zu halten.
Die allgemeinen Schritte zur Implementierung von Markierungen für die Einführung von Funktionen:
Prüfen Sie bei einer bestimmten Codeänderung, ob Sie ein Flag benötigen, und bestimmen Sie gegebenenfalls den Flag-Typ.
Deklarieren Sie das Flag.
Setzen Sie die Codeänderung in das Flag.
Legen Sie den Wert des Flags fest.
Erstellen und testen Sie den Code.
Flag-Werte zur Laufzeit ändern
Testcode mit Flags für die Funktionsveröffentlichung
Auf den Seiten in diesem Abschnitt erfahren Sie, wie Sie die einzelnen Schritte ausführen.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
