Perguntas frequentes sobre a CTS

O Programa de compatibilidade do Android é o principal fator para manter o feedback positivo do ecossistema Android. O CTS é a principal ferramenta para garantir a qualidade da compatibilidade em escala. A equipe do Android continua a melhorar a ferramenta CTS e a cobertura de testes. A adição regular de casos de teste melhora significativamente a qualidade dos dispositivos compatíveis.

Perguntas gerais

Esta seção contém perguntas frequentes gerais sobre o CTS.

O que o CTS testa?

O CTS testa se todas as APIs de tipos fortes com suporte ao Android estão presentes e se comportam corretamente. O CTS também testa outros comportamentos do sistema que não são APIs, como o ciclo de vida de apps e a performance.

Como o CTS é licenciado?

O CTS é licenciado sob a mesma Licença de Software Apache 2.0 que a maior parte do Android usa.

Os codecs são verificados pelo CTS?

Sim. Todos os codecs obrigatórios são verificados pelo CTS.

Perguntas específicas do teste

Esta seção contém perguntas frequentes que ajudam a executar testes do CTS com mais eficiência.

Qual é a diferença entre o CTS Sharding e o TF Sharding?

O CTS Sharding e o TF Sharding são planos de teste totalmente diferentes, com base em bases de código de infraestrutura de teste diferentes. Embora o comando de execução seja o mesmo em versões diferentes, o resultado do sharding se comporta de maneira diferente. O CTS Sharding atribui casos de teste estaticamente aos dispositivos em teste (DUTs, na sigla em inglês) da seguinte maneira:

O TF Sharding atribui casos de teste dinamicamente aos DUTs disponíveis da seguinte maneira:

O que se espera de um dispositivo que oferece suporte a várias ABIs?

O dispositivo precisa passar em todos os testes do CTS e do CTS Verifier para cada modo de ABI que ele afirma oferecer suporte. Portanto, é necessário executar um app para as ABIs específicas. As diretrizes para várias ABIs são as seguintes:

  • Para o CTS e o CTS Verifier, há versões ARM e x86 para cada arquitetura. Cada uma delas pode oferecer suporte ao modo de 32 ou 64 bits.
  • Para testes do CTS, se um dispositivo oferece suporte a ARM e x86, ele precisa executar e passar nos testes do CTS ARM e x86, respectivamente.

Consulte CDD 3.3.1. Interfaces binárias de aplicativos para requisitos de CDD na ABI.

É suficiente executar um teste apenas na ABI principal (por exemplo, 64 bits) para reduzir o tempo de execução do teste?

Não.Um app Android é executado nos próprios runtimes de 32 ou 64 bits. O código de máquina real, o caminho de código e o estado são diferentes entre 32 e 64. Se você pular um modo, estará cobrindo apenas 50% da ABI do dispositivo.

Por que há tantos casos de teste informados como "Não executados"?

Verifique o número de Módulos concluídos em vez do número de Não executados.

Nas versões anteriores, os módulos do CTS eram informados como Módulo concluído de forma muito agressiva antes de serem concluídos. Portanto, um número de Módulos concluídos era informado sem que todos os casos de teste fossem concluídos, mesmo quando alguns dispositivos tinham problemas. O novo arcabouço de testes é mais conservador e informa um número maior de testes Não executados quando ocorre um problema.

Uma execução de módulo até a conclusão informa Módulo não concluído na invocação mais recente (done="false") no relatório durante o seguinte:

  • Uma execução de teste para o módulo foi interrompida por um problema de conexão do dispositivo.
  • Nem todas as execuções de teste esperadas para o módulo foram realizadas.

  • Tentativa (usando a opção -r/--retry) com outras opções de filtragem, como:

    • --include-filter
    • --exclude-filter
    • -t/--test (opção ainda não compatível com a nova tentativa)
    • --retry-type failed
    • --subplan

Para receber um status de Módulo concluído (done="true") para esses módulos, tente novamente o seguinte para a invocação mais recente:

run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions

Um módulo executado sem nenhum dos problemas mencionados anteriormente (mesmo com 0 testes restantes) é marcado como Módulo concluído no novo relatório.

Exceções

  • O CtsNNAPITestCases tem um problema conhecido devido à limitação de argumentos do Linux/SO. O módulo pode ser executado novamente isoladamente usando run cts -m CtsNNAPITestCases diretamente.

Como posso evitar que a preparação do teste falhe atrás do firewall corporativo?

Todos os conjuntos de testes automatizados tentam fazer o download dos arquivos de mídia do CTS ou dos arquivos de lógica de negócios durante o runtime. Em muitos ambientes corporativos, um firewall e um proxy são típicos, o que faz com que a preparação do teste falhe. Execute a linha a seguir ou adicione-a ao .profile (no Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

Preciso de um chip para o CTS para o elemento seguro?

Se um chip é necessário para o teste depende do entendimento se o recurso é compatível com o dispositivo de teste.

  • Se o dispositivo NÃO precisar oferecer suporte aos apps Android que acessam elementos seguros, seja no UICC (por exemplo, um chip) distribuído pelas operadoras de rede móvel (operadoras) ou incorporado ao dispositivo, você poderá configurar o manifesto HIDL para não incluir o android.hardware.secure_element HAL element. Nesse caso, a API android.se.omapi.SEService.getReaders() informa uma lista vazia, e o teste do CTS é aprovado automaticamente e informa uma aprovação para o CTS.
  • Se o dispositivo PRECISAR oferecer suporte a apps Android que acessam elementos de segurança, seja no UICC (por exemplo, um chip) distribuído pelas operadoras de rede móvel (operadoras) ou incorporado ao dispositivo, você precisará implementar o elemento de segurança corretamente e testá-lo internamente. O teste do CTS para o elemento seguro descreve como se preparar para executar os testes do CTS que garantem que o pacote de API android.se.omapi adicionado no Android 9 esteja funcional. Também recomendamos realizar testes adicionais por conta própria, já que a cobertura de testes do CTS é mínima.

Onde posso encontrar os chips para o CTS para o elemento seguro?

Entre em contato com o fornecedor de chips preferido.

Por que o chip Orange aparece na tela de bloqueio durante a execução do CTS com o sharding de token?

O caso de teste não é iniciado porque o teste do chip está bloqueado. Desative o Bloqueio do chip nas **Configurações de bloqueio do chip** antes de executar o CTS com o sharding de token.

Os testes são executados quando os flags de recursos estão desativados no dispositivo

Para todos os flags nas versões de lançamento, a anotação @RequiresFlagsEnabled ou @RequiresFlagsDisabled usa os valores dos flags da configuração de lançamento binário do CTS, não da configuração de lançamento do dispositivo. A desativação dos flags no dispositivo não desativa o teste, já que o conjunto de testes do CTS executados para uma determinada versão é fixo na configuração lançada da plataforma AOSP.