اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تستخدم Google علامات إطلاق الميزات كنهج لضمان ثبات ملفّات رمز المصدر. تكون هذه العلامات مطلوبة أيضًا لأنواع معيّنة من المساهمات
في AOSP. قبل تنفيذ ميزة الإبلاغ عن إطلاق الميزة، حدِّد ما إذا كان
يجب وضع علامة على التغيير. وإذا كان الإبلاغ عن المحتوى ضروريًا، عليك تحديد نوع البلاغ الذي تريد استخدامه.
تحديد استخدام العلامة
لتحديد حالات استخدام علامة إطلاق الميزة، اتّبِع الإرشادات التالية:
إذا كنت بصدد إجراء تغيير قد يؤدي إلى عدم استقرار قاعدة بيانات AOSP،
مثل إضافة ميزة جديدة أو إصلاح خطأ معقّد بشكلٍ خاص، استخدِم علامة بدء
الميزة.
في المقابل، إذا كنت بصدد إجراء تغيير على الرمز البرمجي لا يُحتمَل أن يؤدي إلى عدم استقرار
قاعدة الرموز البرمجية، مثل تعديل التعليقات، لن تحتاج إلى استخدام علامة
إطلاق الميزة.
تحديد نوع العلامة
هناك نوعان من العلامات: علامات aconfig وعلامات الإنشاء.
علامات Aconfig
تُستخدَم علامات Aconfig لفصل تنفيذ الرمز البرمجي الذي لم يتم طرحه عن
الرمز البرمجي الذي تم طرحه أثناء عملية الاختبار والإصدار. يمكن أن تكون علامات Aconfig
للقراءة والكتابة أو للقراءة فقط:
علامات aconfig للقراءة والكتابة هي متغيّرات منطقية يمكنك تفعيلها (بضبطها على
true) أو إيقافها (بضبطها على false) أثناء التشغيل. استخدِم علامة القراءة والكتابة لاختبار
التغييرات وإصدارها بدون التأثير في استقرار الفرع الرئيسي.
رموز aconfig للقراءة فقط هي ثوابت منطقية لا يمكنك تغييرها أثناء
وقت التشغيل. يمكنك تحويل علامات aconfig للقراءة والكتابة إلى علامات aconfig للقراءة فقط
للحصول على رمز برمجي ثابت وجاهز للإصدار.
بالإضافة إلى ذلك، استنادًا إلى المُجمِّع الذي تستخدمه، عند استخدام علامة للقراءة فقط،
قد يتم استبعاد الرمز الذي لا يتم تنفيذه
من عملية الإنشاء. لذلك، يمكنك استخدام علامات القراءة فقط لإخفاء أي رمز برمجي
لم يكتمل بعد ليصبح جزءًا من إصدار.
علامات الإنشاء
علامات الإنشاء هي ثوابت (سلاسل) وقت الإنشاء ولا يمكنك تغييرها أثناء
وقت التشغيل. استخدِم هذه العلامات في الحالات التي لا يمكنك فيها استخدام علامات aconfig،
مثل:
لديك قطعة رمز برمجي مُجمَّعة مسبقًا أو مُنشأة مسبقًا تريد تضمينها في
الإصدار.
إذا كنت تريد إجراء تغييرات على نظام الإنشاء نفسه
إذا أردت وضع علامات حول التبعيات لإدارة حجم الرمز
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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\"`)."]]
