ConfigStore HAL

في 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، راجع إضافة فئات وعناصر واجهة .

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

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

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

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

تصميم ConfigStore HAL

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

تصميم مخزن التكوين HAL

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

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

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

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

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