קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כשמוסיפים קוד ל-AOSP, צריך להשתמש בדגלים להשקת תכונות כדי לבודד קוד שלא נבדק מקוד שנבדק. הפעלת דגלים להשקת תכונות כדי להריץ ולבדוק את הקוד.
לעומת זאת, אפשר להשבית את הדגלים להשקת תכונות כדי לוודא שקוד שלא נבדק לא יבוצע.
סימוני השקה של תכונות משמשים בעיקר בשתי הדרכים הבאות:
אם אתם תורמים ל-AOSP, יכול להיות שבודק השינוי יבקש מכם להטמיע דגל להשקת תכונה כדי לבדוק את התכונה כראוי.
מידע נוסף על ההסתעפויות זמין במאמר מחזור החיים של גרסאות.
Google משתמשת בדגלים להשקת תכונות כדי לוודא שהגרסה האחרונה של Android (android16-release) יציבה לכולם. אם החברה שלכם שומרת רפליקת AOSP ועובדת ממנה, תוכלו להשתמש בתיוג של השקת תכונות כדי לשמור על יציבות הרפליקות של קוד AOSP עבור צוות הפיתוח.
השלבים העיקריים להטמעת דיווח על השקת תכונות:
בשינוי קוד נתון, צריך לקבוע אם צריך להוסיף דגל, ואם כן, צריך לקבוע את סוג הדגל.
מגדירים את הדגל.
עוטפים את שינוי הקוד בדגל.
מגדירים את ערך הדגל.
פיתוח ובדיקה של הקוד.
שינוי ערכי הדגלים בזמן הריצה.
בדיקת קוד שמשתמש בדגלים להשקת תכונות
בדפים שבקטע הזה מוסבר איך לבצע כל אחד מהשלבים האלה.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","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 (שעון 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."]]
