קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
דגלים של build הם קבועים בזמן ה-build, ואי אפשר לשנות אותם במהלך זמן הריצה. הדגלים האלה משמשים במקרים שבהם אי אפשר להשתמש בדגלי aconfig, למשל:
יש לכם קטע קוד שנוצר מראש או נוצר מראש שרוצים לכלול ב-build באופן אופציונלי.
אתם רוצים לבצע שינויים במערכת ה-build עצמה.
אתם רוצים להוסיף דגלים לקשרי התלות כדי לנהל את גודל הקוד.
אתם רוצים לנהל את ההשקה של תכונה, אבל אתם צריכים לבדוק את הערך של הדגל לפני שהמערכת תספק את דגלי aconfig.
הצהרת דגל build
הכרזות על דגלים ל-build מופיעות בקובצי textproto. כדי להצהיר על דגל build:
ניווט אל WORKING_DIRECTORY/build/release/flag_declarations/
יוצרים קובץ בשם RELEASE_MY_FLAG_NAME.textproto.
עורכים את הקובץ ומוסיפים רשומה דומה לזו:
name: "RELEASE_MY_FLAG_NAME"
namespace: "android_UNKNOWN"
description: "Control if we should read from new storage."
workflow: LAUNCH
containers: "product"
containers: "system"
containers: "system_ext"
containers: "vendor"
איפה:
name מכיל את שם הדגל, לפניו RELEASE_. מותר להשתמש רק באותיות רישיות ובקו תחתון.
namespace מכיל את מרחב השמות של התרומות. עליכם לעבוד עם בודק Google שהוקצה לכם כדי לקבוע את מרחב השמות. אם אתם משתמשים בדגלים להשקת תכונות כדי לשמור על יציבות של המראה של AOSP, אתם יכולים להשתמש במרחב השמות (namespace) כרצונכם.
value הוא הסוג והערך הראשוניים של הדגל. הסוג יכול להיות bool_value או string_value. אם הערך של type הוא string_value, צריך להקיף אותו במירכאות. אם לא מציינים ערך, הערך יהיה מחרוזת ריקה. ערכים בוליאניים מיוצגים כ-true או כמחרוזת ריקה עבור false.
workflow הוא LAUNCH או PREBUILT. משתמשים ב-LAUNCH לדגלים בוליאניים שעוברים מ-false ל-true, בדומה לדגלים להשקת תכונות.
משתמשים ב-PREBUILT לדגלים שמגדירים גרסה, בדרך כלל של גרסת build מוכנה מראש.
containers סוג הקוד שאתם כותבים, למשל 'vendor' לקוד של ספק או 'product' לקוד של מוצר. אם אתם לא בטוחים באיזה ערך להשתמש, השתמשו בכל ארבעת סוגי הקונטיינרים כפי שמוצג בדוגמה הקודמת.
שימוש בדגל build בקובץ Soong
בקובץ ה-build ובמודול שבהם רוצים לשלוח שאילתה לגבי ערך הדגל, משתמשים בתנאי כדי להסתעף לפי ערך הדגל. לדוגמה, בקטע הקוד הבא מתבצעת שאילתה לגבי הערך של הדגל RELEASE__READ_FROM_NEW_STORAGE:
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Declare and use a build flag\n\nBuild flags are build-time constants and can't be changed during runtime. These\nflags are used in circumstances where aconfig flags can't be used, such as\n\n- You have a precompiled or prebuilt piece of code that you want include optionally in a build.\n- You want to make changes to build system itself.\n- You want to put flags around dependencies to manage code size.\n- You want to manage the launch of a feature, but you need to check the value of the flag before aconfig flags are made available by the system.\n\nDeclare a build flag\n--------------------\n\nBuild flags are declared in textproto files. To declare a build flag:\n\n1. Navigate to \u003cvar translate=\"no\"\u003eWORKING_DIRECTORY\u003c/var\u003e`/build/release/flag_declarations/`\n2. Create a file called `RELEASE_`\u003cvar translate=\"no\"\u003eMY_FLAG_NAME\u003c/var\u003e`.textproto`.\n3. Edit the file and add an entry similar to the following:\n\n name: \"RELEASE_MY_FLAG_NAME\"\n namespace: \"android_UNKNOWN\"\n description: \"Control if we should read from new storage.\"\n workflow: LAUNCH\n containers: \"product\"\n containers: \"system\"\n containers: \"system_ext\"\n containers: \"vendor\"\n\n Where:\n - `name` contains the name of the flag preceded by `RELEASE_`. Only uppercase letters and underscore are allowed.\n - `namespace` contains the namespace for contributions. You must work with the assigned Google reviewer to determine your namespace. If you are using feature launch flags to maintain stability of your own AOSP mirror, you can use namespace however you like.\n - `value` is the initial type and value for the flag. The type can be `bool_value` or `string_value`. If type is `string_value` then the value must be in quotes. If not specified, the value is an empty string. Boolean values are represented as either `true` or the empty string for false.\n - `workflow` is either `LAUNCH` or `PREBUILT`. Use `LAUNCH` for boolean flags that advance from `false` to `true`, similar to feature launch flags. Use `PREBUILT` for flags that set a version, typically of a prebuilt.\n - `containers` the type of code you are writing, such as \"vendor\" for vendor code or \"product\" for product code. If you are in doubt of the value to use, use all four containers types as shown in the previous sample.\n\nUse a build flag in a Soong file\n--------------------------------\n\nIn the build file and module where you want to query the flag value, use a\nconditional to branch on the flag value. For example, in the following snippet,\nthe `RELEASE__READ_FROM_NEW_STORAGE` flag's value is queried: \n\n cc_defaults {\n name: \"aconfig_lib_cc_shared_link.defaults\",\n shared_libs: select(release_flag(\"RELEASE_READ_FROM_NEW_STORAGE\"), {\n true: [\"libaconfig_storage_read_api_cc],\n default: [],\n }),\n }\n\nIf this flag's value is `true`, the `libaconfig_storage_read_api_cc` module is\ndynamically linked into the `cc_defaults` module.\n\nIf this flag's value is `false`, nothing (`default: [],`) happens.\n\nUse a build flag in a makefile\n------------------------------\n\nIn the make file, a build flag is a read-only make variable. The following\nmakefile sample accesses a build flag called `RELEASED_PACKAGE_NFC_STCK`: \n\n # NFC and Secure Element packages\n PRODUCT_PACKAGES += \\\n $(RELEASE_PACKAGE_NFC_STACK) \\\n Tag \\\n SecureElement \\\n android.hardware.nfc-service.st \\\n android.hardware.secure_element@1.0-service.st \\\n NfcOverlayCoral\n\nThis flag's declaration has a `workflow` field set to `PREBUILT` in\n[`RELEASE_PACKAGE_NFC_STACK.textproto`](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/release/flag_declarations/RELEASE_PACKAGE_NFC_STACK.textproto?q=%22RELEASE_PACKAGE_NFC_STACK%22&ss=android%2Fplatform%2Fsuperproject%2Fmain)\nand a string value of\n`com.android.nfcservices` [`RELEASE_PACKAGE_NFC_STACK.textproto`](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/release/flag_values/ap3a/RELEASE_PACKAGE_NFC_STACK.textproto)\nthe flag values file for the `trunk_staging` development configuration.\n| **Note:** Flags whose `workflow` field is set to `LAUNCH` should always be compared to an empty string, for example if `flag == true` is written `ifneq (,$(RELEASE_MY_FLAG))` and if `flag == false` is written `ifeq (,$(RELEASE_MY_FLAG))`."]]
