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