التحقّق من قابلية اختبار 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 اختبارات امتثال.

تحديد طبقات تجريد الأجهزة المتوافقة

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

• ‫/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 أيضًا جميع طبقات تجريد الأجهزة التي تتضمّن عمليات تنفيذ للوظيفة passthrough (أي التي تتضمّن ملف -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 التي تصل إليها اختبارات VTS، تأكَّد من أنّ كل اختبار HAL يستخدم نموذج VtsHalHidlTargetTestEnvBase لتسجيل حِزم HAL التي يتم الوصول إليها في الاختبار. يمكن لإطار عمل اختبار VTS استخراج وحدات HAL المسجّلة عند إجراء المعالجة المسبقة للاختبار.

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