Contrôle de testabilité HAL

La suite de tests de fournisseurs Android 9 (VTS) prend en charge une méthode d'exécution permettant d'utiliser la configuration de l'appareil afin d'identifier les tests VTS qui doivent être ignorés pour cette cible d'appareil.

Flexibilité des tests VTS

Depuis Android 8.0, les tests VTS sont requis pour tous les appareils lancés avec Android 8.0 et versions ultérieures. Cependant, tous les tests VTS ne s’appliquent pas à toutes les cibles d’appareils. Par exemple:

  • Si un périphérique spécifique ne prend pas en charge un HAL de test (par exemple IR), VTS n'a pas besoin d'exécuter des tests pour ce test HAL sur cette cible de périphérique.
  • Si plusieurs appareils partagent le même SoC et la même image de fournisseur mais ont des 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 comprend 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 supérieur.
  • Les tests de non-conformité aident les fournisseurs à améliorer la qualité des produits (performances/fuzzing, etc.). Ces tests sont facultatifs pour les fournisseurs.

Le fait qu'un test soit ou non un test de conformité 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 pris en charge

VTS peut utiliser les fichiers suivants pour déterminer si le périphérique cible prend en charge un HAL spécifique :

  • /system/compatibility_matrix.xml . Réclame 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 configurations version pour la même entrée, indiquant que le framework peut fonctionner avec différentes versions.
    • version1.0-1 signifie que le framework peut fonctionner avec la version la plus basse 1.0 et ne nécessite pas de version supérieure à 1.1.
  • Manifeste de manifest.xml . Réclame 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 prend en charge toutes les versions de 1.0 à 1.2.
  • lshal . Un outil sur l'appareil qui affiche des informations d'exécution sur les services HAL enregistrés auprès du hwservicemanager . Exemple :
    android.hardware.vibrator@1.0::IVibrator/default
    

    lshal affiche également tous les HAL avec des implémentations passthrough (c'est-à-dire ayant le fichier -impl.so correspondant sur le périphérique). 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 manifeste du fournisseur pour déterminer (et tester) toutes les instances HAL fournies par l'appareil. Flux de décision :

Testability check for compliance

Figure 1. Vérification de testabilité pour les tests de conformité VTS

Tests de non-conformité

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

Testability check for noncompliance

Figure 2. Vérification de testabilité pour les tests de non-conformité VTS

Localisez le manifeste du fournisseur

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

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

Vérificateur de testabilité VTS

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 consultés

Pour déterminer à quelles HAL les tests VTS accèdent, assurez-vous que chaque test HAL utilise le modèle VtsHalHidlTargetTestEnvBase pour enregistrer les HAL consultées 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 consulter /system/etc/vintf/manifest.xml . Si un HAL est défini ici, 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 .)