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 saltati per quel dispositivo di destinazione.

Flessibilità del test VTS

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

• Se un dispositivo specifico non supporta un HAL di test (ad esempio IR), VTS non ha bisogno di eseguire test per quel test HAL su quella destinazione del dispositivo.
• Se diversi dispositivi condividono lo stesso SoC e l'immagine del fornitore ma hanno funzionalità hardware diverse, VTS deve determinare se un test deve essere eseguito o ignorato per un dispositivo di destinazione 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. È necessario eseguire (e superare) questi test sui dispositivi avviati con Android 8.0 o versioni successive.
• I test di non conformità aiutano i fornitori a migliorare la qualità del prodotto (prestazioni/fuzzing, ecc.). Questi test sono facoltativi per i fornitori.

Il fatto che un test sia o meno un test di conformità 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 dispositivo di destinazione 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 versione e interfacce diverse.
  • Il file può contenere più configurazioni version per la stessa voce, indicando che il framework può funzionare con versioni diverse.
  • version1.0-1 significa che il framework può funzionare con la versione più bassa 1.0 e non richiede una versione successiva alla 1.1.
• manifest.xml del dispositivo. Richiede 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 versione e interfacce diverse.
  • Se il file contiene solo una singola 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 sui servizi HAL registrati con hwservicemanager . Esempio:

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

  
  lshal mostra anche tutti gli HAL che hanno implementazioni passthrough (cioè hanno 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/)
  

Prove di conformità

Per i test di conformità, VTS si basa sul manifesto 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) gli HAL sperimentali non dichiarati nel file manifest.xml . Flusso decisionale:

Individuare il manifesto del fornitore

VTS ricerca il file manifest.xml del fornitore nei seguenti posti nel seguente ordine:

1. /vendor/etc/vintf/manifest.xml + manifesto ODM (se lo stesso HAL è definito in entrambe le posizioni, il manifesto ODM sovrascrive quello 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

Controllo della testabilità VTS

vts_testibility_checker è un file binario confezionato 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 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 si è avuto accesso

Per determinare a quali HAL si accede dai test VTS, assicurarsi che ciascun 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 pre-elaborazione del test.

Per i test di conformità, puoi anche controllare /system/etc/vintf/manifest.xml . Se qui viene definito un HAL, VTS dovrebbe testarlo. (Per i servizi HAL forniti dal sistema (ad esempio graphics.composer/vr ), gli HAL sono dichiarati in /system/manifest.xml .)