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, ajouter le test à la suite general-tests lui permet de faire partie d'une suite de mappage de test utilisée dans les vérifications préalables à l'envoi.
tester la configuration
Dans la plupart des cas, la configuration de test, qui est un fichier XML utilisé par Trade Federation pour exécuter un test VTS, est générée automatiquement lors de la compilation. Vous pouvez toutefois personnaliser la configuration des tests.
Créer un fichier de configuration de test personnalisé
La création d'un fichier XML de test à partir de zéro peut s'avérer compliquée, car elle implique de comprendre 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 faciliter 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 indiqué 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 en utiliser n'importe laquelle.
Copiez le fichier .config dans le répertoire où se trouve le fichier Android.bp.
S'il n'y a qu'un seul module de test dans le fichier Android.bp, vous pouvez renommer le fichier XML en AndroidTest.xml. Le système de compilation l'utilisera alors automatiquement comme fichier de configuration du module de test. Sinon, ajoutez un attribut test_config au module, comme illustré dans l'exemple ci-dessous.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Vous disposez maintenant d'un fichier de configuration de test avec lequel utiliser et mettre en œuvre la personnalisation.
Forcer l'exécution du test avec la racine adb
La plupart des tests VTS nécessitent des droits racine pour s'exécuter. Si le fichier de 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 ce qui suit 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, et l'exécution du test avec le framework arrêté permet au test de s'exécuter de manière stable sans être affecté par les éclats de l'appareil. Si le fichier de 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 les options du lanceur de test dans le fichier XML.
Par exemple, le paramètre native-test-timeout dans l'entrée suivante autorise l'exécution du test avec un délai avant expiration de trois minutes, au lieu de la valeur par défaut d'une 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 la commande suivante au 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 du fournisseur sont publiées pour la première fois avec cette propriété. Cela ne dépend pas du niveau d'API de lancement de l'appareil, mais uniquement du premier niveau d'API du SoC qui définit cette valeur. La valeur 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 illustré 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
La propriété ro.board.first_api_level sera automatiquement définie sur 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. Il est automatiquement défini sur ro.product.first_api_level, ou sur 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 10 ou version ultérieure, vous pouvez effectuer le processus de partitionnement sur plusieurs appareils lors des tests avec les plans VTS et CTS-on-GSI 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 partitions et les exécute sur plusieurs appareils.