Suite de tests
Pour qu'un test fasse partie de VTS, il doit disposer du paramètre suivant dans Android.bp.
test_suites: ["vts"],
De plus, l'ajout du test à la suite general-tests lui permet d'être
d'une suite de mappage de test utilisée dans les vérifications avant envoi.
tester la configuration
Dans la plupart des cas, la configuration de test, qui est un fichier XML utilisé par The Trade La fédération pour exécuter un test VTS est automatiquement générées lors de la compilation. Vous pouvez toutefois personnaliser la configuration des tests.
Créer un fichier de configuration de test personnalisé
Créer un fichier XML de test à partir de zéro peut s'avérer compliqué, car cela implique le fonctionnement de l'outil de test, ainsi que la différence entre chaque lanceur de test. Le fichier de configuration de test généré automatiquement est conçu pour ce processus.
Si vous devez personnaliser le fichier XML de test, vous pouvez utiliser le fichier généré automatiquement comme point de départ.
Pour localiser le fichier de configuration de test généré automatiquement, exécutez d'abord la commande make pour créer la configuration, comme illustré ci-dessous.
$ m VtsHalUsbV1_1TargetTest
Dans votre répertoire de compilation, vous pouvez rechercher le fichier de configuration en fonction du nom du module, comme illustré ci-dessous.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Il peut y avoir plusieurs copies du fichier et vous pouvez utiliser n'importe laquelle d'entre elles.
Copiez le fichier .config dans le répertoire où se trouve le fichier Android.bp.
Si le fichier Android.bp ne contient qu'un seul module de test, vous pouvez
remplacez le nom du fichier XML par AndroidTest.xml. Le système de compilation s'exécute automatiquement
l'utilise comme fichier de configuration du module de test. Sinon,
Ajoutez un attribut test_config au module, comme indiqué dans
dans l'exemple ci-dessous.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Vous disposez maintenant d'un fichier de configuration de test à utiliser et à implémenter. la personnalisation.
Forcer l'exécution du test avec la racine adb
La plupart des tests VTS nécessitent un privilège racine pour s'exécuter. Si la configuration de test
est généré automatiquement, vous pouvez ajouter l'attribut suivant à Android.bp.
require_root: true,
Si le fichier de configuration de test est personnalisé, ajoutez au fichier XML de test.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Arrêter le framework pendant le test
De nombreux tests VTS ne nécessitent pas l'exécution du framework Android. Exécuter le test avec le framework arrêté permet de l'exécuter de manière stable, sans être affecté par les erreurs d'appareil. Si la configuration de test
est généré automatiquement, vous pouvez ajouter l'attribut suivant à Android.bp.
disable_framework: true,
Si le fichier de configuration de test est personnalisé, ajoutez ce qui suit au fichier XML de test.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Ajouter des arguments de test supplémentaires
L'exécution de certains tests gtest peut prendre plus de temps. Dans ce cas, vous pouvez ajouter des options de testeur de course dans le fichier XML.
Par exemple, le paramètre native-test-timeout dans l'exemple
permet d'exécuter le test avec un délai d'inactivité de 3 minutes, au lieu de
la valeur par défaut est de 1 minute.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
Exiger un niveau d'API minimal
Certains tests VTS ne peuvent s'exécuter que sur des appareils avec un niveau d'API minimal. Si le fichier de configuration de test est généré automatiquement, vous pouvez ajouter l'attribut suivant à Android.bp.
min_shipping_api_level: 29,
ou
vsr_min_shipping_api_level: 202404,
Si le fichier de configuration de test est personnalisé, ajoutez le dans le fichier XML de test.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
ou
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Propriétés au niveau de l'API
Android 12 définit les propriétés ro.board.first_api_level et ro.board.api_level pour afficher le niveau d'API des images du fournisseur sur ces appareils. En combinant ces propriétés avec ro.product.first_api_level, les suites de tests choisissent les scénarios de test appropriés pour les appareils.
Android 13 définit ro.vendor.api_level, qui est défini automatiquement en calculant le niveau d'API du fournisseur requis à l'aide des propriétés ro.product.first_api_level, ro.board.first_api_level et ro.board.api_level.
Pour en savoir plus, consultez la section Niveau d'API du fournisseur.
ro.board.first_api_level
La propriété ro.board.first_api_level correspond au niveau d'API lorsque les images du fournisseur
pour un SoC qualifié pour
le gel des fournisseurs sont les premiers
publiée avec cette propriété. Cela ne dépend pas de l'API de lancement de l'appareil
mais ne dépend que du premier niveau d'API du SoC qui définit cette valeur. La
est permanente pendant toute la durée de vie du SoC.
Pour définir ro.board.first_api_level, les fabricants d'appareils peuvent définir BOARD_SHIPPING_API_LEVEL dans leur fichier device.mk, comme indiqué dans l'exemple suivant :
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
Il définira automatiquement la propriété ro.board.first_api_level pour
vendor/build.prop sur l'appareil. La propriété est définie par le processus init du fournisseur.
ro.board.api_level
La propriété ro.board.api_level correspond au niveau d'API du fournisseur actuel des images du fournisseur au format YYYYMM dans lequel l'API du fournisseur a été figée. Il est
défini automatiquement par le système de compilation.
ro.vendor.api_level
La propriété ro.vendor.api_level a été introduite dans Android 13 pour indiquer le niveau d'API que les images du fournisseur doivent prendre en charge. Cette valeur est automatiquement définie sur ro.product.first_api_level ou ro.board.api_level si ro.board.first_api_level est présent et que ro.board.api_level est défini sur un niveau d'API antérieur à ro.product.first_api_level. La version sera remplacée par le niveau d'API du fournisseur correspondant si elle est définie sur la version à partir de ro.product.first_api_level, qui est supérieure ou égale à 35. Les tests d'implémentation du fournisseur qui nécessitent une mise à niveau de l'image du fournisseur peuvent être exclus des exigences du fournisseur pour le SoC en faisant référence à cette propriété.
Processus de segmentation à l'aide de VTS
Pour Android version 10 ou ultérieure, vous pouvez effectuer le processus de segmentation sur plusieurs appareils lors des tests avec les forfaits VTS et CTS sur GSI en suivant en suivant les instructions ci-dessous.
run vts --shard-count <number of devices> -s <device serial> ...
Cette commande divise le plan VTS en fragments et les exécute sur plusieurs appareils.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Cette commande divise le plan CTS-on-GSI en fragments et les exécute sur plusieurs appareils.