Suite de tests
Pour qu'un test fasse partie de VTS, il doit avoir 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 contrôles préalables à la soumission.
Configuration des tests
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 automatiquement générée lors de la génération. Cependant, vous pouvez personnaliser la configuration du test.
Créer un fichier de configuration de test personnalisé
Créer un nouveau fichier XML de test à partir de zéro peut être compliqué, car cela implique de comprendre le fonctionnement du faisceau de tests, 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 construction, 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 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 .
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 , et le système de build l'utilise 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 avec lequel travailler et implémenter la personnalisation.
Forcer l'exécution du test avec adb root
La plupart des tests VTS nécessitent le privilège root 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 avec stabilité sans être affecté par les failles 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
Certains tests gtest peuvent nécessiter plus de temps pour s'exécuter. Dans de tels cas, vous pouvez ajouter des options d'exécution de test dans le fichier XML.
Par exemple, le paramètre native-test-timeout dans l'entrée suivante permet au test de s'exécuter avec un délai d'expiration de 3 minutes, au lieu de 1 minute par défaut.
<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 minimum
Certains tests VTS ne peuvent s'exécuter que sur des appareils dotés d'un niveau API minimum. Si le fichier de configuration de test est généré automatiquement, vous pouvez ajouter l'attribut suivant à Android.bp .
test_min_api_level: 29,
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.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 définit les propriétés ro.board.first_api_level et ro.board.api_level pour afficher le niveau 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 cas 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 .
ro.board.first_api_level
La propriété ro.board.first_api_level est le niveau d'API lorsque les images du fournisseur pour un SoC 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 dépend 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 est le niveau d'API actuel des images du fournisseur pour un SoC. Lorsque le niveau d'API de l'image du fournisseur qui possède le ro.board.first_api_level est mis à jour, l'appareil utilisant le SoC doit définir la propriété ro.board.api_level avec le niveau d'API actuel de l'image du fournisseur au lieu de mettre à jour le ro.board.first_api_level . . Si cette propriété n'est pas définie, ro.board.first_api_level sera utilisé par défaut.
Pour définir le ro.board.api_level , définissez BOARD_API_LEVEL dans le fichier device.mk avec la valeur souhaitée.
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. Ceci est automatiquement défini au minimum de ro.board.api_level (ou ro.board.first_api_level si ro.board.api_level n'est pas défini) et ro.product.first_api_level . 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 partage à l'aide de VTS
Pour Android version 10 ou supé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.
,Suite de tests
Pour qu'un test fasse partie de VTS, il doit avoir 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 contrôles préalables à la soumission.
Configuration des tests
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 automatiquement générée lors de la génération. Cependant, vous pouvez personnaliser la configuration du test.
Créer un fichier de configuration de test personnalisé
Créer un nouveau fichier XML de test à partir de zéro peut être compliqué, car cela implique de comprendre le fonctionnement du faisceau de tests, 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 construction, 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 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 .
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 , et le système de build l'utilise 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 avec lequel travailler et implémenter la personnalisation.
Forcer l'exécution du test avec adb root
La plupart des tests VTS nécessitent le privilège root 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 avec stabilité sans être affecté par les failles 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
Certains tests gtest peuvent nécessiter plus de temps pour s'exécuter. Dans de tels cas, vous pouvez ajouter des options d'exécution de test dans le fichier XML.
Par exemple, le paramètre native-test-timeout dans l'entrée suivante permet au test de s'exécuter avec un délai d'expiration de 3 minutes, au lieu de 1 minute par défaut.
<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 minimum
Certains tests VTS ne peuvent s'exécuter que sur des appareils dotés d'un niveau API minimum. Si le fichier de configuration de test est généré automatiquement, vous pouvez ajouter l'attribut suivant à Android.bp .
test_min_api_level: 29,
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.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 définit les propriétés ro.board.first_api_level et ro.board.api_level pour afficher le niveau 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 cas 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 .
ro.board.first_api_level
La propriété ro.board.first_api_level est le niveau d'API lorsque les images du fournisseur pour un SoC 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 dépend 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 est le niveau d'API actuel des images du fournisseur pour un SoC. Lorsque le niveau d'API de l'image du fournisseur qui possède le ro.board.first_api_level est mis à jour, l'appareil utilisant le SoC doit définir la propriété ro.board.api_level avec le niveau d'API actuel de l'image du fournisseur au lieu de mettre à jour le ro.board.first_api_level . . Si cette propriété n'est pas définie, ro.board.first_api_level sera utilisé par défaut.
Pour définir le ro.board.api_level , définissez BOARD_API_LEVEL dans le fichier device.mk avec la valeur souhaitée.
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. Ceci est automatiquement défini au minimum de ro.board.api_level (ou ro.board.first_api_level si ro.board.api_level n'est pas défini) et ro.product.first_api_level . 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 partage à l'aide de VTS
Pour Android version 10 ou supé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.