בדיקת HAL עם התאמה לשם השירות

‫Android 9 כולל תמיכה בהשגת שם השירות של מופע HAL נתון על סמך המכשיר שבו מופעלות בדיקות Vendor Test Suite‏ (VTS). הפעלת בדיקות VTS HAL שמודעות לשם השירות מאפשרת למפתחים לבצע אוטומציה של בדיקות הרחבות של ספקים, של כמה HAL ושל כמה מופעים של HAL בהרצות בדיקות VTS בצד היעד ובצד המארח.

מידע על שמות שירותים

כל מופע של שירות HAL שפועל נרשם עם שם שירות.

בגרסאות קודמות של Android, מפתחים שהריצו בדיקות VTS HAL נדרשו להגדיר את שם השירות הנכון עבור לקוח הבדיקה ב-getService() או להשאיר את השם ריק ולחזור לשם השירות שמוגדר כברירת מחדל. החסרונות של הגישה הזו כוללים:

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

ב-Android 9, מפתחים יכולים לקבל באופן אוטומטי את שם השירות של מופע HAL נתון על סמך המכשיר שנבדק. היתרונות של הגישה הזו כוללים תמיכה בבדיקות:

• Vendor HAL extensions. לדוגמה, אם לספק יש הטמעה של camera.provider HAL שפועלת במכשירי הספק עם שם שירות מותאם אישית, VTS יכול לזהות את מופע הספק ולהריץ את הבדיקה מולו.
• Multiple HAL instances (כמה מופעים של HAL). לדוגמה, אם ל-graphics.composer HAL יש שני מופעים (אחד עם שם השירות default ואחד עם שם השירות vr), ‏ VTS יכול לזהות את שני המופעים ולהריץ את הבדיקה על כל אחד מהם.
• בדיקות של Multi-HAL. השימוש באפשרות הזו מתאים לבדיקה של כמה HAL עם כמה מופעים. לדוגמה, כשמריצים את בדיקת VTS שמאמתת את אופן הפעולה של KeyMint (לשעבר Keymaster) ו-Gatekeeper HAL ביחד, VTS יכול לבדוק את כל השילובים של מופעי שירות עבור ה-HAL האלה.

בדיקות בצד היעד

כדי להפעיל את ההגדרה 'מודעות לשם השירות' לבדיקות בצד היעד, Android 9 כולל סביבת בדיקה שניתנת להתאמה אישית (VtsHalHidlTargetTestEnvBase) שמספקת ממשקי API ל:

• רושמים את ה-HAL(ים) לטירגוט בבדיקה.
• מציינים את כל רכיבי ה-HAL הרשומים.
• קבלת שמות של שירותים עבור HAL רשומים שסופקו על ידי מסגרת VTS.

בנוסף, ה-framework של VTS מספק תמיכה בזמן ריצה עבור:

• ביצוע עיבוד מקדים לקובץ הבינארי של הבדיקה כדי לקבל את כל ה-HAL של הבדיקה הרשומים.
• זיהוי כל המכונות של השירות שפועלות וקבלת שם השירות של כל מכונה (השם מאוחזר על סמך vendor/manifest.xml).
• חישוב כל השילובים של המכונות (כדי לתמוך בבדיקות של כמה HAL).
• יצירת בדיקה חדשה לכל מופע (שילוב) של שירות.

דוגמה:

הגדרה של בדיקות בצד היעד שמודעות לשם השירות

כדי להגדיר את סביבת הבדיקה לבדיקה עם מודעות לשם השירות בצד היעד:

1. מגדירים testEnvironment על סמך VtsHalHidlTargetTestEnvBase ורושמים בדיקות HAL:

   #include <VtsHalHidlTargetTestEnvBase.h>
   class testEnvironment  : public::testing::VtsHalHidlTargetTestEnvBase {
         virtual void registerTestServices() override {
       registerTestService<IFoo>();
         }
   };

2. משתמשים ב-getServiceName() שסופק על ידי סביבת הבדיקה כדי להעביר את שם השירות:

   ::testing::VtsHalHidlTargetTestBase::getService<IFoo>(testEnv->getServiceName<IFoo>("default"));
   // "default" is the default service name you want to use.

3. רושמים את סביבת הבדיקה ב-main() וב-initTest:

   int main(int argc, char** argv) {
           testEnv = new testEnvironment();
           ::testing::AddGlobalTestEnvironment(testEnv);
           ::testing::InitGoogleTest(&argc, argv);
           testEnv->init(argc, argv);
           return RUN_ALL_TESTS();
   }

דוגמאות נוספות זמינות במאמר VtsHalCameraProviderV2_4TargetTest.cpp.

בדיקות בצד המארח של VTS

בדיקות בצד המארח של VTS מריצות סקריפטים של בדיקות בצד המארח במקום קבצים בינאריים של בדיקות במכשיר היעד. כדי להפעיל את ההגדרה 'שם השירות' בבדיקות האלה, אפשר להשתמש בתבניות בצד המארח כדי להריץ את אותו סקריפט בדיקה כמה פעמים עם פרמטרים שונים (בדומה לבדיקה עם פרמטרים של gtest).

• סקריפט בדיקת ה-HAL מציין את שירותי ה-HAL לטירגוט בבדיקה.
• הפונקציה hal_hidl_host_test (מחלקת משנה של param_test) מקבלת את ה-HAL(s) הרשומים לבדיקה מסקריפט הבדיקה, מזהה את שמות השירותים התואמים ל-HAL לבדיקה, ואז יוצרת שילובים של שמות שירותים (לבדיקה של כמה HAL) כפרמטרים של הבדיקה. היא גם מספקת שיטה getHalServiceName() שמחזירה את שם השירות המתאים בהתאם לפרמטר שמועבר לתרחיש הבדיקה הנוכחי.
• תבנית param_test תומכת בלוגי לקבלת רשימת פרמטרים ולהרצת כל מקרי הבדיקה שצוינו מול כל פרמטר. כלומר, לכל מקרה בדיקה נוצרים N מקרי בדיקה חדשים עם פרמטרים (N = גודל הפרמטרים), כל אחד עם פרמטר נתון.

הגדרה של בדיקות בצד המארח שמודעות לשם השירות

כדי להגדיר את סביבת הבדיקה לבדיקה עם מודעות לשם השירות בצד המארח:

1. מציינים את שירות ה-HAL של היעד בסקריפט הבדיקה:

   TEST_HAL_SERVICES = { "android.hardware.foo@1.0::IFoo" }

2. מתקשרים אל getHalServiceName() ומעבירים את השם אל init hal:

   self.dut.hal.InitHidlHal(
               target_type='foo',
               target_basepaths=self.dut.libPaths,
               target_version=1.0,
               target_package='android.hardware.foo',
               target_component_name='IFoo',
               hw_binder_service_name
                     =self.getHalServiceName("android.hardware.foo@1.0::IFoo"),
               bits=int(self.abi_bitness))

דוגמאות נוספות זמינות במאמר VtsHalMediaOmxStoreV1_0HostTest.py.

רישום של שכבות HAL לבדיקה

בגרסאות קודמות של Android, מערכת VTS זיהתה את HAL לבדיקה באמצעות האפשרות <precondition-lshal> שהוגדרה ב-AndroidTest.xml. היה קשה לתחזק את הגישה הזו (כי היא הסתמכה על המפתחים כדי להגדיר את הבדיקה בצורה נכונה ולעדכן את ההגדרה בהתאם) והיא הייתה לא מדויקת (כי היא הכילה רק את חבילת המידע ופרטי הגרסה ולא את פרטי הממשק).

ב-Android 9, ‏ VTS מזהה את HAL של הבדיקה באמצעות מודעות לשם השירות. ממשקי HAL רשומים לבדיקה שימושיים גם למטרות הבאות:

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