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 quel dispositivo target.

Flessibilità del test VTS

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

  • Se un dispositivo specifico non supporta un HAL di test (ad es. IR), VTS non deve eseguire test per questo test HAL sul dispositivo di destinazione.
  • 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.

Il fatto che un test sia o meno un test di conformità dipende al piano a cui appartiene. Test eseguiti con i piani VTS sono considerati test di conformità.

Determinare gli HAL supportati

VTS può utilizzare i seguenti file per determinare se il dispositivo di destinazione supporta un HAL specifico:

  • /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, a indicare 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 di runtime sui servizi HAL registrati con il hwservicemanager. Esempio: 
    android.hardware.vibrator@1.0::IVibrator/default
    lshal mostra anche tutti gli HAL con implementazioni passthrough (ovvero con il file -impl.so corrispondente sul 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 della testabilità per la conformità

Figura 1. Verifica della testabilità per i test di conformità VTS

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:

Controllo di verificabilità per non conformità

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

Individuare il manifest del fornitore

VTS cerca il file manifest.xml del fornitore nei seguenti luoghi e nell'ordine indicato di seguito:

  1. /vendor/etc/vintf/manifest.xml + manifest ODM (se lo stesso HAL è definito in entrambi i posti, il manifest ODM sostituisce quello in /vendor/etc/vintf/manifest.xml)
  2. /vendor/etc/vintf/manifest.xml
  3. File ODM manifest.xml, caricato dai seguenti file nell'ordine seguente:
    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 testabilità VTS

vts_testibility_checker è un file binario pacchettizzato con VTS e utilizzato dal framework di test VTS in fase di esecuzione per determinare se un determinato test HAL è testabile o meno. Si basa su libvintf per caricare e analizzare il file manifest del fornitore e implementa il flusso decisionale descritto 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 mancata conformità: 
    vts_testability_check -b <bitness>  <hal@version>

L'output di vts_testability_check utilizza il seguente formato JSON: 

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

Determina gli HAL a cui è stato eseguito l'accesso

Per determinare a quali HAL viene eseguito l'accesso dai test VTS, assicurati che ogni test HAL utilizzi il modello VtsHalHidlTargetTestEnvBase per registrare gli HAL a cui viene eseguito l'accesso 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 qui è definito un HAL, il VTS deve testarlo. Per i servizi HAL forniti dal sistema (ad es. graphics.composer/vr), gli HAL sono dichiarati in /system/manifest.xml.