Controllo della testabilità dell'HAL

La Test Suite del fornitore di Android 9 (VTS) supporta una metodo di runtime per utilizzare la configurazione del dispositivo al fine di identificare quali test VTS deve essere ignorato per il targeting per dispositivo.

Flessibilità del test VTS

A partire da Android 8.0, i test VTS sono richiesti per tutti i dispositivi lanciati con Android 8.0 e versioni successive. Tuttavia, non tutti i test VTS si applicano a tutti i dispositivi target. Ad esempio:

  • Se un dispositivo specifico non supporta un HAL di test (ad es. IR), VTS non è necessario eseguire test per il test HAL in base al dispositivo target.
  • Se più dispositivi condividono lo stesso SoC e la stessa immagine del fornitore, ma funzionalità hardware diverse, VTS deve determinare se un test deve essere eseguito o ignorato per un dispositivo target specifico.

Tipi di test VTS

VTS include i seguenti tipi di test:

  • I test di conformità garantiscono la compatibilità tra framework e alle partizioni dei fornitori. Questi test devono essere eseguiti (e superati) su dispositivi con Android 8.0 o versioni successive.
  • I test di non conformità aiutano i fornitori a migliorare il prodotto qualità (prestazioni/fuzzing ecc.). Questi test sono facoltativi per i fornitori.

La presenza o meno di un test di conformità dipende dal piano a cui appartiene a. Test eseguiti con i piani VTS sono considerati test di conformità.

Determinare gli HAL supportati

VTS può utilizzare i file riportati di seguito per determinare se il dispositivo target supporta un uno specifico HAL:

  • /system/compatibility_matrix.xml. Rivendica le istanze HAL come richiesto dal framework. Esempio:
    <hal format="hidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1.0-1</version>
        <interface>
           <name>IVibrator</name>
           <instance>default</instance>
        </interface>
    </hal>
    
    • L'attributo optional indica se l'HAL è strettamente come richiesto dal framework.
    • Il file può contenere più voci per lo stesso HAL (con lo stesso nome) ma con versioni e interfacce diverse.
    • Il file può contenere più configurazioni version per la stessa voce, indicando che il framework può funzionare con versioni diverse.
    • version1.0-1 significa che il framework può funzionare con il livello versione 1.0 e non richiede una versione successiva alla 1.1.
  • Dispositivo manifest.xml. Rivendica le istanze HAL fornite dal di terze parti. Esempio:
    <hal format="hidl">
        <name>android.hardware.vibrator</name>
        <transport>hwbinder</transport>
        <version>1.2</version>
        <interface>
            <name>IVibrator</name>
           <instance>default</instance>
        </interface>
    </hal>
    
    • Il file può contenere più voci per lo stesso HAL (con lo stesso nome) ma con versioni e interfacce diverse.
    • Se il file contiene una sola configurazione di version per una voce, version1.2 significa che il fornitore supporta tutte le versioni da 1,0 a 1,2.
  • lshal. Uno strumento sul dispositivo che mostra informazioni sul runtime i servizi HAL registrati con hwservicemanager. Esempio:
    android.hardware.vibrator@1.0::IVibrator/default
    

    lshal mostra anche tutti gli HAL con passthrough implementazioni (ovvero avere il file -impl.so corrispondente del dispositivo). Esempio:
    android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
    android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)
    

Test di conformità

Per i test di conformità, VTS si basa sul file manifest del fornitore per determinare (e test) di tutte le istanze HAL fornite dal dispositivo. Flusso decisionale:

Verifica di conformità della verificabilità

Figura 1. Controllo della verificabilità per i test di conformità VTS
di Gemini Advanced.

Test di non conformità

Per i test di non conformità, VTS si basa sul file manifest del fornitore lshal produce risultati per determinare (e testare) gli HAL sperimentali non rivendicati nel file manifest.xml. Flusso decisionale:

Verifica della verificabilità per mancata conformità

Figura 2. Controllo di verificabilità per non conformità VTS test
di Gemini Advanced.

Individuare il manifest del fornitore

VTS verifica il file manifest.xml del fornitore nei seguenti campi va nel seguente ordine:

  1. /vendor/etc/vintf/manifest.xml + manifest ODM (se lo stesso HAL) viene definito in entrambe le posizioni, il manifest ODM sostituisce quello specificato /vendor/etc/vintf/manifest.xml)
  2. /vendor/etc/vintf/manifest.xml
  3. File ODM manifest.xml, caricato dai seguenti file in nel seguente ordine:
    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

Strumento di verifica della verificabilità VTS

La vts_testibility_checker è un file binario pacchettizzato con VTS e utilizzato da il framework di test VTS in fase di runtime per determinare se un determinato test HAL viene testabile o meno. Si basa su libvintf per caricare e analizzare il file manifest del fornitore e implementa il flusso decisionale descritti nella sezione precedente.

Per usare vts_testability_check:

  • Per un test di conformità:
    vts_testability_check -c -b <bitness>  <hal@version>
    
  • Per un test di non conformità:
    vts_testability_check -b <bitness>  <hal@version>
    

L'output di vts_testability_check utilizza il seguente json formato:

{testable: <True/False> Instances: <list of instance names of HAL service>}

Determinare gli HAL a cui è stato eseguito l'accesso

Per determinare a quali HAL accedono i test VTS, assicurati che ogni test HAL utilizza VtsHalHidlTargetTestEnvBase per registrare gli HAL a cui si accede nel test. Il test VTS può quindi estrarre gli HAL registrati durante la pre-elaborazione del test.

Per i test di conformità, puoi anche /system/etc/vintf/manifest.xml. Se in questo campo viene definito un HAL, dovresti testarlo. (Per i servizi HAL forniti dal sistema (ad es. graphics.composer/vr), gli HAL vengono dichiarati in /system/manifest.xml.