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

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