ConfigStore HAL

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

Android 8.0 سیستم عامل اندروید یکپارچه را به پارتیشن های عمومی ( system.img ) و سخت افزاری خاص ( vendor.img و odm.img ) تقسیم می کند. در نتیجه این تغییر، کامپایل شرطی باید از ماژول های نصب شده در پارتیشن سیستم حذف شود و چنین ماژول هایی باید پیکربندی سیستم را در زمان اجرا تعیین کنند (و بسته به آن پیکربندی متفاوت رفتار کنند).

ConfigStore HAL مجموعه‌ای از APIها را برای دسترسی به موارد پیکربندی فقط خواندنی که برای پیکربندی چارچوب Android استفاده می‌شوند، ارائه می‌کند. این صفحه طراحی ConfigStore HAL را توضیح می دهد (و چرا از ویژگی های سیستم برای این منظور استفاده نمی شود). سایر صفحات در این بخش، رابط HAL ، اجرای سرویس ، و استفاده از سمت سرویس گیرنده را شرح می‌دهند که همگی از surfaceflinger به عنوان مثال استفاده می‌کنند. برای راهنمایی در مورد کلاس‌های رابط ConfigStore، به افزودن کلاس‌ها و موارد رابط مراجعه کنید.

چرا از ویژگی های سیستم استفاده نمی کنید؟

ما استفاده از ویژگی های سیستم را در نظر گرفتیم اما چندین مشکل اساسی پیدا کردیم، از جمله:

  • محدودیت طول در مقادیر ویژگی های سیستم محدودیت های محدودی در طول مقادیر خود دارند (92 بایت). علاوه بر این، از آنجایی که این محدودیت‌ها به‌عنوان ماکروهای C مستقیماً در معرض برنامه‌های اندرویدی قرار گرفته‌اند، افزایش طول می‌تواند مشکلات سازگاری با عقب را ایجاد کند.
  • بدون پشتیبانی از نوع همه مقادیر در اصل رشته هستند و APIها به سادگی رشته را به یک int یا bool تجزیه می کنند. سایر انواع داده های ترکیبی (به عنوان مثال، آرایه و ساختار) باید توسط کلاینت ها کدگذاری/رمزگشایی شوند (به عنوان مثال، "aaa,bbb,ccc" را می توان به صورت آرایه ای از سه رشته کدگذاری کرد).
  • رونویسی می کند. از آنجایی که ویژگی‌های سیستم فقط خواندنی به‌عنوان ویژگی‌های یکبار نوشتن پیاده‌سازی می‌شوند، فروشندگان/ODMهایی که می‌خواهند مقادیر فقط خواندنی تعریف‌شده توسط AOSP را لغو کنند، باید مقادیر فقط خواندنی خود را قبل از مقادیر فقط خواندنی تعریف‌شده توسط AOSP وارد کنند. این به نوبه خود باعث می شود که مقادیر قابل بازنویسی تعریف شده توسط فروشنده توسط مقادیر تعریف شده توسط AOSP نادیده گرفته شوند.
  • آدرس مورد نیاز فضای ویژگی های سیستم در هر فرآیند مقدار نسبتاً زیادی از فضای آدرس را اشغال می کند. ویژگی های سیستم در واحدهای prop_area با اندازه ثابت 128 کیلوبایت گروه بندی می شوند، که همه آنها به یک فضای آدرس فرآیند تخصیص داده می شوند حتی اگر فقط یک ویژگی سیستم در آن دسترسی داشته باشد. این می تواند مشکلاتی را در دستگاه های 32 بیتی که فضای آدرس با ارزش است ایجاد کند.

ما سعی کردیم بر این محدودیت‌ها غلبه کنیم بدون اینکه سازگاری را از بین ببریم، اما همچنان نگران بودیم که ویژگی‌های سیستم برای پشتیبانی از دسترسی به موارد پیکربندی فقط خواندنی طراحی نشده است. در نهایت به این نتیجه رسیدیم که ویژگی‌های سیستم برای اشتراک‌گذاری چند مورد به‌روزرسانی شده پویا در سراسر Android در زمان واقعی مناسب‌تر است و نیاز به یک سیستم جدید برای دسترسی به موارد پیکربندی فقط خواندنی وجود دارد.

طراحی HAL ConfigStore

طراحی اولیه ساده است:

طراحی HAL را پیکربندی کنید

شکل 1. طراحی HAL ConfigStore

  • پرچم های ساخت (که در حال حاضر برای کامپایل شرطی چارچوب استفاده می شود) را در HIDL توضیح دهید.
  • فروشندگان و OEM ها SoC و مقادیر خاص دستگاه را برای پرچم های ساخت با اجرای سرویس HAL ارائه می کنند.
  • چارچوب را برای استفاده از سرویس HAL برای یافتن مقدار یک آیتم پیکربندی در زمان اجرا تغییر دهید.

موارد پیکربندی که در حال حاضر توسط چارچوب به آنها ارجاع می شود در بسته HIDL نسخه شده ( android.hardware.configstore@1.0 ) گنجانده شده است. فروشندگان/OEMها با پیاده‌سازی رابط‌ها در این بسته، مقادیری را برای آیتم‌های پیکربندی ارائه می‌کنند، و چارچوب زمانی که نیاز به دریافت مقداری برای یک آیتم پیکربندی دارد، از رابط‌ها استفاده می‌کند.

ملاحظات امنیتی

پرچم‌های ساخت تعریف شده در یک رابط، تحت تأثیر همان سیاست SELinux قرار می‌گیرند. اگر یک یا چند پرچم ساخت باید سیاست های SELinux متفاوتی داشته باشند، باید آنها را به یک رابط دیگر جدا کنید . این می‌تواند نیاز به بازنگری عمده در android.hardware.configstore package داشته باشد، زیرا رابط‌های جدا شده دیگر با عقب‌نشینی سازگار نیستند.