בדיקת יכולת הבדיקה של 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 ומעלה.
  • בדיקות אי-תאימות עוזרות לספקים לשפר את איכות המוצר (ביצועים, בדיקת fuzz וכו'). הבדיקות האלה הן אופציונליות לספקים.

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

בדיקת יכולת הבדיקה לצורך אי-תאימות

איור 2. בדיקת יכולת בדיקה של בדיקות VTS noncompliance tests

איתור מניפסט הספק

הכלי 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 יכולה לחלץ את HALs הרשומים במהלך העיבוד המקדים של הבדיקה.

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