Perguntas frequentes sobre CTS

O Programa de Compatibilidade Android é o principal fator para sustentar o feedback positivo para o ecossistema Android. O CTS é a ferramenta chave para garantir a qualidade da compatibilidade na balança. A equipe do Android continua aprimorando a ferramenta CTS e a cobertura de teste. A adição regular de casos de teste melhora significativamente a qualidade dos dispositivos compatíveis.

Este artigo fornece perguntas frequentes para executar os testes CTS com mais eficiência.

Qual é a diferença entre fragmentação CTS e fragmentação TF?

CTS Sharding e TF Sharding são planos de teste totalmente diferentes, alimentados por uma base de código de infraestrutura de teste diferente. Embora o comando de execução seja o mesmo em diferentes versões, o resultado da fragmentação se comporta de maneira diferente. O CTS Sharding atribui estaticamente casos de teste a Devices Under Test (DUTs) da seguinte forma:

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

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

O dispositivo tem que passar por todos os CTS/Verifier para cada modo ABI que afirma suportar. Portanto, é necessário executar um aplicativo para as ABIs específicas. As diretrizes para várias ABIs são as seguintes:

  • Para CTS/Verifier, existem versões ARM e x86 para cada arquitetura. Cada um deles pode suportar o modo de 32 ou 64 bits.
  • Para testes CTS, se um dispositivo suporta ARM e x86, ele deve executar e passar nos testes ARM e x86 CTS, respectivamente.

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

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

Não. Um aplicativo Android é executado em seus próprios tempos de execução de 32 ou 64 bits. O código de máquina real, o caminho do 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 relatados como Não Executados?

Você deve verificar o número do Módulo Concluído em vez do número Não Executado .

Nas versões mais antigas, os módulos CTS eram relatados como Módulo Concluído de forma muito agressiva antes de serem concluídos. Portanto, um número de Módulos Concluídos foi relatado sem que todo o caso de teste fosse concluído, mesmo quando alguns dispositivos apresentavam problemas. O novo conjunto de testes é mais conservador e relata um número maior de testes Não executados quando ocorre um problema.

Um módulo executado até a conclusão relata Módulo não concluído na chamada 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.

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

    • --incluir-filtro
    • --excluir-filtro
    • -t/--test (Opção ainda não suportada na repetição)
    • --retry-type falhou
    • --subplano

Para obter um status de Módulo concluído (done="true") para esses módulos, tente novamente o seguinte para a chamada 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 acima (mesmo com 0 testes restantes) é marcado como Módulo Concluído no novo relatório.

Exceções

  • CtsNNAPITestCases tem um problema conhecido devido à limitação do linux/OS de args. O módulo pode ser executado novamente de forma isolada através de 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 baixar os arquivos de mídia CTS ou os arquivos de lógica de negócios durante o tempo de execução. Em muitos ambientes corporativos, um firewall/proxy é típico, o que faz com que a preparação do teste falhe. Execute a seguinte linha ou adicione-a ao .profile (no Ubuntu).

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

Preciso de um cartão SIM para CTS para Secure Element?

A necessidade de um cartão SIM para o teste depende do entendimento se o recurso é compatível com o dispositivo de teste.

  • Se o seu dispositivo NÃO precisar suportar os aplicativos Android que acessam elementos seguros - seja no UICC (por exemplo, um cartão SIM) distribuído pelas operadoras de rede móvel (portadoras) ou incorporado no dispositivo - você pode configurar o manifesto HIDL para não incluir o elemento HAL android.hardware.secure_element . Nesse caso, a API android.se.omapi.SEService.getReaders() relatará uma lista vazia e o teste CTS passará automaticamente e relatará uma aprovação para o CTS.
  • Se o seu dispositivo PRECISA dar suporte a aplicativos Android acessando elementos seguros - seja no UICC (por exemplo, um cartão SIM) distribuído pelas operadoras de rede móvel (operadoras) ou incorporado no dispositivo - você precisa implementar o elemento seguro corretamente e testá-lo em casa. Teste CTS para Secure Element descreve como se preparar para executar os testes CTS que garantem que o pacote de API android.se.omapi adicionado no Android 9 seja funcional. Também recomendamos realizar testes adicionais por conta própria, pois a cobertura do teste CTS é mínima.

Onde posso obter os cartões SIM para CTS for Secure Element?

Você pode entrar em contato com seu fornecedor de SIM preferido.

Por que o Orange SIM está na tela de bloqueio durante a execução do CTS com fragmentação de token?

O caso de teste não inicia porque o teste do cartão SIM está bloqueado. Desative a opção "Bloquear cartão SIM" em "Configurações de bloqueio do cartão SIM" antes de executar o CTS com fragmentação de token.