اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
في Android 10، يستخدم واجهة برمجة التطبيقات ConfigStore HAL علامات الإنشاء لتخزين
قيم الإعدادات في القسم vendor، وتحصل خدمة في القسم system
على هذه القيم باستخدام HIDL (ينطبق ذلك أيضًا على Android 9). ومع ذلك، تم إيقاف HAL ConfigStore نهائيًا بسبب استهلاكه المكثّف للذاكرة وصعوبة استخدامه.
سيظلّ واجهة برمجة التطبيقات ConfigStore HAL متوفّرة في AOSP لتوفير أقسام المورّدين القديمة. على
الأجهزة التي تعمل بالإصدار Android 10 أو الإصدارات الأحدث، يقرأ surfaceflinger
خصائص النظام أولاً. وفي حال عدم تحديد أيّ خاصية نظام لعنصر ملف الإعدادات
في SurfaceFlingerProperties.sysprop، يعود surfaceflinger إلى
واجهة برمجة التطبيقات ConfigStore HAL.
يقسّم نظام التشغيل Android 8.0 نظام التشغيل Android المتكامل إلى أقسام عامة
(system.img) وأقسام خاصة بالأجهزة (vendor.img و
odm.img). نتيجةً لهذا
التغيير، يجب إزالة الترجمة الشَرطية من الوحدات المثبَّتة في ملف التمهيد
النظام، ويجب أن تحدِّد هذه الوحدات إعدادات
النظام أثناء التشغيل (وتتصرف بشكلٍ مختلف استنادًا إلى هذه الإعدادات).
يوفّر واجهة برمجة التطبيقات ConfigStore HAL مجموعة من واجهات برمجة التطبيقات للوصول إلى عناصر الإعدادات
للقراءة فقط التي يتم استخدامها لضبط إطار عمل Android. توضّح هذه الصفحة
تصميم واجهة HAL لـ ConfigStore (وسبب عدم استخدام سمات النظام لهذا
الغرض)، وتوضّح الصفحات الأخرى في هذا القسم بالتفصيل
واجهة HAL و
تنفيذ الخدمة و
الاستخدام من جهة العميل،
وذلك باستخدام surfaceflinger كمثال. للحصول على مساعدة بشأن فئات واجهة ConfigStore، يُرجى الاطّلاع على مقالة إضافة فئات الواجهة والعناصر.
لماذا لا يتم استخدام سمات النظام؟
لقد فكّرنا في استخدام سمات النظام، ولكننا واجهنا عدة مشاكل أساسية،
من بينها:
حدود الطول المسموح به للقيم تفرض خصائص النظام حدودًا ضيّقة على طول قيمها (92 بايت). بالإضافة إلى ذلك، بما أنّه تم عرض
هذه الحدود مباشرةً لتطبيقات Android كوحدات ماكرو C، يمكن أن يؤدي زيادة
الطول إلى حدوث مشاكل في التوافق مع الإصدارات القديمة.
عدم توفّر أنواع معيّنة جميع القيم هي سلاسل نصية في الأساس، وتعمل واجهات برمجة التطبيقات على تحليل السلسلة إلى int أو bool.
يجب أن ينفذ العملاء عملية ترميز/فك ترميز أنواع البيانات المركبة الأخرى (مثل الصفيف والبنية) (على سبيل المثال، يمكن ترميز "aaa,bbb,ccc" كصفيف من ثلاث سلاسل).
عمليات الاستبدال بما أنّ خصائص النظام للقراءة فقط يتم تنفيذها كخصائص للكتابة مرة واحدة، على المورّدين أو المصنّعين الأصليين للأجهزة (ODM) الذين يريدون إلغاء
القيم للقراءة فقط التي حدّدها إطار عمل AOSP استيراد قيمهم الخاصة للقراءة فقط قبل
القيم للقراءة فقط التي حدّدها إطار عمل AOSP. ويؤدي ذلك بدوره إلى إلغاء القيم القابلة للإعادة الكتابة التي يحدّدها المورّد من خلال القيم التي يحدّدها إطار عمل AOSP.
متطلبات مساحة العناوين: تستهلك سمات النظام
مقدارًا كبيرًا نسبيًا من مساحة العناوين في كل عملية. يتم تجميع ملفات النظام
في وحدات prop_area بحجم ثابت يبلغ 128 كيلوبايت، ويتم تخصيص كل
هذه الوحدات لمساحة عناوين العملية حتى إذا كان يتم الوصول إلى ملف نظام واحد فقط
فيها. ويمكن أن يؤدي ذلك إلى حدوث مشاكل على الأجهزة التي تعمل بنظام 32 بت
حيث تكون مساحة العناوين قيّمة.
حاولنا التغلب على هذه القيود بدون التضحية بالتوافق،
لكن ظلّنا قلقين من أنّ خصائص النظام لم يتم تصميمها
للسماح بالوصول إلى عناصر الضبط للقراءة فقط. في النهاية، قرّرنا أنّ
خصائص النظام هي الأنسب لمشاركة بعض العناصر التي يتم تعديلها ديناميكيًا
على مستوى نظام التشغيل Android بالكامل في الوقت الفعلي، وأنّ هناك حاجة إلى نظام جديد
مخصّص للوصول إلى عناصر الضبط للقراءة فقط.
تصميم واجهة برمجة التطبيقات لـ ConfigStore
التصميم الأساسي بسيط:
الشكل 1: تصميم واجهة برمجة التطبيقات لـ ConfigStore
وصف علامات الإنشاء (التي تُستخدَم حاليًا لتجميع الإطار بشكل مشروط) في HIDL
يقدّم المورّدون والمصنّعون الأصليون للأجهزة قيمًا خاصة بالمنظومة على الرقاقة والجهاز لعلامات الإنشاء من خلال
تنفيذ خدمة HAL.
عدِّل إطار العمل لاستخدام خدمة HAL للعثور على قيمة أحد عناصر الإعدادات أثناء التشغيل.
يتم تضمين عناصر الضبط التي يشير إليها إطار العمل حاليًا في
حزمة HIDL ذات الإصدار (android.hardware.configstore@1.0).
يقدّم المورّدون/الشركات المصنّعة الأصلية للأجهزة قيمًا لعناصر الضبط من خلال تنفيذ
الواجهات في هذه الحزمة، ويستخدم إطار العمل الواجهات عندما يحتاج
إلى الحصول على قيمة لعنصر الضبط.
اعتبارات الأمان
تتأثر علامات الإنشاء المحدّدة في الواجهة نفسها بسياسة SELinux
نفسها. إذا كان يجب أن تتضمّن علامة بناء واحدة أو أكثر سياسات SELinux مختلفة،
يجب فصلها إلى واجهة أخرى. وقد يتطلّب ذلك
مراجعة كبرى لـ android.hardware.configstore package لأنّ
الواجهات المنفصلة لم تعُد متوافقة مع الإصدارات القديمة.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)."]]
