Controllo della testabilità dell'HAL

La Test Suite del fornitore di Android 9 (VTS) supporta una metodo di runtime per utilizzare la configurazione del dispositivo al fine di identificare quali test VTS deve essere ignorato per il targeting per dispositivo.

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

• Se un dispositivo specifico non supporta un HAL di test (ad es. IR), VTS non è necessario eseguire test per il test HAL in base al dispositivo target.
• Se più dispositivi condividono lo stesso SoC e la stessa immagine del fornitore, ma 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 framework e alle partizioni dei fornitori. Questi test devono essere eseguiti (e superati) su dispositivi con Android 8.0 o versioni successive.
• I test di non conformità aiutano i fornitori a migliorare il prodotto qualità (prestazioni/fuzzing ecc.). Questi test sono facoltativi per i fornitori.

La presenza o meno di un test di conformità dipende dal piano a cui appartiene a. Test eseguiti con i piani VTS sono considerati test di conformità.

Determinare gli HAL supportati

VTS può utilizzare i file riportati di seguito per determinare se il dispositivo target supporta un uno specifico HAL:

• /system/compatibility_matrix.xml. Rivendica le istanze HAL come richiesto 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 come 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ù 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 il livello versione 1.0 e non richiede una versione successiva alla 1.1.
• Dispositivo manifest.xml. Rivendica le istanze HAL fornite dal di terze parti. 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 di 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 sul runtime i servizi HAL registrati con hwservicemanager. Esempio:

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

  
  lshal mostra anche tutti gli HAL con passthrough implementazioni (ovvero avere il file -impl.so corrispondente del 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 file manifest del fornitore per determinare (e test) di tutte le istanze HAL fornite dal dispositivo. Flusso decisionale:

di Gemini Advanced.

Test di non conformità

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

di Gemini Advanced.

Individuare il manifest del fornitore

VTS verifica il file manifest.xml del fornitore nei seguenti campi va nel seguente ordine:

1. /vendor/etc/vintf/manifest.xml + manifest ODM (se lo stesso HAL) viene definito in entrambe le posizioni, il manifest ODM sostituisce quello specificato /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. File ODM manifest.xml, caricato dai seguenti file in 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 verifica della verificabilità VTS

La vts_testibility_checker è un file binario pacchettizzato con VTS e utilizzato da il framework di test VTS in fase di runtime per determinare se un determinato test HAL viene testabile o meno. Si basa su libvintf per caricare e analizzare il file manifest del fornitore e implementa il flusso decisionale descritti 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 json formato:

{testable: <True/False> Instances: <list of instance names of HAL service>}

Determinare gli HAL a cui è stato eseguito l'accesso

Per determinare a quali HAL accedono i test VTS, assicurati che ogni test HAL utilizza VtsHalHidlTargetTestEnvBase per registrare gli HAL a cui si accede nel test. Il test VTS può quindi estrarre gli HAL registrati durante la pre-elaborazione del test.

Per i test di conformità, puoi anche /system/etc/vintf/manifest.xml. Se in questo campo viene definito un HAL, dovresti testarlo. (Per i servizi HAL forniti dal sistema (ad es. graphics.composer/vr), gli HAL vengono dichiarati in /system/manifest.xml.