קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
ב-AOSP יש את האפשרויות הבאות לשמירת פרטי ההגדרה במכשיר:
מאפייני מערכת
מאפיינים של שיטת הפשטת חומרה (HAL)
קובצי XML של הגדרות המערכת
שכבות-על של משאבים (סטטיות ובזמן ריצה)
מאפייני מערכת
מאפייני מערכת הם צמדי מפתח/ערך של מחרוזות שמאוחסנים במילון הגלובלי build.prop. מאפייני מערכת הם משאבים ברמת המערכת שקל להשתמש בהם, והם גורמים לירידה נמוכה בביצועים. כשמשתמשים במאפייני מערכת, אין צורך להשתמש בתקשורת בין תהליכים (IPC) גם אם מאפיין מערכת משותף לכמה תהליכים. עם זאת, מאפייני המערכת דומים למשתנים גלובליים, והם עלולים להזיק אם משתמשים בהם בצורה שגויה. שימוש לרעה בנכסי המערכת עלול לגרום לבעיות כמו נקודות חולשה באבטחה והגבלת הגישה של המשתמשים לאפליקציות. לפני שמשתמשים במאפייני המערכת כדי לאחסן את פרטי ההגדרה, כדאי לשקול את אפשרויות ההגדרה האחרות.
כשמקור האמת של הגדרה הוא מרכיב חומרה במכשיר, ה-HAL של החומרה צריך לספק את המידע לגבי הרכיב הזה. מגדירים שיטה חדשה של HAL ב-HAL הקיים כדי לגשת להגדרות. מידע נוסף על פיתוח HAL זמין במאמר AIDL ל-HALs.
קובצי XML של הגדרות המערכת
כשנתוני התצורה סטטיים אבל מורכבים (מבוססי-מבנה), מומלץ להשתמש ב-XML או בפורמטים דומים אחרים לנתוני התצורה. מוודאים שהסכימה של הקובץ נשארת יציבה. בקובצי XML, אפשר להשתמש ב-xsd_config כדי לשמור על יציבות הסכימה ולנצל את היתרונות של מנתח XML שנוצר באופן אוטומטי.
שכבת-על של משאבים
אפשר להשתמש בשכבות-על של משאבים כדי להתאים אישית מוצר. יש שני סוגים של שכבות-על של משאבים:
שכבת-על של משאבים בסביבת זמן ריצה (RRO) משמשת לשינוי ערכי המשאבים של חבילת יעד בסביבת זמן ריצה. לדוגמה, אפליקציה שמותקנת בקובץ האימג' של המערכת עשויה לשנות את ההתנהגות שלה על סמך הערך של משאב. במקום להטמיע את ערך המשאב בזמן ה-build, קובץ RRO שמותקן במחיצה אחרת יכול לשנות את הערכים של משאבי האפליקציה בזמן הריצה. למידע נוסף על קובצי RRO, ראו שינוי הערך של משאבי האפליקציה בזמן הריצה.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Configuration overview\n\nAOSP offers the following options for storing configuration information on a\ndevice:\n\n- System properties\n- Hardware abstraction layer (HAL) properties\n- System config XML files\n- Resource overlays (static and runtime)\n\nSystem properties\n-----------------\n\n*System properties* are string key/value pairs stored in the `build.prop`\nglobal dictionary. System properties are system-wide resources that are easy to\nuse and have a low performance overhead. When using system properties, you don't\nneed to use interprocess communication (IPC) even if a system property is shared\nacross multiple processes. However, system properties are similar to global\nvariables and can be harmful when misused. The misuse of system properties can\nresult in issues such as security vulnerabilities and apps becoming inaccessible\nto users. Before using system properties to store configuration information,\nconsider the other configuration options.\n\nFor further information on system properties, see\n[Add system properties](/docs/core/architecture/configuration/add-system-properties)\n| **Note:** Previous to Android 10, AOSP used a ConfigStore HAL to store system properties. ConfigStore HAL is deprecated and should no longer be used. For information on the ConfigStore HAL, refer to [ConfigStore HAL](/docs/core/architecture/configuration/archive).\n\nHAL properties\n--------------\n\nWhen the source of truth for a configuration is from a hardware component on a\ndevice, the HAL for the hardware must provide the information for that\ncomponent. Define a new HAL method in the existing HAL for accessing the\nconfiguration. For further information on developing a HAL, see\n[AIDL for HALs](/docs/core/architecture/aidl/aidl-hals).\n| **Note:** Don't configure the HAL to use system properties as a side-channel communication mechanism for HALs.\n\nSystem config XML files\n-----------------------\n\nWhen the configuration data is static but complicated (structured), consider\nusing XML or other such formats for the configuration data. Ensure that the\nfile schema remains stable. For XML files, you can use\n[`xsd_config`](/docs/core/architecture/config-file-schema-api#config-build-rule)\nto keep the schema stable, and to take advantage of an autogenerated XML\nparser.\n\nResource overlay\n----------------\n\nYou can use resource overlays to customize a product. There are two types of\nresource overlays:\n\n- *Standard resource overlay* used to customize a product at build time. Foris\n information on standard resource overlays, see\n [Customizing the build with resource overlays](/docs/setup/create/new-device#use-resource-overlays).\n\n- *Runtime resource overlay (RRO)* is used to change the resource values\n of a target package at runtime. For example, an app installed on the system\n image might change its behavior based upon the value of a resource. Rather than\n hardcoding the resource value at build time, an RRO installed on a different\n partition can change the values of the app's resources at runtime. For more\n information on RROs, see\n [Change the value of an app's resources at runtime](/docs/core/runtime/rros)."]]