فحص قابلية اختبار HAL

يدعم Android 9 Vendor Test Suite (VTS) طريقة وقت التشغيل لاستخدام تكوين الجهاز لتحديد اختبارات VTS التي يجب تخطيها لهدف الجهاز هذا.

مرونة اختبار VTS

اعتبارًا من نظام التشغيل Android 8.0، أصبحت اختبارات VTS مطلوبة لجميع الأجهزة التي تعمل بنظام التشغيل Android 8.0 والإصدارات الأحدث. ومع ذلك، لا تنطبق جميع اختبارات VTS على جميع أهداف الأجهزة. على سبيل المثال:

  • إذا كان جهاز معين لا يدعم اختبار HAL (مثل IR)، فلا يحتاج VTS إلى تشغيل اختبارات لاختبار HAL هذا مقابل هدف الجهاز هذا.
  • إذا كانت هناك عدة أجهزة تشترك في نفس صورة شركة نفط الجنوب وصورة البائع ولكن لديها وظائف أجهزة مختلفة، فيجب على VTS تحديد ما إذا كان يجب تشغيل الاختبار أو تخطيه لهدف جهاز محدد.

أنواع اختبار VTS

يتضمن VTS أنواع الاختبارات التالية:

  • تضمن اختبارات الامتثال التوافق بين أقسام الإطار والبائعين. يلزم تشغيل هذه الاختبارات (واجتيازها) على الأجهزة التي تعمل بنظام التشغيل Android 8.0 أو أعلى.
  • تساعد اختبارات عدم الامتثال البائعين على تحسين جودة المنتج (الأداء/التشويش وما إلى ذلك). هذه الاختبارات اختيارية للبائعين.

يعتمد ما إذا كان الاختبار بمثابة اختبار امتثال أم لا على الخطة التي ينتمي إليها. تعتبر الاختبارات التي يتم إجراؤها مع خطة VTS بمثابة اختبارات امتثال.

تحديد HALs المدعومة

يمكن لـ 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 الجهاز.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.
  • لشال . أداة على الجهاز تعرض معلومات وقت التشغيل حول خدمات 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 التي يوفرها الجهاز. تدفق القرار:

Testability check for compliance

الشكل 1. فحص قابلية الاختبار لاختبارات الامتثال لـ VTS

اختبارات عدم الامتثال

بالنسبة لاختبارات عدم الامتثال، يعتمد VTS على بيان البائع ومخرجات lshal لتحديد (واختبار) شرائح HALs التجريبية التي لم تتم المطالبة بها في ملف manifest.xml . تدفق القرار:

Testability check for noncompliance

الشكل 2. التحقق من قابلية الاختبار لاختبارات عدم الامتثال لـ VTS

تحديد موقع بيان البائع

يتحقق VTS من ملف manifest.xml للمورد في الأماكن التالية بالترتيب التالي:

  1. /vendor/etc/vintf/manifest.xml + ODM Manifest (إذا تم تعريف 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>}

تحديد HALs التي تم الوصول إليها

لتحديد شرائح HAL التي يتم الوصول إليها عن طريق اختبارات VTS، تأكد من أن كل اختبار HAL يستخدم قالب VtsHalHidlTargetTestEnvBase لتسجيل HAL(s) التي تم الوصول إليها في الاختبار. يمكن لإطار اختبار VTS بعد ذلك استخراج HALs المسجلة عند المعالجة المسبقة للاختبار.

لاختبارات الامتثال، يمكنك أيضًا التحقق من /system/etc/vintf/manifest.xml . إذا تم تعريف HAL ​​هنا، فيجب على VTS اختباره. (بالنسبة لخدمات HAL التي يقدمها النظام (على سبيل المثال graphics.composer/vr )، يتم الإعلان عن HALs في /system/manifest.xml .)