Controllo della testabilità HAL

Android 9 Vendor Test Suite (VTS) supporta un metodo di runtime per utilizzare la configurazione del dispositivo per identificare quali test VTS devono essere ignorati per il target 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 un target del dispositivo specifico.

Tipi di test VTS

VTS include i seguenti tipi di test:

• I test di conformità garantiscono la compatibilità tra le partizioni del framework e del fornitore. Questi test devono essere eseguiti (e superati) sui dispositivi lanciati con Android 8.0 o versioni successive.
• I test dinon conformità aiutano i fornitori a migliorare la qualità del prodotto (rendimento/fuzzing e così via). Questi test sono facoltativi per i fornitori.

Se 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 il target del dispositivo 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 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ù version configurazioni per la stessa voce, il che indica che il framework può funzionare con versioni diverse.
  • version1.0-1 significa che il framework può funzionare con la versione più bassa versione 1.0 e non richiede una versione superiore a 1.1.
• manifest.xml del dispositivo. 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 da 1.0 a 1.2.
• lshal. Uno strumento sul dispositivo che mostra informazioni di runtime su i 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 test) 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) gli HAL sperimentali non rivendicati nel file manifest.xml. Flusso decisionale:

Individuare il manifest del fornitore

VTS controlla il file manifest.xml del fornitore nei seguenti percorsi, nel seguente ordine:

1. /vendor/etc/vintf/manifest.xml + manifest ODM (se lo stesso HAL è definito in entrambi i percorsi, il manifest ODM sostituisce quello in /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. File manifest.xml ODM, 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

Controllo della testabilità VTS

The vts_testibility_checker è un file binario incluso in VTS e utilizzato da VTS test framework 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 utilizzare 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 gli HAL a cui è stato eseguito l'accesso

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