À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Console de commande CTS V2
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Utiliser la console CTS v2

Pour Android 7.0 ou version ultérieure, utilisez CTS v2.

Sélectionner des forfaits

Les plans de test disponibles sont les suivants:

cts : exécute CTS à partir d'une installation CTS existante.
cts-camera : exécute cts-camera à partir d'une installation CTS existante.
cts-java : exécute les tests Java principaux à partir d'une installation CTS existante.
cts-pdk : exécute des tests utiles pour valider un build de fusion PDK.
everything : configuration commune pour les suites de compatibilité.

Voici d'autres configurations disponibles:

basic-reporters : configuration avec des rapporteurs CTS de base.
collect-tests-only : exécute CTS à partir d'une installation CTS préexistante.
common-compatibility-config : configuration commune pour les suites de compatibilité.
cts-filtered-sample : configuration courante pour les suites de compatibilité.
cts-known-failures : configuration avec des échecs connus de CTS.
cts-preconditions : configurations de préconditions CTS.
host : exécute un seul test basé sur l'hôte sur un appareil existant.
instrument : exécute un seul test d'instrumentation Android sur un appareil existant.
native-benchmark : exécute un test de stress natif sur un appareil existant.
native-stress : exécute un test de stress natif sur un appareil existant.
recharge : faux test qui attend que les appareils soient presque déchargés et les maintient en charge.
testdef : exécute les tests contenus dans les fichiers test_def.xml sur un appareil existant.
util/wifi : configuration de l'utilitaire pour configurer le Wi-Fi sur l'appareil.
util/wipe : efface les données utilisateur sur l'appareil.

Tous ces plans et configurations peuvent être exécutés à l'aide de la commande run cts.

Documentation de référence sur les commandes de la console CTS v2

Ce tableau récapitule les commandes de la console CTS v2 pour différents cas d'utilisation.

Hôte	Description
`help`	Afficher un récapitulatif des commandes les plus couramment utilisées
`help all`	Afficher la liste complète des commandes disponibles
`version`	Affichez la version.
`exit`	Quittez correctement la console CTS. La console se ferme lorsque tous les tests en cours d'exécution sont terminés.
`extdir`	Le fichier de téléchargement compressé est décompressé dans `extdir`. Si vous souhaitez vous débarrasser de la sortie gonflée, utilisez l'option `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Si vous souhaitez décompresser le fichier dans le répertoire actuel, n'utilisez pas l'option `-d`. Exécutez simplement: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Exécuter	Description
`run cts`	Dans Android 10, exécutez le plan CTS par défaut et CTS-Instant ensemble (c'est-à-dire l'appel CTS complet). Pour Android 9 ou version antérieure, exécutez uniquement le plan CTS par défaut. Utilisez cette option complète (y compris les conditions préalables) pour valider l'appareil. Pour en savoir plus sur les inclusions, consultez cts.xml. La console CTS peut accepter d'autres commandes pendant les tests. Si aucun appareil n'est connecté, l'ordinateur de bureau (ou hôte) CTS attend qu'un appareil soit connecté avant de commencer les tests. Si plusieurs appareils sont connectés, l'hôte CTS choisit automatiquement un appareil.
`run cts-instant`	Pour Android 9, exécutez le plan CTS-Instant par défaut.
`run cts --module-parameter INSTANT_APP`	Dans Android 10, exécutez le plan CTS-Instant par défaut.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	Sous Android 10, exécutez le ou les modules de test CTS-Instant spécifiés.
`run retry`	Pour Android 9 ou version ultérieure uniquement. Réessayez tous les tests qui ont échoué ou qui n'ont pas été exécutés depuis les sessions précédentes. Par exemple, `run retry --retry -s` ou `run retry --retry --shard-count` avec le fractionnement TF. `run cts --retry` n'est pas autorisé pour Android 9 ou version ultérieure.
`run cts-sim`	Pour Android 11 ou version ultérieure. Exécute le sous-ensemble de tests sur un appareil avec carte SIM.
`--device-token`	Pour Android 8.1 ou version antérieure Indique qu'un appareil donné possède le jeton donné. (par exemple, `--device-token 1a2b3c4d:sim-card`).
`--enable-token-sharding`	Pour Android 10 ou version ultérieure uniquement Correspond automatiquement au test nécessitant le type de carte SIM correspondant. Il n'est pas nécessaire de fournir un numéro de série d'appareil pour exécuter des cas de test liés à la carte SIM. Cartes SIM compatibles: `SIM_CARD`, `UICC_SIM_CARD` et `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Exécutez le plan CTS par défaut (c'est-à-dire l'appel CTS complet), mais ignorez les conditions préalables pour économiser du temps d'exécution lors du développement itératif d'un nouveau test. Cela permet de contourner la validation et la configuration de la configuration de l'appareil, comme le transfert de fichiers multimédias ou la vérification de la connexion Wi-Fi, comme c'est le cas lorsque l'option `--skip-preconditions` est utilisée. Cette commande ignore également la collecte d'informations sur l'appareil et tous les vérificateurs d'état du système. Il n'exécute également les tests que sur une seule ABI. Pour la validation de l'appareil, évitez cette optimisation et incluez toutes les conditions préalables et vérifications. Pour connaître les exclusions, consultez le fichier cts-dev.xml. La console CTS peut accepter d'autres commandes pendant les tests. Si aucun appareil n'est connecté, l'ordinateur de bureau (ou hôte) CTS attend qu'un appareil soit connecté avant de commencer les tests. Si plusieurs appareils sont connectés, l'hôte CTS choisit automatiquement un appareil.
`--subplan subplan_name`	Exécutez le sous-plan spécifié.
`--module/-m test_module_name --test/-t test_name`	Exécutez le module et le test spécifiés. Par exemple, `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` exécute le package, la classe ou le test spécifique. Attention: N'utilisez pas cette option lorsque vous utilisez l'option `--include-filter`.
`--retry`	Réessayez tous les tests qui ont échoué ou qui n'ont pas été exécutés lors des sessions précédentes. Utilisez `list results` pour obtenir l'ID de session.
`--retry-type NOT_EXECUTED`	Ne relancez que les tests qui n'ont pas été exécutés lors des sessions précédentes. Utilisez `list results` pour obtenir l'ID de session.
`--shards number_of_shards`	Pour Android 8.1 ou version antérieure Divisez une exécution CTS en un nombre donné de segments indépendants, à exécuter en parallèle sur plusieurs appareils.
`--shard-count number_of_shards`	Pour Android 9 Divisez une exécution CTS en un nombre donné de segments indépendants, à exécuter en parallèle sur plusieurs appareils.
`--serial/-s deviceID`	Exécutez CTS sur l'appareil spécifique.
`--include-filter "test_module_name test_name"`	Exécutez avec les modules spécifiés, ou les packages, classes et cas de test. Par exemple, `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` inclut le module spécifié. Cette option de commande n'est pas prise en charge lors de l'exécution de la nouvelle tentative. Attention: N'utilisez pas cette option lorsque vous utilisez l'option `--module/-m`.
`--exclude-filter "test_module_name test_name"`	Excluez les modules spécifiés, ou les packages, classes et scénarios de test, de l'exécution. Par exemple, `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` exclut le module spécifié.
`--log-level-display/-l log_level`	Exécutez avec le niveau de journalisation minimal spécifié affiché dans `STDOUT`. Valeurs valides: [`VERBOSE`,`DEBUG`, `INFO`, `WARN`,`ERROR`, `ASSERT`].
`--abi abi_name`	Force l'exécution du test sur l'ABI donnée, 32 ou 64. Par défaut, CTS exécute un test une fois pour chaque ABI compatible avec l'appareil.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	Améliore la visibilité sur les défaillances et peut aider à effectuer des diagnostics.
`--device-token`	Indique qu'un appareil donné possède le jeton donné, par exemple `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	Ignore la collecte d'informations sur l'appareil. Attention: N'utilisez pas cette option lorsque vous exécutez CTS pour approbation.
`--skip-preconditions`	Ignorez les conditions préalables pour économiser du temps d'exécution lors du développement itératif d'un nouveau test. Cela évite de valider et de configurer la configuration de l'appareil, par exemple en transmettant des fichiers multimédias ou en vérifiant la connexion Wi-Fi.
Liste	Description
`list modules`	Répertorie tous les modules de test disponibles dans le dépôt.
`list plans` ou `list configs`	Répertorie tous les plans de test (configurations) disponibles dans le dépôt.
`list subplans`	Répertoriez tous les sous-plans disponibles dans le dépôt.
`list invocations`	Liste des commandes run actuellement exécutées sur les appareils.
`list commands`	Répertorie toutes les commandes run actuellement dans la file d'attente en attente d'être attribuées à des appareils.
`list results`	Liste des résultats CTS actuellement stockés dans le dépôt.
`list devices`	Liste des appareils actuellement connectés et de leur état. Les appareils disponibles sont des appareils en état de fonctionnement et inactifs, disponibles pour exécuter des tests. Les appareils indisponibles sont des appareils visibles via ADB, mais qui ne répondent pas aux commandes ADB et ne seront pas alloués pour les tests. Les appareils alloués sont ceux qui exécutent actuellement des tests.
Vider	Description
`dump logs`	Vider les journaux tradefed pour toutes les invocations en cours d'exécution.
Ajouter	Description
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Créez un sous-plan dérivé de la session précédente. Cette option génère un sous-plan pouvant être utilisé pour exécuter un sous-ensemble de tests. La seule option obligatoire est `--session`. Les autres sont facultatifs, mais, lorsqu'ils sont inclus, ils doivent être suivis d'une valeur. L'option `--result-type` est répétable. Par exemple, `add subplan --session 0 --result-type passed --result-type failed` est valide.