Suite de tests
Pour qu'un test fasse partie de VTS, il doit comporter le paramètre suivant dans Android.bp.
test_suites: ["vts"],
De plus, l'ajout du test à la suite general-tests lui permet de faire partie d'une suite de mappage de tests 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 Trade Federation pour exécuter un test VTS, est générée automatiquement lors de la compilation. Vous pouvez toutefois personnaliser la configuration du test.
Créer un fichier de configuration de test personnalisé
Créer un fichier XML de test à partir de zéro peut être compliqué, car cela implique de comprendre le fonctionnement du harnais de test, ainsi que la différence entre chaque exécuteur 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 indiqué ci-dessous.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Il peut y avoir plusieurs copies du fichier. Vous pouvez utiliser celle de votre choix.
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 automatiquement comme fichier de configuration du module de test. Sinon, ajoutez un attribut test_config au module, comme indiqué dans l'exemple ci-dessous.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Vous disposez désormais d'un fichier de configuration de test pour travailler et implémenter la personnalisation.
Forcer l'exécution du test avec adb root
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 les éléments suivants 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. L'exécution du test avec le framework arrêté permet au test de s'exécuter avec stabilité sans être affecté par les instabilités 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 les éléments suivants au fichier XML de test.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Ajouter des arguments de test supplémentaires
Certains tests gtest peuvent nécessiter plus de temps pour s'exécuter. Dans ce cas, vous pouvez ajouter des options de test runner dans le fichier XML.
Par exemple, le paramètre native-test-timeout de l'entrée suivante permet au test de s'exécuter 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 du niveau d'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 automatiquement défini 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 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 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 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 automatiquement défini par le système de compilation.
ro.vendor.api_level
La propriété ro.vendor.api_level a été introduite dans Android 13 pour afficher 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 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 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 se référant à 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 tout en testant 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 fragments et les exécute sur plusieurs appareils.