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:

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:

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.