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

مجموعه تست فروشندگان اندروید ۹ (VTS) از یک روش زمان اجرا برای استفاده از پیکربندی دستگاه پشتیبانی می‌کند تا مشخص شود کدام تست‌های VTS باید برای آن دستگاه هدف نادیده گرفته شوند.

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

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

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

انواع تست VTS

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

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

اینکه یک تست، تست انطباق باشد یا خیر، بستگی به این دارد که به کدام طرح تعلق دارد. تست‌هایی که با طرح 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هایی را که با پیاده‌سازی‌های passthrough (یعنی داشتن فایل -impl.so مربوطه روی دستگاه) اجرا می‌شوند، نشان می‌دهد. مثال:

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

آزمون‌های انطباق

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

آزمایش‌های عدم انطباق

برای تست‌های عدم انطباق، VTS به خروجی‌های manifest فروشنده و 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 برای بارگذاری و تجزیه فایل manifest فروشنده است و جریان تصمیم‌گیری شرح داده شده در بخش قبلی را پیاده‌سازی می‌کند.

برای استفاده از 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 تعریف شده‌اند.)