Vérification de la testabilité HAL

Android 9 Vendor Test Suite (VTS) prend en charge 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

À partir d'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 test HAL (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é assurent la compatibilité entre les partitions cadres et fournisseurs. Ces tests doivent être exécutés (et réussis) sur les appareils lancés avec Android 8.0 ou supérieur.
  • Tests non-respect des fournisseurs d'aide pour améliorer la qualité des produits (performance / fuzzing etc.). Ces tests sont facultatifs pour les fournisseurs.

Le fait qu'un test soit un test de conformité ou non dépend du plan auquel il appartient. Les tests qui fonctionnent avec le plan VTS sont considérés comme des tests de conformité.

Détermination des HAL pris en charge

VTS peut utiliser les fichiers suivants pour déterminer si l'appareil 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' optional attribut indique si le HAL est strictement nécessaire par le cadre.
    • 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 des configurations pour la même entrée, ce qui indique le cadre peut fonctionner avec des versions différentes.
    • version1.0-1 signifie que le cadre peut travailler avec la plus faible version 1.0, et ne nécessite pas une version supérieure à 1,1.
  • Dispositif 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 la version configuration pour une entrée, version1.2 moyen le fournisseur prend en charge toutes les versions de 1.0 ~ 1.2.
  • lshal. Un outil sur l' appareil qui montre runtime informations sur les services de HAL inscrits au hwservicemanager . Exemple:
    android.hardware.vibrator@1.0::IVibrator/default
    

    lshal montre également que tous les HALS avec des implémentations traversants (ie ayant le correspondant -impl.so fichier sur le dispositif). 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. testabilité vérifier pour les tests de conformité VTS

Tests de non-conformité

Pour les tests de non-conformité, VTS repose sur le manifeste des fournisseurs et lshal sorties pour déterminer (et test) les HALs expérimentaux non réclamés dans le manifest.xml fichier. Flux de décision :

Testability check for non-compliance

Figure 2. testabilité vérification des tests VTS non-conformité

Localisation du manifeste du fournisseur

Chèques VTS pour le vendeur manifest.xml fichier dans les endroits suivants dans l'ordre suivant:

  1. /vendor/etc/vintf/manifest.xml + ODM manifeste (Si même HAL est défini dans les deux endroits, manifeste ODM l' emporte celui /vendor/etc/vintf/manifest.xml )
  2. /vendor/etc/vintf/manifest.xml
  3. ODM manifest.xml fichier, 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

Le vts_testibility_checker est un fichier binaire fourni avec VTS et utilisé par framework de test VTS lors de l' exécution pour déterminer si un test HAL donné est testable ou non. Il est basé sur libvintf à la charge et analyser le vendeur fichier manifeste et met en œuvre la décision de flux 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 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étermination des HAL accédés

Pour déterminer quels sont HALs accessibles par des tests VTS, assurez -vous que chaque test HAL utilise le VtsHalHidlTargetTestEnvBase modèle pour enregistrer le HAL (s) accessible 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 est défini ici, VTS devrait le tester. (Pour les services de HAL fournis par le système (par exemple graphics.composer/vr ), les HALs sont déclarés dans /system/manifest.xml .)