بررسی قابلیت آزمایش HAL

«مجموعه آزمون فروشنده» (VTS) در Android 9 از روش زمان اجرایی برای استفاده از پیکربندی دستگاه جهت شناسایی آزمون‌های VTS که باید برای هدف دستگاه رد شوند پشتیبانی می‌کند.

انعطاف‌پذیری آزمایش VTS

از Android 8.0، تست‌های VTS برای همه دستگاه‌هایی که با Android 8.0 و بالاتر عرضه می‌شوند الزامی است. بااین‌حال، همه آزمون‌های VTS برای همه هدف‌های دستگاه اعمال نمی‌شود. برای مثال:

• اگر دستگاه خاصی از HAL آزمایشی (مثلاً IR) پشتیبانی نکند، VTS نیازی به اجرای آزمایش برای آن آزمایش HAL درمقابل آن هدف دستگاه ندارد.
• اگر چند دستگاه SoC و تصویر فروشنده یکسانی داشته باشند اما عملکردهای سخت‌افزاری متفاوتی داشته باشند، VTS باید تعیین کند که آیا آزمایشی باید برای هدف دستگاه خاصی اجرا شود یا از آن رد شود.

انواع آزمایش VTS

‫VTS شامل انواع آزمون زیر است:

• آزمایش‌های رعایت استانداردها سازگاری بین چارچوب و پارتیشن‌های فروشنده را تضمین می‌کند. این آزمایش‌ها باید در دستگاه‌هایی که با Android نسخه ۸.۰ یا بالاتر عرضه می‌شوند اجرا شوند (و موفقیت‌آمیز باشند).
• آزمایش‌های عدم رعایت استانداردها به فروشندگان کمک می‌کند کیفیت محصول (عملکرد/تست‌های فازینگ و غیره) را بهبود دهند. این آزمایش‌ها برای فروشندگان اختیاری است.

اینکه آزمایشی آزمون رعایت استانداردها باشد یا نه به طرحی که به آن تعلق دارد بستگی دارد. آزمایش‌هایی که با طرح VTS اجرا می‌شوند آزمایش‌های انطباق درنظر گرفته می‌شوند.

تعیین HALهای پشتیبانی‌شده

‫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 یعنی چارچوب می‌تواند با پایین‌ترین نسخه ۱٫۰ کار کند و به نسخه‌ای بالاتر از ۱٫۱ نیاز ندارد.
• دستگاه 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 یعنی فروشنده از همه نسخه‌های ۱.۰ تا ۱.۲ پشتیبانی می‌کند.
• 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 ارائه‌شده توسط دستگاه به مانیفست فروشنده متکی است. جریان تصمیم‌گیری:

آزمایش‌های عدم رعایت استانداردها

برای آزمایش‌های عدم‌رعایت، 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. فایل 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>}

تعیین کردن HALهای دسترسی‌پذیر

برای تعیین اینکه تست‌های VTS به کدام HALها دسترسی دارند، مطمئن شوید که هر تست HAL از الگوی VtsHalHidlTargetTestEnvBase برای ثبت HAL(های) دسترسی‌یافته در تست استفاده می‌کند. چارچوب آزمایش VTS می‌تواند HALهای ثبت‌شده را هنگام پیش‌پردازش آزمایش استخراج کند.

برای آزمون‌های رعایت استانداردها، می‌توانید /system/etc/vintf/manifest.xml را نیز بررسی کنید. اگر HAL در اینجا تعریف شده باشد، VTS باید آن را آزمایش کند. (برای سرویس‌های HAL ارائه‌شده توسط سیستم (برای نمونه، graphics.composer/vr)، ‫HAL در /system/manifest.xml اعلام می‌شود.)