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

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