التحقّق من قابلية اختبار HAL

تتيح "مجموعة اختبارات المورّد" (VTS) في Android 9 طريقة وقت التشغيل لاستخدام إعدادات الجهاز من أجل تحديد اختبارات VTS التي يجب تخطّيها على الجهاز المستهدف.

مرونة اختبار VTS

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

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

أنواع اختبارات VTS

يتضمّن VTS أنواع الاختبارات التالية:

• تضمن اختبارات الامتثال التوافق بين أقسام إطار العمل وأقسام المورّد. ويجب إجراء هذه الاختبارات (واجتيازها) على الأجهزة التي تعمل بالإصدار 8.0 من نظام التشغيل Android أو الإصدارات الأحدث.
• تساعد اختبارات عدم الامتثال المورّدين في تحسين جودة المنتجات (الأداء/التشويش وما إلى ذلك). هذه الاختبارات اختيارية للمورّدين.

يعتمد ما إذا كان الاختبار اختبار امتثال أم لا على الخطة التي ينتمي إليها. تُعد الاختبارات التي يتم تنفيذها باستخدام خطة VTS اختبارات امتثال.

تحديد حِزم HAL المتوافقة

يمكن أن يستخدم VTS الملفات التالية لتحديد ما إذا كان الجهاز المستهدف يتوافق مع طبقة تجريد أجهزة معيّنة:

• ‫/system/compatibility_matrix.xml: يطالب مثيلات HAL التي يتطلبها إطار العمل. مثال:

  <hal format="hidl" optional="true">
      <name>android.hardware.vibrator</name>
      <version>1.0-1</version>
      <interface>
         <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • تشير السمة optional إلى ما إذا كان إطار العمل يتطلّب استخدام طبقة تجريد الأجهزة (HAL) بشكل صارم.
  • قد يحتوي الملف على إدخالات متعددة لنفس طبقة تجريد الأجهزة (HAL) (بالاسم نفسه) ولكن بإصدارات وواجهات مختلفة.
  • قد يحتوي الملف على إعدادات version متعددة للإدخال نفسه، ما يشير إلى أنّ إطار العمل يمكنه العمل مع إصدارات مختلفة.
  • يشير version1.0-1 إلى أنّ إطار العمل يمكنه العمل مع الإصدار 1.0 الأدنى، ولا يتطلّب إصدارًا أعلى من 1.1.
• الجهاز manifest.xml تطالب هذه السمة بمثيلات HAL التي يوفّرها المورّد. مثال:

  <hal format="hidl">
      <name>android.hardware.vibrator</name>
      <transport>hwbinder</transport>
      <version>1.2</version>
      <interface>
          <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • قد يحتوي الملف على إدخالات متعددة لنفس طبقة تجريد الأجهزة (HAL) (بالاسم نفسه) ولكن بإصدارات وواجهات مختلفة.
  • إذا كان الملف يحتوي على version إعداد واحد لأحد الإدخالات، يعني version1.2 أنّ المورّد يتيح جميع الإصدارات من 1.0 إلى 1.2.
• lshal أداة على الجهاز تعرض معلومات وقت التشغيل حول خدمات HAL المسجّلة في hwservicemanager مثال:

  android.hardware.vibrator@1.0::IVibrator/default

  تعرض
  lshal أيضًا جميع طبقات تجريد الأجهزة التي تتضمّن عمليات تنفيذ للوظيفة "نقل البيانات" (أي التي تتضمّن ملف -impl.so المقابل على الجهاز). مثال:

  android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
  android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

اختبارات الامتثال

بالنسبة إلى اختبارات التوافق، يعتمد VTS على بيان المورّد لتحديد (واختبار) جميع مثيلات HAL التي يوفّرها الجهاز. مسار اتخاذ القرار:

اختبارات عدم الامتثال

بالنسبة إلى اختبارات عدم الامتثال، تعتمد مجموعة VTS على بيان المورّد ونتائج lshal لتحديد (واختبار) حِزم HAL التجريبية التي لم يتم الإفصاح عنها في ملف manifest.xml. مسار اتخاذ القرار:

تحديد موقع ملف بيان المورّد

يبحث VTS عن ملف manifest.xml الخاص بالمورّد في المواقع التالية بالترتيب التالي:

1. /vendor/etc/vintf/manifest.xml + بيان ODM (إذا تم تحديد HAL نفسه في كلا المكانين، سيحل بيان ODM محل البيان في /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. ملف ODM manifest.xml، تم تحميله من الملفات التالية بالترتيب التالي:
   1. /odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
   2. /odm/etc/vintf/manifest.xml
   3. /odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
   4. /odm/etc/manifest.xml
   5. /vendor/manifest.xml

أداة التحقّق من إمكانية إجراء اختبارات VTS

vts_testibility_checker هو ملف ثنائي مضمّن في VTS ويستخدمه إطار عمل اختبار VTS في وقت التشغيل لتحديد ما إذا كان اختبار HAL معيّن قابلاً للاختبار أم لا. ويستند إلى libvintf لتحميل ملف بيان المورِّد وتحليله، كما ينفّذ مسار اتخاذ القرار الموضّح في القسم السابق.

لاستخدام vts_testability_check:

• بالنسبة إلى اختبار الامتثال:

  vts_testability_check -c -b <bitness>  <hal@version>

• بالنسبة إلى اختبار عدم الامتثال:

  vts_testability_check -b <bitness>  <hal@version>

يكون الناتج من vts_testability_check بالتنسيق التالي:

{testable: <True/False> Instances: <list of instance names of HAL service>}

تحديد حِزم HAL التي تم الوصول إليها

لتحديد حِزم HAL التي تصل إليها اختبارات VTS، تأكَّد من أنّ كل اختبار HAL يستخدم نموذج VtsHalHidlTargetTestEnvBase لتسجيل حِزم HAL التي يتم الوصول إليها في الاختبار. يمكن لإطار عمل اختبار VTS استخراج وحدات HAL المسجّلة عند إجراء المعالجة المسبقة للاختبار.

بالنسبة إلى اختبارات التوافق، يمكنك أيضًا الاطّلاع على /system/etc/vintf/manifest.xml. إذا تم تحديد HAL هنا، يجب أن يختبر VTS ذلك. (بالنسبة إلى خدمات HAL التي يوفّرها النظام (مثل graphics.composer/vr)، يتم تعريف طبقات HAL في /system/manifest.xml).