Vérification de la testabilité du HAL

La suite de tests VTS (Vendor Test Suite) d'Android 9 est compatible avec une méthode d'exécution permettant d'utiliser la configuration de l'appareil pour identifier les tests VTS à ignorer pour cette cible d'appareil.

Flexibilité des tests VTS

Depuis Android 8.0, les tests VTS sont obligatoires pour tous les appareils lancés avec Android 8.0 ou une version ultérieure. Toutefois, tous les tests VTS ne s'appliquent pas à toutes les cibles d'appareils. Exemple :

• Si un appareil spécifique n'est pas compatible avec un HAL de test (par exemple, IR), VTS n'a pas besoin d'exécuter des tests pour ce HAL sur cette cible d'appareil.
• Si plusieurs appareils partagent le même SoC et la même image de fournisseur, mais qu'ils disposent de fonctionnalités matérielles différentes, VTS doit déterminer si un test doit être exécuté ou ignoré pour une cible d'appareil spécifique.

Types de tests VTS

VTS inclut les types de tests suivants :

• Les tests de conformité garantissent la compatibilité entre les partitions du framework et du fournisseur. Ces tests doivent être exécutés (et réussis) sur les appareils lancés avec Android 8.0 ou une version ultérieure.
• Les tests de non-conformité aident les fournisseurs à améliorer la qualité de leurs produits (performances/fuzzing, etc.). Ces tests sont facultatifs pour les fournisseurs.

Le caractère de conformité d'un test dépend du plan auquel il appartient. Les tests exécutés avec le plan VTS sont considérés comme des tests de conformité.

Déterminer les HAL compatibles

VTS peut utiliser les fichiers suivants pour déterminer si la cible de l'appareil est compatible avec un HAL spécifique :

• /system/compatibility_matrix.xml. Revendique les instances HAL requises par le framework. Exemple :

  <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'attribut optional indique si le HAL est strictement requis par le framework.
  • Le fichier peut contenir plusieurs entrées pour le même HAL (avec le même nom) mais avec des versions et des interfaces différentes.
  • Le fichier peut contenir plusieurs version configurations pour la même entrée, ce qui indique que le framework peut fonctionner avec différentes versions.
  • version1.0-1 signifie que le framework peut fonctionner avec la version 1.0 la plus basse et ne nécessite pas de version supérieure à 1.1.
• manifest.xml de l'appareil. Revendique les instances HAL fournies par le fournisseur. Exemple :

  <hal format="hidl">
      <name>android.hardware.vibrator</name>
      <transport>hwbinder</transport>
      <version>1.2</version>
      <interface>
          <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • Le fichier peut contenir plusieurs entrées pour le même HAL (avec le même nom) mais avec des versions et des interfaces différentes.
  • Si le fichier ne contient qu'une seule configuration version pour une entrée, version1.2 signifie que le fournisseur est compatible avec toutes les versions de 1.0 à 1.2.
• lshal. Outil sur l'appareil qui affiche des informations d'exécution sur les services HAL enregistrés auprès de hwservicemanager. Exemple :

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

  
  lshal affiche également tous les HAL avec des implémentations directes (c'est-à-dire ceux qui ont le fichier -impl.so correspondant sur l'appareil). Exemple :

  android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
  android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

Tests de conformité

Pour les tests de conformité, VTS s'appuie sur le fichier manifeste du fournisseur pour déterminer (et tester) toutes les instances HAL fournies par l'appareil. Flux de décision :

Tests de non-conformité

Pour les tests de non-conformité, VTS s'appuie sur le fichier manifeste du fournisseur et lshal sorties pour déterminer (et tester) les HAL expérimentaux non revendiqués dans le manifest.xml fichier. Flux de décision :

Localiser le fichier manifeste du fournisseur

VTS recherche le fichier du fournisseur manifest.xml aux emplacements suivants, dans l'ordre indiqué :

1. /vendor/etc/vintf/manifest.xml + fichier manifeste ODM (si le même HAL est défini aux deux emplacements, le fichier manifeste ODM remplace celui de /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. Fichier manifest.xml ODM, chargé à partir des fichiers suivants, dans l'ordre indiqué :
   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

Outil de vérification de la testabilité VTS

Le vts_testibility_checker est un binaire fourni avec VTS et utilisé par le framework de test VTS au moment de l'exécution pour déterminer si un test HAL donné est testable ou non. Il est basé sur libvintf pour charger et analyser le fichier manifeste du fournisseur, et implémente le flux de décision décrit dans la section précédente.

Pour utiliser vts_testability_check :

• Pour un test de conformité :

  vts_testability_check -c -b <bitness>  <hal@version>

• Pour un test de non-conformité :

  vts_testability_check -b <bitness>  <hal@version>

La sortie de vts_testability_check utilise le format JSON suivant :

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

Déterminer les HAL auxquels l'accès est autorisé

Pour déterminer les HAL auxquels les tests VTS ont accès, assurez-vous que chaque test HAL utilise le VtsHalHidlTargetTestEnvBase modèle pour enregistrer les HAL auxquels l'accès est autorisé dans le test. Le framework de test VTS peut ensuite extraire les HAL enregistrés lors du prétraitement du test.

Pour les tests de conformité, vous pouvez également vérifier /system/etc/vintf/manifest.xml. Si un HAL y est défini, VTS doit le tester. (Pour les services HAL fournis par le système (par exemple, graphics.composer/vr), les HAL sont déclarés dans /system/manifest.xml.)