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.

CTS com tecnologia de desenvolvedor

Esta página descreve as diretrizes de uso do CTS com tecnologia de desenvolvedor (CTS-D).

Cobertura de teste

O CTS-D, assim como o CTS e o CTS Verifier, só pode aplicar o seguinte:

Todas as APIs públicas descritas no SDK para desenvolvedores (developer.android.com) para um determinado nível de API.
Todos os requisitos obrigatórios incluídos no Documento de definição de compatibilidade do Android (CDD) para um determinado nível de API.

Os requisitos não obrigatórios, como "FORTEMENTE RECOMENDADO", "DEVE" e "PODE", são opcionais e não podem ser testados usando o CTS.

Como todas as APIs e os requisitos do CDD estão vinculados a um nível de API específico, todos os testes do CTS (CTS, CTS-D e CTS Verifier) são vinculados ao mesmo nível de API que as APIs ou os requisitos associados. Se uma API específica for descontinuada ou alterada, o teste correspondente precisará ser descontinuado ou atualizado.

Regras de criação de testes CTS

Um teste precisa produzir o mesmo resultado objetivo de forma consistente.
Um teste precisa determinar se um dispositivo é aprovado ou reprovado testando-o uma vez.
Os criadores de testes precisam remover todos os fatores possíveis que possam afetar os resultados.
Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração precisa ser claramente definida na mensagem de confirmação. Para conferir exemplos de instruções de configuração, consulte Como configurar o CTS.
O teste não pode ser executado por mais de 6 horas de cada vez. Se precisar ser executado por mais tempo, inclua o raciocínio na proposta de teste para que possamos analisá-la.

Confira a seguir um exemplo de conjunto de condições de teste para testar uma restrição de app:

O Wi-Fi está estável (para um teste que depende do Wi-Fi).
O dispositivo permanece parado durante o teste (ou não, dependendo do teste).
O dispositivo está desconectado de qualquer fonte de alimentação com X% de nível de bateria.
Nenhum app, serviço em primeiro plano ou serviço em segundo plano está em execução, exceto o CTS.
A tela fica desligada durante a execução do CTS.
O dispositivo NÃO é isLowRamDevice.
A economia de bateria / restrições de app não foram alteradas do estado "padrão".

Testar a qualificação

Aceitamos novos testes que apliquem um comportamento que não é testado por testes de CTS, CTS Verifier ou CTS-D. Qualquer teste que verifique um comportamento fora do escopo da nossa cobertura de teste será rejeitado.

Processo de envio do CTS

Escrever uma proposta de teste:um desenvolvedor de apps envia uma proposta de teste usando o Google Issue Tracker, descrevendo o problema identificado e propondo um teste para verificar isso. A proposta precisa incluir o ID do requisito de CDD associado. A equipe do Android analisa a proposta.
Desenvolver um teste CTS:depois que uma proposta é aprovada, o remetente cria um teste CTS no AOSP no branch principal (AOSP/main). A equipe do Android analisa o código.
Publicar teste:envie seu CL no AOSP/main e selecione-o para o branch androidx-tests-dev mais recente. O teste já está disponível publicamente.

Diretrizes para a elaboração de testes CTS-D

Siga o Guia de estilo de código Java.
Siga todas as etapas descritas em Desenvolvimento do CTS.
Adicione seus testes ao plano de teste apropriado:
- Use include-filters para adicionar novos testes ao plano de teste do CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Use exclude-filters para excluir os novos testes do plano de teste principal do CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
Processe todos os avisos e sugestões de errorprone em build_error.log.
Rebaseie as mudanças em head. Isso inclui os planos de teste cts-developer.xml e cts-developer-exclude.xml.
Trabalhe com seu contato de engenharia do Google para determinar se o caso de teste pode ser incluído em um módulo CTS existente. Se não for possível, eles vão ajudar você a criar um novo módulo.
Para cada novo módulo de teste criado, crie um arquivo OWNERS no diretório do novo módulo de teste.
- O arquivo OWNERS precisa conter as seguintes informações, obtidas do proprietário do teste do Google com quem você está trabalhando:
- # Bug component: xxx
- Proprietário de teste do Google ldap
Em AndroidTest.xml, especifique os seguintes parâmetros. Consulte os arquivos de exemplo (1, 2) para conferir exemplos:
- Instant_app ou not_instant_app
- secondary_user ou not_secondary_user
- all_foldable_states ou no_foldable_states
Para especificar o minSDK correto, consulte a documentação de <uses-sdk>.
Ao verificar novos métodos, classes ou módulos de teste, adicione-os ao plano de teste do CTS-D e exclua-os do plano de teste principal do CTS da mesma forma que para novos testes.

Executar o teste CTS-D

Execute o plano de teste CTS-D na linha de comando usando run cts --plan cts-developer.

Para executar um caso de teste específico, use run cts --include-filter "test_module_name test_name".

Para informações sobre como executar o CTS completo, consulte Executar testes do CTS.

Aceitação e liberação

Depois que uma solicitação de teste é enviada, uma equipe interna a analisa para garantir que ela testa um requisito do CDD ou um comportamento documentado da API. Se o teste for determinado como uma verificação de requisito ou comportamento válido, a equipe vai encaminhar o caso de teste a um engenheiro do Google para uma análise mais detalhada. O engenheiro do Google vai entrar em contato com você para dar feedback sobre como o teste pode ser melhorado antes de ser aceito no CTS.

Consulte Programação de lançamentos e informações sobre ramificações para saber mais sobre a programação de lançamentos do CTS.