ConfigStore HAL

الروبوت 8.0 الانقسامات ومتجانسة الروبوت OS في عام ( system.img ) والأجهزة محددة ( vendor.img و odm.img ) أقسام. نتيجة لهذا التغيير ، يجب إزالة الترجمة الشرطية من الوحدات النمطية المثبتة في قسم النظام ويجب أن تحدد هذه الوحدات تكوين النظام في وقت التشغيل (وتتصرف بشكل مختلف اعتمادًا على هذا التكوين).

يوفر ConfigStore HAL مجموعة من واجهات برمجة التطبيقات للوصول إلى عناصر التكوين للقراءة فقط المستخدمة لتكوين إطار عمل Android. تصف هذه الصفحة تصميم ConfigStore HAL (ولماذا لم يتم استخدام خصائص النظام لهذا الغرض) ؛ صفحات أخرى في هذا القسم بالتفصيل اجهة HAL ، تنفيذ الخدمة ، و استخدام العميل ، كل باستخدام surfaceflinger كمثال على ذلك. للحصول على مساعدة الطبقات واجهة ConfigStore، انظر إضافة فئات واجهة والأصناف .

لماذا لا تستخدم خصائص النظام؟

فكرنا في استخدام خصائص النظام ولكن وجدنا العديد من المشكلات الأساسية ، بما في ذلك:

  • حدود الطول على القيم. خصائص النظام لها حدود مشددة على طول قيمها (92 بايت). بالإضافة إلى ذلك ، نظرًا لأن هذه الحدود قد تعرضت مباشرةً لتطبيقات Android مثل وحدات الماكرو C ، فإن زيادة الطول يمكن أن يتسبب في حدوث مشكلات في التوافق مع الإصدارات السابقة.
  • لا يوجد نوع الدعم. كل القيم هي الأساس السلاسل، واجهات برمجة التطبيقات ببساطة تحليل سلسلة إلى int أو bool . أنواع البيانات مركبة أخرى (على سبيل المثال، مجموعة والبنية) ينبغي ترميز / فك الشفرة من قبل العملاء (على سبيل المثال، "aaa,bbb,ccc" يمكن أن تكون مشفرة على أنها مجموعة من ثلاثة سلاسل).
  • يستبدل. نظرًا لأنه يتم تنفيذ خصائص النظام للقراءة فقط كخصائص للكتابة مرة واحدة ، يجب على البائعين / ODM الذين يريدون تجاوز قيم القراءة فقط المعرفة من AOSP استيراد قيم القراءة فقط الخاصة بهم قبل قيم القراءة فقط المعرفة من قبل AOSP. وهذا بدوره يؤدي إلى تجاوز القيم التي يحددها البائع والقابلة لإعادة الكتابة بواسطة القيم المحددة من قبل AOSP.
  • عنوان متطلبات مساحة. تشغل خصائص النظام قدرًا كبيرًا نسبيًا من مساحة العنوان في كل عملية. يتم تجميع خصائص النظام في prop_area الوحدات مع حجم ثابت من 128 كيلو بايت، والتي تم تخصيصها لمساحة عنوان العملية حتى لو يتم الوصول فقط خاصية نظام واحد في ذلك. يمكن أن يسبب هذا مشاكل على أجهزة 32 بت حيث مساحة العنوان ثمينة.

حاولنا التغلب على هذه القيود دون التضحية بالتوافق ، لكننا ظللنا نشعر بالقلق من أن خصائص النظام لم تكن مصممة لدعم الوصول إلى عناصر التكوين للقراءة فقط. في النهاية قررنا أن خصائص النظام هي الأنسب لمشاركة بعض العناصر المحدثة ديناميكيًا عبر جميع أجهزة Android في الوقت الفعلي ، وأن هناك حاجة لنظام جديد مخصص للوصول إلى عناصر التكوين للقراءة فقط.

تصميم ConfigStore HAL

التصميم الأساسي بسيط:

Configstore HAL التصميم

تصميم الشكل 1. ConfigStore HAL

  • وصف إشارات البناء (المستخدمة حاليًا للترجمة الشرطية لإطار العمل) في HIDL.
  • يوفر البائعون والشركات المصنعة للمعدات الأصلية SoC وقيمًا خاصة بالجهاز لإنشاء إشارات عن طريق تنفيذ خدمة HAL.
  • قم بتعديل إطار العمل لاستخدام خدمة HAL للعثور على قيمة عنصر التكوين في وقت التشغيل.

تدرج بنود التكوين المشار إليه حاليا من قبل الإطار في حزمة HIDL إصداراتها ( android.hardware.configstore@1.0 ). يوفر البائعون / مصنعي المعدات الأصلية قيمًا لعناصر التكوين من خلال تنفيذ واجهات في هذه الحزمة ، ويستخدم إطار العمل الواجهات عندما يحتاج إلى الحصول على قيمة لعنصر التكوين.

اعتبارات أمنية

تتأثر إشارات البناء المحددة في نفس الواجهة بنفس سياسة SELinux. إذا يجب أن يكون واحد أو أكثر من الأعلام بناء سياسات سيلينو مختلفة، فإنها يجب أن تكون مفصولة إلى واجهة أخرى. وهذا يمكن أن تتطلب مراجعة رئيسية من android.hardware.configstore package باعتبارها واجهات منفصلة لم تعد المتوافقة.