Controllo della testabilità dell'HAL

La suite di test del fornitore (VTS) di Android 9 supporta un metodo di runtime per l'utilizzo della configurazione del dispositivo per identificare i test VTS da saltare per il dispositivo di destinazione.

Flessibilità dei 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 diversi dispositivi condividono lo stesso SoC e la stessa immagine del fornitore, ma hanno 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 il framework e le partizioni del fornitore. Questi test devono essere eseguiti (e superati) sui dispositivi lanciati con Android 8.0 o versioni successive.
  • I test di non conformità aiutano i fornitori a migliorare la qualità del prodotto (prestazioni/fuzzing e così via). 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. I test eseguiti con il piano 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 richieste 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 obbligatoria per il 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 indica che il framework può funzionare con la versione minima 1.0 e non richiede una versione superiore a 1.1.
  • Dispositivo manifest.xml. Rivendica le istanze HAL fornite dal fornitore. 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 version per una voce, version1.2 significa che il fornitore supporta tutte le versioni dalla 1.0 alla 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 manifest del fornitore per determinare (e testare) tutte le istanze HAL fornite dal dispositivo. Flusso decisionale:

Verifica di conformità della verificabilità

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

Test di non conformità

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

Verifica della testabilità per la mancata conformità

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

Individuare il manifest del fornitore

VTS cerca il file manifest.xml del fornitore nei seguenti luoghi e nel seguente ordine:

  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 runtime 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 non 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 accedono i test VTS, assicurati che ogni test HAL utilizzi il modello VtsHalHidlTargetTestEnvBase per registrare gli HAL a cui si accede nel test. Il framework di test VTS può quindi estrarre gli HAL registrati durante la preelaborazione del test.

Per i test di conformità, puoi anche controllare /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 vengono dichiarati in /system/manifest.xml.