27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
AOSP'ye kod eklerken test edilmemiş kodu test edilmiş koddan ayırmak için özellik lansmanı işaretlerini kullanın. Kodunuzu yürütmek ve test etmek için özellik lansmanı işaretlerini etkinleştirin.
Bunun tam tersine, test edilmemiş kodun yürütülmesini önlemek için özellik lansmanı işaretlerini devre dışı bırakın.
Özellik lansmanı işaretleri temel olarak şu iki şekilde kullanılır:
AOSP'ye katkıda bulunuyorsanız değişikliğinizin inceleyeninden, özelliğin düzgün şekilde test edilmesi için bir özellik lansmanı işareti uygulamanız istenebilir.
Dallar hakkında daha fazla bilgi için Sürüm yaşam döngüsü bölümüne bakın.
Google, Android'in en son sürüm dalının (android16-release) herkes için kararlı olmasını sağlamak amacıyla özellik lansmanı işaretlerini kullanır. Şirketiniz AOSP'nin bir kopyasını tutuyorsa ve bu kopyadan çalışıyorsa AOSP kodunun kopyasını geliştirme ekibiniz için kararlı tutmak üzere özellik lansmanı işaretlemeyi kullanın.
Özellik lansmanı işaretlemeyi uygulamayla ilgili üst düzey adımlar şunlardır:
Belirli bir kod değişikliği için işarete ihtiyacınız olup olmadığını ve gerekiyorsa işaret türünü belirleyin.
İşareti belirtin.
Kod değişikliğinizi işaret içine alın.
İşaretin değerini ayarlayın.
Kodunuzu derleyip test edin.
Çalışma zamanında işaret değerlerini değiştirin.
Özellik yayınlama işaretlerini kullanan kodu test etme
Bu bölümdeki sayfalarda, bu adımların her birinin nasıl uygulanacağı açıklanmaktadır.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]