از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
در اندروید 10، ConfigStore HAL از پرچم‌های ساخت برای ذخیره مقادیر پیکربندی در پارتیشن vendor استفاده می‌کند، و یک سرویس در پارتیشن system با استفاده از HIDL به آن مقادیر دسترسی پیدا می‌کند (این در اندروید 9 نیز صادق است). با این حال، به دلیل مصرف زیاد حافظه و استفاده دشوار، ConfigStore HAL منسوخ شده است.
ConfigStore HAL برای پشتیبانی از پارتیشن های فروشنده قدیمی در AOSP باقی می ماند. در دستگاه‌هایی که Android 10 یا بالاتر دارند، surfaceflinger ابتدا ویژگی‌های سیستم را می‌خواند. اگر هیچ ویژگی سیستمی برای یک آیتم پیکربندی در «SurfaceFlingerProperties.sysprop» تعریف نشده باشد، «surfaceflinger» به ConfigStore HAL برمی گردد.
Android 8.0 سیستم عامل اندروید یکپارچه را به پارتیشن های عمومی ( system.img ) و سخت افزاری خاص ( vendor.img و odm.img ) تقسیم می کند. در نتیجه این تغییر، کامپایل شرطی باید از ماژول های نصب شده در پارتیشن سیستم حذف شود و چنین ماژول هایی باید پیکربندی سیستم را در زمان اجرا تعیین کنند (و بسته به آن پیکربندی متفاوت رفتار کنند).
ConfigStore HAL مجموعه‌ای از APIها را برای دسترسی به موارد پیکربندی فقط خواندنی که برای پیکربندی چارچوب Android استفاده می‌شوند، ارائه می‌کند. این صفحه طراحی ConfigStore HAL را توضیح می دهد (و چرا از ویژگی های سیستم برای این منظور استفاده نمی شود). سایر صفحات در این بخش ، رابط HAL ، اجرای سرویس ، و استفاده از سمت سرویس گیرنده را شرح می‌دهند که همگی از surfaceflinger به عنوان مثال استفاده می‌کنند. برای راهنمایی در مورد کلاس‌های رابط ConfigStore، به افزودن کلاس‌ها و موارد رابط مراجعه کنید.
چرا از ویژگی های سیستم استفاده نمی کنید؟
ما استفاده از ویژگی های سیستم را در نظر گرفتیم اما چندین مشکل اساسی پیدا کردیم، از جمله:
محدودیت طول در مقادیر ویژگی های سیستم محدودیت های محدودی در طول مقادیر خود دارند (92 بایت). علاوه بر این، از آنجایی که این محدودیت‌ها مستقیماً در معرض برنامه‌های Android به عنوان ماکروهای C قرار گرفته‌اند، افزایش طول می‌تواند باعث مشکلات سازگاری با عقب‌گردی شود.
بدون پشتیبانی از نوع همه مقادیر در اصل رشته هستند و APIها به سادگی رشته را به یک int یا bool تجزیه می کنند. سایر انواع داده های ترکیبی (به عنوان مثال، آرایه و ساختار) باید توسط کلاینت ها کدگذاری/رمزگشایی شوند (به عنوان مثال، "aaa,bbb,ccc" می توان به صورت آرایه ای از سه رشته کدگذاری کرد).
رونویسی می کند. از آنجایی که ویژگی‌های سیستم فقط خواندنی به‌عنوان ویژگی‌های یک بار نوشتن پیاده‌سازی می‌شوند، فروشندگان/ODMهایی که می‌خواهند مقادیر فقط خواندنی تعریف‌شده توسط AOSP را لغو کنند، باید مقادیر فقط خواندنی خودشان را قبل از مقادیر فقط خواندنی تعریف‌شده توسط AOSP وارد کنند. این به نوبه خود باعث می شود که مقادیر قابل بازنویسی تعریف شده توسط فروشنده توسط مقادیر تعریف شده توسط AOSP نادیده گرفته شوند.
آدرس فضای مورد نیاز ویژگی های سیستم در هر فرآیند مقدار نسبتاً زیادی از فضای آدرس را اشغال می کند. ویژگی‌های سیستم در واحدهای prop_area با اندازه ثابت 128 کیلوبایت گروه‌بندی می‌شوند که همه آنها به یک فضای آدرس فرآیند اختصاص داده می‌شوند، حتی اگر فقط یک ویژگی سیستم در آن دسترسی داشته باشد. این می تواند مشکلاتی را در دستگاه های 32 بیتی که فضای آدرس با ارزش است ایجاد کند.
ما سعی کردیم بر این محدودیت‌ها غلبه کنیم بدون اینکه سازگاری را به خطر بیندازیم، اما همچنان نگران بودیم که ویژگی‌های سیستم برای پشتیبانی از دسترسی به موارد پیکربندی فقط خواندنی طراحی نشده است. در نهایت به این نتیجه رسیدیم که ویژگی‌های سیستم برای اشتراک‌گذاری چند مورد به‌روزرسانی شده پویا در سراسر Android در زمان واقعی مناسب‌تر است و نیاز به یک سیستم جدید برای دسترسی به موارد پیکربندی فقط خواندنی وجود دارد.
طراحی HAL ConfigStore
طراحی اولیه ساده است:
شکل 1. طراحی HAL ConfigStore
پرچم های ساخت (که در حال حاضر برای کامپایل شرطی چارچوب استفاده می شود) را در HIDL توضیح دهید.
فروشندگان و OEM ها SoC و مقادیر خاص دستگاه را برای پرچم های ساخت با اجرای سرویس HAL ارائه می کنند.
چارچوب را برای استفاده از سرویس HAL برای یافتن مقدار یک آیتم پیکربندی در زمان اجرا تغییر دهید.
موارد پیکربندی که در حال حاضر توسط چارچوب به آنها ارجاع می شود در بسته HIDL نسخه شده ( android.hardware.configstore@1.0 ) گنجانده شده است. فروشندگان/OEM ها با پیاده سازی واسط ها در این بسته، مقادیری را برای آیتم های پیکربندی ارائه می کنند، و چارچوب زمانی که نیاز به دریافت مقداری برای یک آیتم پیکربندی دارد، از رابط ها استفاده می کند.
ملاحظات امنیتی
پرچم‌های ساخت تعریف‌شده در یک رابط، تحت تأثیر همان سیاست SELinux قرار می‌گیرند. اگر یک یا چند پرچم ساخت باید خط‌مشی‌های SELinux متفاوتی داشته باشند، باید به یک رابط دیگر جدا شوند . این می‌تواند نیاز به بازنگری عمده در android.hardware.configstore package داشته باشد، زیرا رابط‌های جدا شده دیگر با عقب‌نشینی سازگار نیستند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# ConfigStore HAL\n\nIn Android 10, ConfigStore HAL uses build flags to store\nconfig values in the `vendor` partition, and a service in the `system`\npartition accesses those values using HIDL (this is also true in Android 9). However, due to high\nmemory consumption and difficult usage, the ConfigStore HAL has been deprecated.\n\n\nThe ConfigStore HAL remains in AOSP to support legacy vendor partitions. On\ndevices running Android 10 or later, `surfaceflinger`\nreads system properties first; if no system property is defined for a config\nitem in \\`SurfaceFlingerProperties.sysprop\\`, \\`surfaceflinger\\` falls back to the\nConfigStore HAL.\n| **Warning:** Android 10 deprecates the ConfigStore HAL and replaces the HAL with system properties. For details, refer to [Configuring](/docs/core/architecture/configuration).\n\nAndroid 8.0 splits the monolithic Android OS into generic\n(`system.img`) and hardware-specific (`vendor.img` and\n`odm.img`) partitions. As a result of this\nchange, conditional compilation must be removed from modules installed to the\nsystem partition and such modules must determine the configuration of the\nsystem at runtime (and behave differently depending on that configuration).\n\nThe ConfigStore HAL provides a set of APIs for accessing read-only\nconfiguration items used to configure the Android framework. This page describes\nthe design of ConfigStore HAL (and why system properties weren't used for this\npurpose); other pages in this section detail the\n[HAL interface](/docs/core/architecture/configstore/interface),\n[service\nimplementation](/docs/core/architecture/configstore/service), and\n[client-side usage](/docs/core/architecture/configstore/client),\nall using `surfaceflinger` as an example. For help with ConfigStore\ninterface classes, see\n[Adding Interface\nClasses and Items](/docs/core/architecture/configstore/add-class-item).\n\nWhy not use system properties?\n------------------------------\n\nWe considered using system properties but found several fundamental issues,\nincluding:\n\n- **Length limits on values.** System properties have tight limits on the length of their values (92 bytes). In addition, as these limits have been directly exposed to Android apps as C macros, increasing the length can cause backward-compatibility issues.\n- **No type support.** All values are essentially strings, and APIs simply parse the string into an `int` or `bool`. Other compound data types (for example, array and struct) should be encoded/decoded by the clients (for example, `\"aaa,bbb,ccc\"` can be coded as an array of three strings).\n- **Overwrites.** Because read-only system properties are implemented as write-once properties, vendors/ODMs that want to override AOSP-defined read-only values must import their own read-only values prior to AOSP-defined read-only values. This, in turn, results in vendor-defined rewritable values being overridden by AOSP-defined values.\n- **Address space requirements.** System properties take a relatively large amount of address space in each process. System properties are grouped in `prop_area` units with a fixed size of 128 KB, all of which is allocated to a process address space even if only a single system property in it is being accessed. This can cause problems on 32-bit devices where address space is precious.\n\nWe attempted to overcome these limitations without sacrificing compatibility,\nbut continued to be concerned that system properties weren't designed to\nsupport accessing read-only configuration items. Eventually we decided that\nsystem properties are better suited for sharing a few dynamically updated items\nacross all of Android in real time, and that a need existed for a new system\ndedicated to accessing read-only configuration items.\n\nConfigStore HAL design\n----------------------\n\nThe basic design is simple:\n\n**Figure 1.** ConfigStore HAL design\n\n- Describe build flags (currently used for conditionally compiling the framework) in HIDL.\n- Vendors and OEMs provide SoC and device-specific values for build flags by implementing the HAL service.\n- Modify the framework to use the HAL service to find the value of a configuration item at runtime.\n\nConfiguration items currently referenced by the framework are included in a\nversioned HIDL package (`android.hardware.configstore@1.0`).\nVendors/OEMs provide values to the configuration items by implementing\ninterfaces in this package, and the framework uses the interfaces when it needs\nto get a value for a configuration item.\n\nSecurity considerations\n-----------------------\n\nBuild flags defined in the same interface are affected by same SELinux\npolicy. If one or more build flags should have different SELinux policies,\n**they must be separated to another interface** . This can require\nmajor revision of `android.hardware.configstore package` as the\nseparated interfaces are no longer backward-compatible.\n| **Note:** For details on SELinux, see [SELinux Overview](/docs/security/features/selinux)."]]
