اختبار قابلية اختبار HAL

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

مرونة اختبار الفيديوهات

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

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

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

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

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

يعتمد ما إذا كان الاختبار اختبار امتثال أم لا على الخطة التي ينتمي إليها. تُعدّ الاختبارات التي يتم إجراؤها باستخدام خطة اختبار الأداء والتوافق اختبارات الامتثال.

تحديد واجهات برمجة التطبيقات (HAL) المتوافقة

يمكن أن تستخدم أداة فحص الأجهزة للتوافق مع معايير Google Play (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 أيضًا جميع واجهات HAL التي تتضمّن عمليات تنفيذ للمرور المباشر (أي توفُّر ملف -impl.so المقابل على الجهاز). مثال:

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

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

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

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

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

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

تبحث أداة التحقّق من المحتوى في الفيديو عن ملف 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_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 تنسيق json التالي:

{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.)