בדיקת יכולת בדיקת HAL

חבילת בדיקות הספק (VTS) של Android 9 תומכת בשיטה של זמן ריצה שמאפשרת להשתמש בהגדרות המכשיר כדי לזהות אילו בדיקות VTS צריך לדלג עליהן עבור יעד המכשיר הזה.

גמישות בבדיקת VTS

החל מגרסה Android 8.0, בדיקות VTS נדרשות לכל המכשירים שהושקו עם Android מגרסה 8.0 ואילך. עם זאת, לא כל בדיקות VTS חלות על כל יעדי המכשירים. לדוגמה:

• אם מכשיר ספציפי לא תומך ב-HAL לבדיקה (למשל IR), ל-VTS אין צורך להריץ בדיקות של בדיקת ה-HAL הזו נגד היעד של המכשיר הזה.
• אם לכמה מכשירים יש אותה תמונה של ספק SoC ואותה תמונה של ספק, אבל יש להם פונקציות חומרה שונות, VTS צריך לקבוע אם צריך להריץ בדיקה או לדלג על יעד מכשיר ספציפי.

סוגי בדיקות VTS

VTS כולל את סוגי הבדיקות הבאים:

• בדיקות תאימות מבטיחות תאימות בין המסגרת לבין המחיצות של הספקים. צריך להריץ את הבדיקות האלה (ולעבור אותן) במכשירים שפועלת בהם גרסת Android 8.0 ואילך.
• בדיקות אי-תאימות עוזרות לספקים לשפר את איכות המוצרים (ביצועים, בדיקות fuzzing וכו'). הספקים יכולים לבצע את הבדיקות האלה באופן אופציונלי.

בדיקה אם בדיקה היא בדיקת תאימות או לא תלויה בתוכנית שאליה היא שייכת. בדיקות שפועלות עם תוכנית 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 היא שה-framework יכול לפעול עם הגרסה הנמוכה ביותר 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

בדיקות אי-תאימות

בבדיקות של אי-תאימות, VTS מסתמך על המניפסט של הספק ועל הפלט של lshal כדי לקבוע (ולבדוק) את ה-HALs הניסיוניים שלא צוינו בקובץ 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. קובץ manifest.xml של ODM, שנטען מהקבצים הבאים בסדר הבא:
   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 יש גישה

כדי לקבוע לאילו HALs מתבצעת גישה על ידי בדיקות VTS, צריך לוודא שכל בדיקת HAL משתמשת בתבנית VtsHalHidlTargetTestEnvBase כדי לרשום את ה-HALs שנגישים בבדיקה. לאחר מכן, ה-framework של בדיקת VTS יכול לחלץ את רכיבי ה-HAL הרשומים במהלך עיבוד הבדיקה מראש.

אפשר גם לבדוק את /system/etc/vintf/manifest.xml לבדיקות תאימות. אם HAL מוגדר כאן, VTS צריך לבדוק אותו. (לשירותי HAL שמסופקים על ידי המערכת (למשל graphics.composer/vr), אישורי HAL מוצהרים ב-/system/manifest.xml.)