La suite de tests du fournisseur (VTS, Vendor Test Suite) Android 9 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 ou 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 de tests pour ce test HAL sur cette cible d'appareil.
- Si plusieurs appareils partagent le même SoC et la même image du 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 le framework et les partitions du fournisseur. Ces tests doivent être exécutés (et réussis) sur les appareils lancés avec Android 8.0 ou version ultérieure.
- Les tests de non-conformité aident les fournisseurs à améliorer la qualité de leurs produits (performances, flous, 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. Les tests exécutés avec un plan VTS sont considérés comme des tests de conformité.
Déterminer les HAL compatibles
Le VTS peut utiliser les fichiers suivants pour déterminer si l'appareil cible est compatible avec une 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 une version 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 avec la version la plus basse, la version 1.0, et qu'il ne nécessite pas de version supérieure à la version 1.1.
- L'attribut
- Appareil
manifest.xml
. Revendiquent 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 une version 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 avec
hwservicemanager
. Exemple :android.hardware.vibrator@1.0::IVibrator/default
lshal
affiche également tous les HAL avec des implémentations de passthrough (c'est-à-dire avec 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é, la suite de test de fournisseur 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 les sorties lshal
pour déterminer (et tester) les HAL expérimentaux non revendiqués dans le fichier manifest.xml
. Flux de décision:
Rechercher le fichier manifeste du fournisseur
VTS recherche le fichier manifest.xml
du fournisseur aux endroits suivants, dans l'ordre suivant:
/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 dans/vendor/etc/vintf/manifest.xml
)/vendor/etc/vintf/manifest.xml
- Fichier ODM
manifest.xml
, chargé à partir des fichiers suivants dans l'ordre suivant :/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
/odm/etc/vintf/manifest.xml
/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
/odm/etc/manifest.xml
/vendor/manifest.xml
Outil de vérification de la testabilité VTS
vts_testibility_checker
est un binaire empaqueté avec VTS et utilisé par le framework de test VTS au moment de l'exécution pour déterminer si un test HAL donné peut être testé ou non. Il est basé sur libvintf
pour charger et analyser le fichier manifeste du fournisseur et met en œuvre 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 accessibles
Pour déterminer les HAL auxquels les tests VTS accèdent, assurez-vous que chaque test HAL utilise le modèle VtsHalHidlTargetTestEnvBase
pour enregistrer le ou les HAL auxquels il accède. 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
.)