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.
Özellik lansmanı işaretleri, Google tarafından kararlı kod dalları sağlamak için bir yaklaşım olarak kullanılır. Bu işaretler, AOSP'ye yapılan belirli katkı türleri için de gereklidir. Özellik lansmanı işaretlemeyi uygulamadan önce, değişikliğiniz için işaretleme gerekip gerekmediğini belirleyin. Ayrıca, işaret gerekiyorsa kullanılacak işaret türünü belirlemeniz gerekir.
İşaret kullanımını belirleme
Özellik lansmanı işaretinin ne zaman kullanılacağını belirlemek için aşağıdaki yönergeleri uygulayın:
Yeni bir özellik ekleme veya özellikle karmaşık bir hatayı düzeltme gibi AOSP kod tabanının kararsız olmasına neden olabilecek bir değişiklik yapıyorsanız özellik lansmanı işaretçisi kullanın.
Buna karşılık, kod tabanının kararsız olmasına neden olmayacak bir kod değişikliği yapıyorsanız (ör. yorumları değiştirmek) özellik lansmanı işareti kullanmanız gerekmez.
İşaret türünü belirleme
İki tür işaret vardır: aconfig işaretleri ve derleme işaretleri.
Aconfig işaretleri
Yapılandırma işaretleri, test ve sürüm oluşturma işlemi sırasında yayınlanmamış kodun yürütülmesini yayınlanmış koddan ayırmak için kullanılır. Aconfig işaretleri salt okunur veya salt yazılabilir olabilir:
Okuma/yazma aconfig işaretleri, çalışma zamanında etkinleştirebileceğiniz (true olarak ayarlanır) veya devre dışı bırakabileceğiniz (false olarak ayarlanır) boole değişkenleridir. Ana dalın kararlılığını etkilemeden değişiklikleri test etmek ve yayınlamak için bir okuma/yazma işareti kullanın.
Salt okunur aconfig işaretleri, çalışma zamanında değiştiremeyeceğiniz doğru/yanlış sabitlerdir. Kararlı ve kullanıma hazır kodlar için salt okunur aconfig işaretlerini salt okunur aconfig işaretlerine dönüştürebilirsiniz.
Ayrıca, kullandığınız derleyiciye bağlı olarak, salt okunur bir işaret kullanıldığında yürütülmeyen kod derlemeden hariç tutulabilir. Bu nedenle, bir sürüme dahil edilmeye hazır olmayan kodları gizlemek için salt okuma işaretlerini kullanabilirsiniz.
İşaret oluşturma
Derleme işaretleri, derleme zamanı sabitleridir (dizelerdir) ve bunları çalışma zamanında değiştiremezsiniz. Aşağıdaki gibi yapılandırma işaretlerini kullanamadığınız durumlarda bu işaretleri kullanın:
Derlemeye dahil etmek istediğiniz önceden derlenmiş veya önceden oluşturulmuş bir kodunuz var.
Sistemde değişiklik yapmak istiyorsunuz.
Kod boyutunu yönetmek için bağımlılıkların etrafına işaretler koymak istiyorsunuz.
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,["# 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\"`)."]]
