O Android Open Source Project (AOSP) oferece várias ferramentas e pacotes de testes para testar várias partes da implementação. Antes de usar as páginas você deve estar familiarizado com os seguintes termos:
- Dispositivo compatível com Android
- Um dispositivo que pode executar qualquer app criado por desenvolvedores de terceiros usando o SDK e o NDK do Android. Dispositivos compatíveis com Android precisam atender aos requisitos do Documento de definição de compatibilidade (CDD) e ser aprovados no Conjunto de teste de compatibilidade (CTS). Compatível com Android são qualificados para participar do ecossistema Android, que inclui potencial de licenciamento do Google Play, possível licenciamento do Pacote dos Serviços do Google Mobile (GMS) de app e APIs e o uso da marca registrada do Android. Qualquer pessoa é bem-vinda usam o código-fonte do Android, mas, para serem considerados parte do ecossistema Android, um dispositivo precisa ser compatível com Android.
- artefato
- Um registro relacionado ao build que permite a solução local de problemas.
- Documento de definição de compatibilidade (CDD)
- Um documento que enumera os requisitos de software e hardware de um dispositivo compatível com o Android.
- Conjunto de teste de compatibilidade (CTS)
Um pacote de testes de nível comercial grátis para download como binário ou como fonte no AOSP. O CTS é um pacote de testes de unidade criado para integração no seu fluxo de trabalho diário. A intenção do CTS é revelar incompatibilidades garantem que o software permaneça compatível durante todo o processo de desenvolvimento.
Testes de CTS e de plataforma não são mutuamente exclusivos. Confira algumas diretrizes:
- Se um teste declarar a correção das funções ou dos comportamentos da API do framework, e o teste precisa ser aplicado em todos os parceiros OEM, ele precisa estar no CTS.
- Se um teste for destinado a capturar regressões durante o desenvolvimento da plataforma, e podem exigir permissão privilegiada para realizar e podem depender nos detalhes de implementação (conforme lançado no AOSP), ele precisa ser uma plataforma teste.
- Serviços do Google Mobile (GMS)
Uma coleção de APIs e apps do Google que podem ser pré-instalados em dispositivos.
- GoogleTest (GTest) (link em inglês)
Um framework de teste e simulação C++. Binários do GTest normalmente acessar camadas de abstração de nível inferior ou realizar uma IPC bruta em vários sistemas serviços. A abordagem de teste para o GTest geralmente está fortemente associada à que está sendo testado. O CTS contém a estrutura GTest.
- teste de instrumentação
Ambiente especial de execução de teste iniciado pelo comando
am instrument
, em que o processo do app de destino for reiniciado e inicializado com um contexto básico de app e um linha de execução de instrumentação for iniciada dentro do ambiente virtual do processo do app máquina virtual. O CTS contém testes de instrumentação.- Logcat
Uma ferramenta de linha de comando que cria um registro de mensagens do sistema, incluindo rastreamentos de pilha de quando o dispositivo gera um erro e mensagens que você programados no app com a classe
Log
.- geração de registros
Usar um registro para acompanhar eventos do sistema do computador, como como erros. Fazer login no Android é complexo, devido à combinação de padrões usados que são combinados na ferramenta Logcat.
- teste pós-envio
Um teste do Android que é realizado quando um novo patch é confirmado em um uma ramificação comum do kernel. Ao inserir
aosp_kernel
como um nome parcial da ramificação, você pode ver uma lista de ramificações de kernel com resultados disponíveis. Por exemplo, os resultados deandroid-mainline
podem ser encontradas em https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- teste de pré-envio
Um teste usado para evitar que falhas sejam introduzidas no aos kernels comuns.
- Trade Federation (link em inglês)
Também chamado de Tradefed, um teste contínuo projetado para executar testes em dispositivos Android. Por exemplo: O Tradefed é usado para executar testes de conjunto de teste de compatibilidade e conjunto de teste de fornecedor.
- Pacote de testes de fornecedor (VTS)
Um conjunto amplo de recursos para Testes do Android, promoção de um processo de desenvolvimento orientado a testes e automação camada de abstração de hardware (HAL) e testes de kernel do SO.
Tipos de teste de plataforma
Um teste de plataforma normalmente interage com um ou mais dos sistemas Android. ou camadas de HAL, exercita a funcionalidades do objeto em teste e declara a exatidão do o resultado dos testes. Um teste de plataforma pode:
- (Tipo 1) APIs de framework de exercício usando o framework do Android. APIs específicas que estão sendo
exercitados podem incluir:
- APIs públicas destinadas a apps de terceiros
- APIs ocultas destinadas a aplicativos privilegiados, ou seja, APIs do sistema ou
APIs particulares (
@hide
, ouprotected
,package private
)
- (Tipo 2) Invocar serviços do sistema Android usando um binder bruto ou proxies IPC diretamente.
- (Tipo 3) Interagir diretamente com HALs usando APIs de baixo nível ou interfaces IPC.
Os testes dos tipos 1 e 2 costumam ser de instrumentação, e os testes do tipo 3 são geralmente são GTests.
Qual é a próxima etapa?
Confira abaixo uma lista de documentos que você pode ler para ter informações mais detalhadas:
Se você ainda não estudou a arquitetura do Android, consulte Visão geral da arquitetura.
Se você está criando um dispositivo compatível com Android, consulte a visão geral do programa de compatibilidade do Android.
Para integrar testes de host de instrumentação, funcionais, métricas e JAR. em um serviço de teste contínuo da plataforma, consulte Fluxo de trabalho de desenvolvimento de testes.
Para detectar e proteger seus dispositivos contra vulnerabilidades, consulte Testes de segurança.
Para saber mais sobre como testar suas implementações de HAL e kernel, consulte Conjunto de testes de fornecedor (VTS) e infraestrutura.
Para testar apps, leia Conceitos básicos de testes no Android apps e conduzir o curso Advanced Android in Kotlin 05.1:Testing Noções básicas usando o método amostras fornecidas.
Saiba mais sobre os testes básicos de pré-envio disponíveis com hooks de repo. Esses ganchos podem ser usados para executar lints, verificar a formatação e acionar a unidade. testes antes de continuar, como fazer upload de uma confirmação. Esses ganchos estão desativados por padrão. Para mais informações, consulte Pré-upload do AOSP Ganchos.
Para ler mais sobre a geração de registros, consulte Noções básicas sobre a geração de registros.
Para entender como depurar o código do Android, consulte Depurar o código nativo da Plataforma Android