Vérification de la testabilité HAL

La suite de test fournisseur (VTS) Android 9 prend en charge un méthode d'exécution permettant d'utiliser la configuration de l'appareil pour identifier les tests VTS doit être ignorée pour cet appareil cible.

Flexibilité des tests VTS

À partir d'Android 8.0, les tests VTS sont requis pour tous les appareils lancés avec Android 8.0 ou version ultérieure Cependant, tous les tests VTS ne s'appliquent pas à tous les appareils cibles. Exemple :

  • Si un appareil spécifique n'est pas compatible avec la fonctionnalité de test HAL (IR, par exemple), le VTS le permet il n'est pas nécessaire d'exécuter ce test HAL sur cet appareil cible.
  • Si plusieurs appareils partagent la même image SoC et la même image du fournisseur, mais que fonctionnalités matérielles différentes, le VTS doit déterminer si un test doit être exécuté ou ignoré pour un appareil cible spécifique.

Types de tests VTS

Le VTS comprend les types de tests suivants:

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

Le fait qu'un test soit un test de conformité ou non dépend du forfait auquel il appartient auxquelles vous souhaitez vous connecter. Les tests exécutés avec <ph type="x-smartling-placeholder"></ph> Les plans 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 l'appareil cible prend en charge un HAL spécifique:

  • /system/compatibility_matrix.xml Revendiquer 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 requises 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, ce qui indique que le framework peut fonctionner avec différentes versions.
    • version1.0-1 signifie que le framework peut fonctionner version 1.0 et ne nécessite pas de version supérieure à 1.1.
  • Appareil manifest.xml. Il récupère les instances HAL fournies par 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 accepte toutes les versions compris entre 1 et 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 toutes les HAL qui utilisent le passthrough les implémentations (c'est-à-dire 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é, le VTS s'appuie sur le fichier manifeste du fournisseur pour déterminer (et test) toutes les instances HAL fournies par l'appareil. Flux de décision:

Contrôle de la testabilité de la conformité

Figure 1. Contrôle de la testabilité pour les tests de conformité VTS

Tests de non-conformité

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

Vérification de la testabilité pour détecter la non-conformité

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

Localiser le fichier manifeste du fournisseur

VTS vérifie le fichier manifest.xml du fournisseur dans les éléments suivants : dans l'ordre suivant:

  1. /vendor/etc/vintf/manifest.xml + fichier manifeste ODM (si le même HAL est identique) est défini aux deux endroits, le fichier manifeste ODM remplace celui /vendor/etc/vintf/manifest.xml)
  2. /vendor/etc/vintf/manifest.xml
  3. Fichier ODM manifest.xml, chargé depuis les fichiers suivants dans 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

Outil de vérification de la testabilité VTS

La vts_testibility_checker est un binaire empaqueté avec VTS et utilisé par 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 mettre en œuvre le flux de décision décrites 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 fichier JSON suivant : format: 

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

Déterminer les HAL accessibles

Pour déterminer à quelles HAL les tests VTS ont accès, assurez-vous que chaque test HAL utilise le VtsHalHidlTargetTestEnvBase pour enregistrer le ou les HAL consultés lors du test. Les tests VTS framework peut ensuite extraire les HAL enregistrées 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 le tester. (Pour les services HAL fournis par le système (par exemple, graphics.composer/vr), les HAL sont déclarées dans /system/manifest.xml).