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

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

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

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

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

סוגי בדיקות VTS

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

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

בדיקה אם בדיקה היא בדיקת תאימות או לא תלויה בתוכנית שאליה היא שייכת ל. בדיקות שמבוצעות עם תוכנית VTS נחשבת כבדיקות תאימות.

הגדרה של רכיבי HAL נתמכים

VTS יכול להשתמש בקבצים הבאים כדי לקבוע אם יעד המכשיר תומך HAL ספציפי:

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

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