A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Console de comando do CTS v2
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Usar o console do CTS v2

Para o Android 7.0 ou versões mais recentes, use o CTS v2.

Selecionar planos

Os planos de teste disponíveis incluem:

cts: executa o CTS de uma instalação do CTS já existente.
cts-camera: executa a CTS-camera de uma instalação de CTS já existente.
cts-java: executa os testes Java principais de uma instalação do CTS já existente.
cts-pdk: executa testes úteis para validar um build de fusão de PDK.
everything: configuração comum para pacotes de compatibilidade.

Outras configurações disponíveis incluem:

basic-reporters: configuração com acionadores básicos do CTS.
collect-tests-only: executa o CTS de uma instalação do CTS já existente.
common-compatibility-config: configuração comum para pacotes de compatibilidade.
cts-filtered-sample: configuração comum para pacotes de compatibilidade.
cts-known-failures: configuração com falhas conhecidas do CTS.
cts-preconditions: configurações de pré-condições do CTS.
host: executa um único teste baseado em host em um dispositivo.
instrument: executa um único teste de instrumentação do Android em um dispositivo.
native-benchmark: executa um teste de estresse nativo em um dispositivo.
native-stress: executa um teste de estresse nativo em um dispositivo.
recarga: um teste falso que aguarda dispositivos quase descarregadas e os mantém para carregamento.
testdef: executa testes contidos em arquivos test_def.xml em um dispositivo.
util/wifi: configuração de utilitários para configurar o Wi-Fi no dispositivo.
util/wipe: exclui permanentemente os dados do usuário no dispositivo.

Todos esses planos e configurações podem ser executados com o comando run cts.

Referência de comando do console CTS v2

Esta tabela resume os comandos do console do CTS v2 para vários usos.

Host	Descrição
`help`	Mostrar um resumo dos comandos mais usados
`help all`	Mostrar a lista completa de comandos disponíveis
`version`	Mostre a versão.
`exit`	Saia do console CTS. O console é fechado quando todos os testes em execução são concluídos.
`extdir`	O arquivo de downloads compactado é descompactado para `extdir`. Se você quiser se livrar da saída inflada, use a opção `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Se você quiser descompactar no diretório atual, não use a opção `-d`. Basta executar: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Executar	Descrição
`run cts`	No Android 10, execute o plano padrão do CTS e o CTS-Instant juntos (ou seja, a invocação completa do CTS). Para o Android 9 ou versões anteriores, execute apenas o plano padrão do CTS. Use essa opção abrangente (incluindo pré-condições) para a validação do dispositivo. Consulte cts.xml para ver as inclusões. O console CTS pode aceitar outros comandos enquanto os testes estão em andamento. Se nenhum dispositivo estiver conectado, a máquina de desktop (ou host) do CTS vai esperar que um dispositivo seja conectado antes de iniciar os testes. Se mais de um dispositivo estiver conectado, o host do CTS vai escolher um automaticamente.
`run cts-instant`	Para o Android 9, execute o plano padrão do CTS-Instant.
`run cts --module-parameter INSTANT_APP`	No Android 10, execute o plano padrão do CTS-Instant.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	No Android 10, execute o módulo de teste CTS-Instant especificado ou os módulos.
`run retry`	Somente para Android 9 ou versões mais recentes. Repita todos os testes que falharam ou não foram executados nas sessões anteriores. Por exemplo, `run retry --retry -s` ou `run retry --retry --shard-count` com fragmentação do TF. `run cts --retry` não é permitido no Android 9 ou versões mais recentes.
`run cts-sim`	Para Android 11 ou versões mais recentes. Executa o subconjunto de testes em um dispositivo com chip.
`--device-token`	Para Android 8.1 ou versões anteriores. Especifica que um determinado dispositivo tem o token especificado. Por exemplo, `--device-token 1a2b3c4d:sim-card`.
`--enable-token-sharding`	Somente para o Android 10 ou versões mais recentes. Corresponde automaticamente ao teste que requer o tipo de SIM correspondente. Não é necessário fornecer um número de série do dispositivo para executar casos de teste relacionados ao chip. Cartões SIM compatíveis: `SIM_CARD`, `UICC_SIM_CARD` e `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Execute o plano CTS padrão (ou seja, a invocação completa do CTS), mas pule as pré-condições para economizar tempo de execução no desenvolvimento iterativo de um novo teste. Isso ignora a verificação e a configuração do dispositivo, como o envio de arquivos de mídia ou a verificação de conexão Wi-Fi, como é feito quando a opção `--skip-preconditions` é usada. Esse comando também pula a coleta de informações do dispositivo e todos os verificadores de status do sistema. Ele também executa os testes em apenas uma ABI. Para a validação do dispositivo, evite essa otimização e inclua todas as pré-condições e verificações. Consulte cts-dev.xml para ver as exclusões. O console CTS pode aceitar outros comandos enquanto os testes estão em andamento. Se nenhum dispositivo estiver conectado, a máquina de desktop (ou host) do CTS vai esperar que um dispositivo seja conectado antes de iniciar os testes. Se mais de um dispositivo estiver conectado, o host do CTS vai escolher um automaticamente.
`--subplan subplan_name`	Executar o subplano especificado.
`--module/-m test_module_name --test/-t test_name`	Executa o módulo e o teste especificados. Por exemplo, `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` executa o pacote, a classe ou o teste específico. Atenção: não use essa opção quando estiver usando a opção `--include-filter`.
`--retry`	Repita todos os testes que falharam ou não foram executados nas sessões anteriores. Use `list results` para receber o ID da sessão.
`--retry-type NOT_EXECUTED`	Refazer apenas os testes que não foram executados nas sessões anteriores. Use `list results` para receber o ID da sessão.
`--shards number_of_shards`	Para Android 8.1 ou versões anteriores. Fragmente uma execução do CTS em um número determinado de partes independentes para execução em vários dispositivos em paralelo.
`--shard-count number_of_shards`	Para o Android 9. Fragmente uma execução do CTS em um número determinado de partes independentes para execução em vários dispositivos em paralelo.
`--serial/-s deviceID`	Execute o CTS no dispositivo específico.
`--include-filter "test_module_name test_name"`	Executar com os módulos especificados ou pacotes, classes e casos de teste. Por exemplo, `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` inclui o módulo especificado. Essa opção de comando não é compatível com a execução de uma nova tentativa. Atenção: não use essa opção ao usar a opção `--module/-m`.
`--exclude-filter "test_module_name test_name"`	Excluir os módulos especificados ou pacotes de teste, classes e casos da execução. Por exemplo, `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` exclui o módulo especificado.
`--log-level-display/-l log_level`	Execução com o nível mínimo de registro especificado exibido para `STDOUT`. Valores válidos: [`VERBOSE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `ASSERT`].
`--abi abi_name`	Força o teste a ser executado na ABI especificada, 32 ou 64. Por padrão, o CTS executa um teste uma vez para cada ABI com suporte do dispositivo.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	Oferece mais visibilidade sobre falhas e pode ajudar no diagnóstico.
`--device-token`	Especifica que um determinado dispositivo tem o token fornecido, como `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	Pula a coleta de informações sobre o dispositivo. Cuidado: não use essa opção ao executar o CTS para aprovação.
`--skip-preconditions`	Pular pré-condições para economizar tempo de execução no desenvolvimento iterativo de um novo teste. Isso ignora a verificação e a configuração do dispositivo, como o envio de arquivos de mídia ou a verificação de conexão Wi-Fi.
Lista	Descrição
`list modules`	Lista todos os módulos de teste disponíveis no repositório.
`list plans` ou `list configs`	Lista todos os planos de teste (configurações) disponíveis no repositório.
`list subplans`	Lista todos os subplanos disponíveis no repositório.
`list invocations`	Lista os comandos run que estão sendo executados nos dispositivos.
`list commands`	Lista todos os comandos run que estão na fila aguardando atribuição a dispositivos.
`list results`	Lista os resultados do CTS armazenados no repositório.
`list devices`	Lista os dispositivos conectados no momento e o estado deles. Os dispositivos disponíveis estão funcionando, são inativos e podem ser usados para executar testes. Os dispositivos indisponíveis são aqueles que aparecem pelo adb, mas não respondem aos comandos do adb e não são alocados para testes. Os dispositivos alocados são aqueles que estão executando testes.
Dump	Descrição
`dump logs`	Faz o despejo dos registros de tradefed para todas as invocações em execução.
Adicionar	Descrição
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Criar um subplano derivado da sessão anterior. Essa opção gera um subplano que pode ser usado para executar um subconjunto de testes. A única opção obrigatória é `--session`. Outros são opcionais, mas, quando incluídos, precisam ser seguidos por um valor. A opção `--result-type` pode ser repetida. Por exemplo, `add subplan --session 0 --result-type passed --result-type failed` é válido.