از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
پرچم‌های راه‌اندازی ویژگی توسط گوگل به عنوان رویکردی برای اطمینان از شاخه‌های کد پایدار استفاده می‌شود. این پرچم ها همچنین برای انواع خاصی از مشارکت در AOSP مورد نیاز است. قبل از اجرای پرچم‌گذاری راه‌اندازی ویژگی، مشخص کنید که آیا پرچم برای تغییر شما ضروری است یا خیر. و اگر پرچم لازم است، باید نوع پرچم مورد استفاده را تعیین کنید.
استفاده از پرچم را تعیین کنید
برای تعیین زمان استفاده از پرچم راه‌اندازی ویژگی، این دستورالعمل‌ها را دنبال کنید:
اگر تغییری ایجاد می‌کنید که می‌تواند باعث ناپایدار شدن پایگاه کد AOSP شود، مانند افزودن یک ویژگی جدید یا رفع یک باگ پیچیده، از یک پرچم راه‌اندازی ویژگی استفاده کنید.
برعکس، اگر در حال تغییر کدی هستید که نمی‌تواند باعث ناپایدار شدن پایگاه کد شود، مانند اصلاح نظرات، نیازی به استفاده از پرچم راه‌اندازی ویژگی نیست.
نوع پرچم را تعیین کنید
دو نوع پرچم وجود دارد: پرچم های aconfig و پرچم های ساخت .
پرچم های Aconfig
پرچم‌های Aconfig برای جدا کردن اجرای کد منتشر نشده از کد منتشر شده در طول فرآیند آزمایش و انتشار استفاده می‌شوند. پرچم های Aconfig می توانند خواندنی-نوشتنی یا فقط خواندنی باشند:
پرچم‌های aconfig خواندن-نوشتن متغیرهای بولی هستند که می‌توانید در زمان اجرا فعال کنید (تنظیم به true ) یا غیرفعال کنید (تنظیم به false ). از یک پرچم خواندن-نوشتن برای آزمایش و انتشار تغییرات بدون تأثیر بر پایداری شاخه اصلی استفاده کنید.
پرچم‌های aconfig فقط خواندنی، ثابت‌های بولی هستند که نمی‌توانید در زمان اجرا آنها را تغییر دهید. می‌توانید پرچم‌های aconfig خواندن-نوشتن را به پرچم‌های aconfig فقط خواندنی برای کدهایی که پایدار و آماده انتشار هستند تبدیل کنید.
علاوه بر این، بسته به کامپایلری که استفاده می‌کنید، وقتی از یک پرچم فقط خواندنی استفاده می‌شود، ممکن است کدی که اجرا نمی‌شود از بیلد حذف شود. بنابراین، می‌توانید از پرچم‌های فقط خواندنی برای مخفی کردن هر کدی که برای بخشی از نسخه آماده نیست استفاده کنید.
پرچم بسازید
پرچم‌های ساخت، ثابت‌های زمان ساخت (رشته‌ها) هستند و نمی‌توانید آنها را در طول زمان اجرا تغییر دهید. از این پرچم ها در شرایطی استفاده کنید که نمی توانید از پرچم های aconfig استفاده کنید، مانند:
شما یک قطعه کد از پیش کامپایل شده یا از پیش ساخته شده دارید که می خواهید آن را در بیلد قرار دهید.
شما می خواهید تغییراتی ایجاد کنید تا خود سیستم را بسازید.
شما می خواهید پرچم هایی را در اطراف وابستگی ها قرار دهید تا اندازه کد را مدیریت کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],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\"`)."]]
