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

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

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

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

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

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

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

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

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

تحديد HALs المتوافقة

وبإمكان 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 التي يقدمها الجهاز. مسار القرار:

الشكل 1. التحقّق من إمكانية إجراء اختبارات الامتثال لنظام VTS

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

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

الشكل 2: التحقّق من إمكانية اختبار عدم امتثال VTS الاختبارات

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

تتحقق 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 ملف json التالي. التنسيق:

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

تحديد HALs التي تم الوصول إليها

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

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