در Android 10، ConfigStore HAL از پرچم‌های ساخت برای ذخیره کردن
مقادیر پیکربندی در پارتیشن vendor استفاده می‌کند، و سرویسی در پارتیشن system
بااستفاده از HIDL به آن مقادیر دسترسی پیدا می‌کند (این موضوع در Android 9 نیز صادق است). بااین‌حال، به‌دلیل مصرف بالای حافظه و استفاده دشوار، ConfigStore HAL منسوخ شده است.
ConfigStore HAL در AOSP باقی می‌ماند تا از بخش‌های فروشنده قدیمی پشتیبانی کند. در دستگاه‌های دارای Android 10 یا بالاتر، surfaceflinger ابتدا
دارایی‌های سیستم را می‌خواند؛ اگر دارایی سیستمی برای عنصر پیکربندی در SurfaceFlingerProperties.sysprop تعریف نشده باشد، surfaceflinger به
ConfigStore HAL برمی‌گردد.
Android 8.0 سیستم‌عامل یکپارچه Android را به بخش‌های عمومی (system.img) و مختص سخت‌افزار (vendor.img و odm.img) تقسیم می‌کند. درنتیجه این تغییر، کامپایل شرطی باید از پیمانه‌های نصب‌شده در پارتیشن سیستم برداشته شود و این پیمانه‌ها باید پیکربندی سیستم را در زمان اجرا تعیین کنند (و بسته به آن پیکربندی، رفتار متفاوتی داشته باشند).
ConfigStore HAL مجموعه‌ای از میاناهای برنامه‌سازی کاربردی برای دسترسی به موارد پیکربندی فقط خواندنی ارائه می‌دهد که برای پیکربندی چارچوب Android استفاده می‌شود. این صفحه
طراحی ConfigStore HAL (و اینکه چرا از ویژگی‌های سیستم برای این
منظور استفاده نشده است) را شرح می‌دهد؛ صفحه‌های دیگر در این بخش جزئیات
میانای HAL،
پیاده‌سازی
سرویس، و
استفاده سمت کارخواه را شرح می‌دهند،
همه بااستفاده از surfaceflinger به‌عنوان نمونه. برای دریافت راهنمایی درباره کلاس‌های میانای ConfigStore، به
افزودن کلاس‌ها و
عناصر میانای مراجعه کنید.
چرا از دارایی‌های سیستم استفاده نمی‌کنید؟
ما استفاده از دارایی‌های سیستم را درنظر گرفتیم اما چندین مشکل اساسی پیدا کردیم، ازجمله:
- محدودیت‌های طول برای مقادیر. دارایی‌های سیستم محدودیت‌های سخت‌گیرانه‌ای برای طول مقادیرشان دارند (۹۲ بایت). علاوه‌براین، ازآنجایی‌که این محدودیت‌ها مستقیماً به‌عنوان کلان‌های C در برنامه‌های Android آشکار شده‌اند، افزایش طول می‌تواند باعث مشکلات سازگاری با نسخه‌های قبلی شود.
- نوع پشتیبانی ندارد. همه مقادیر اساساً رشته هستند و
میاناهای برنامه‌سازی کاربردی به‌سادگی رشته را به
intیاboolتجزیه می‌کنند. انواع داده مرکب دیگر (برای مثال، آرایه و ساختار) باید توسط مشتریان کدبندی/کدگشایی شوند (برای مثال،"aaa,bbb,ccc"می‌تواند به‌عنوان آرایه‌ای از سه رشته کدبندی شود). - رونویسی می‌کند. ازآنجایی‌که دارایی‌های سیستم فقط‌خواندنی به‌عنوان دارایی‌های یک‌بار نوشتنی پیاده‌سازی می‌شوند، فروشندگان/تولیدکنندگان طراحی اصلی که می‌خواهند مقادیر فقط‌خواندنی تعریف‌شده در AOSP را ملغی کنند باید مقادیر فقط‌خواندنی خودشان را قبل‌از مقادیر فقط‌خواندنی تعریف‌شده در AOSP وارد کنند. این امر به نوبه خود منجر به جایگزینی مقادیر بازنویسی‌پذیر تعریف‌شده توسط فروشنده با مقادیر تعریف‌شده توسط AOSP می‌شود.
- الزامات فضای نشانی را برآورده کنید. خواص سیستم مقدار نسبتاً زیادی از فضای نشانی را در هر فرایند اشغال می‌کنند. دارایی‌های سیستم در
prop_areaواحد با اندازه ثابت ۱۲۸ کیلوبایت گروه‌بندی می‌شوند که همه آن‌ها به فضای نشانی پردازش اختصاص داده می‌شود، حتی اگر فقط یک دارایی سیستم در آن واحد دردسترس باشد. این کار می‌تواند در دستگاه‌های ۳۲ بیتی که فضای نشانی در آن‌ها ارزشمند است مشکل ایجاد کند.
تلاش کردیم بدون فدا کردن سازگاری، بر این محدودیت‌ها غلبه کنیم، اما همچنان نگران بودیم که خصوصیات سیستم برای پشتیبانی از دسترسی به عناصر پیکربندی فقط خواندنی طراحی نشده باشند. درنهایت تصمیم گرفتیم که دارایی‌های سیستم برای هم‌رسانی چند مورد به‌روزرسانی‌شده پویا در سراسر Android به‌صورت هم‌زمان مناسب‌تر هستند و نیاز به سیستم جدیدی وجود دارد که به دسترسی به موارد پیکربندی فقط‌خواندنی اختصاص داده شود.
طراحی ConfigStore HAL
طراحی پایه ساده است:
شکل ۱. طراحی ConfigStore HAL
- پرچم‌های ساخت (که برای کامپایل مشروط چارچوب استفاده می‌شود) را در HIDL توصیف کنید.
- فروشندگان و سازندگان تجهیزات اصلی مقادیر SoC و مختص دستگاه را برای پرچم‌های ساخت با پیاده‌سازی سرویس HAL ارائه می‌دهند.
- چارچوب را اصلاح کنید تا از سرویس HAL برای یافتن مقدار عنصر پیکربندی در زمان اجرا استفاده کند.
موارد پیکربندی که چارچوب به آن‌ها ارجاع می‌دهد در بسته HIDL نسخه‌بندی‌شده (android.hardware.configstore@1.0) گنجانده شده است.
فروشندگان/تولیدکنندگان تجهیزات اصلی با پیاده‌سازی
میاناهای موجود در این بسته، مقادیر موارد پیکربندی را ارائه می‌دهند و چارچوب هنگام نیاز به
دریافت مقدار برای مورد پیکربندی از این میانه‌ها استفاده می‌کند.
ملاحظات امنیتی
پرچم‌های ساخت تعریف‌شده در همان میانای تحت‌تأثیر همان خط‌مشی SELinux قرار دارند. اگر یک یا چند پرچم ساخت باید خط‌مشی‌های SELinux متفاوتی داشته باشند،
باید به رابط دیگری منتقل شوند. این کار می‌تواند نیازمند
اصلاحات عمده در android.hardware.configstore package باشد زیرا
میاناهای جداشده دیگر با نسخه‌های قدیمی سازگار نیستند.