بررسی آزمایش پذیری HAL

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

انعطاف پذیری تست VTS

از اندروید 8.0، تست های VTS برای همه دستگاه هایی که با اندروید 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 به این معنی است که چارچوب می تواند با پایین ترین نسخه 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 پشتیبانی می‌کند.
• لشال . ابزاری در دستگاه که اطلاعات زمان اجرا را در مورد خدمات HAL ثبت شده در hwservicemanager نشان می دهد. مثال:

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

  
  lshal همچنین تمام HAL هایی را که با اجرای passthrough (یعنی داشتن فایل -impl.so مربوطه در دستگاه) نشان می دهد. مثال:

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

تست های انطباق

برای آزمایش‌های انطباق، VTS برای تعیین (و آزمایش) تمام نمونه‌های HAL ارائه‌شده توسط دستگاه به مانیفست فروشنده متکی است. جریان تصمیم گیری:

تست های عدم انطباق

برای آزمایش‌های عدم انطباق، VTS برای تعیین (و آزمایش) HAL‌های آزمایشی که در فایل manifest.xml ادعا نشده‌اند، به مانیفست فروشنده و خروجی‌های lshal متکی است. جریان تصمیم گیری:

مانیفست فروشنده را پیدا کنید

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>}

HAL های قابل دسترسی را تعیین کنید

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

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