Controllo della testabilità HAL

La Vendor Test Suite (VTS) di Android 9 supporta un metodo di runtime per utilizzare la configurazione del dispositivo per identificare quali test VTS devono essere ignorati per la destinazione del dispositivo.

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 dei dispositivi. Ad esempio:

• Se un dispositivo specifico non supporta un HAL di test (ad es. IR), VTS non deve eseguire test per quel test HAL sul target del dispositivo.
• Se più 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 una specifica destinazione del dispositivo.

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 con Android 8.0 o versioni successive.
• I test di non conformità aiutano i fornitori a migliorare la qualità dei prodotti (rendimento/fuzzing e così via). Questi test sono facoltativi per i fornitori.

Se un test è un test di conformità o meno dipende dal 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 la destinazione del dispositivo supporta un HAL specifico:

• /system/compatibility_matrix.xml. Richiede 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 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 potrebbe 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 la versione 1.0 più bassa e non richiede una versione superiore alla 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 sul runtime dei servizi HAL registrati con hwservicemanager. Esempio:

  android.hardware.vibrator@1.0::IVibrator/default

  
  lshal mostra anche tutte le 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:

Test di non conformità

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

Individuare il manifest del fornitore

VTS verifica la presenza del file manifest.xml del fornitore nei seguenti percorsi nel seguente ordine:

1. /vendor/etc/vintf/manifest.xml + manifest ODM (se la stessa HAL è definita in entrambi i punti, il manifest ODM sostituisce quella in /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. File ODM manifest.xml, caricato dai seguenti file 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 controllo della testabilità VTS

vts_testibility_checker è un binario incluso in 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>}

Determinare i livelli di astrazione hardware 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 viene eseguito l'accesso nel test. Il framework di test VTS può quindi estrarre gli HAL registrati durante la pre-elaborazione del test.

Per i test di conformità, puoi anche controllare /system/etc/vintf/manifest.xml. Se qui è definita una HAL, VTS deve testarla. Per i servizi HAL forniti dal sistema (ad es. graphics.composer/vr), gli HAL sono dichiarati in /system/manifest.xml.