O Android 9 inclui uma infraestrutura Vendor Test Suite (VTS) para testes automatizados de VTS, CTS ou outros testes em dispositivos parceiros que executam a imagem de sistema genérico AOSP (GSI). Anteriormente, executar esses testes era uma operação altamente manual; a nova infraestrutura de teste VTS foi projetada para oferecer suporte a testes automatizados várias vezes ao dia em vários dispositivos.
Arquitetura
A infraestrutura de teste automatizado VTS usa a seguinte arquitetura:
Quando um teste é acionado, a infraestrutura de teste automatizado do VTS realiza as seguintes tarefas:
- As buscas constroem artefatos e testam recursos de diferentes locais:
- Parceiro Android Build (PAB) . Para a estrutura GSI, VTS e algumas outras compilações.
- Sistema de arquivos local, Google Cloud Storage ou outro sistema de compilação específico do fornecedor . Para parceiros que não armazenam builds na nuvem do Google.
- Os flashes criam artefatos (do dispositivo) e o GSI (do AOSP) no(s) dispositivo(s) conectado(s).
- Executa testes VTS usando TradeFed local ou um TradeFed na nuvem.
- Reporta os resultados do teste para o painel VTS
O processo é coordenado pelo VTS host controller (HC), uma máquina no laboratório que direciona o comportamento de todos os dispositivos conectados sob teste. O HC é responsável por buscar as compilações mais recentes, exibi-las nos dispositivos e invocar testes (localmente ou por meio do comandante). Ele também se comunica com um agendador de nuvem e direciona o tráfego entre o agendador e a instância TradeFed (ou algum outro chicote) em execução no HC. Para obter detalhes sobre o controlador de host, consulte Arquitetura do controlador de host .
Provedores de recursos
O teste automatizado requer recursos como compilações de sistema, arquivos de teste e artefatos VTS. Embora seja possível construí-los a partir do código-fonte, é mais fácil criá-los regularmente a partir da ponta da árvore e postar os artefatos para download.
Os parceiros podem acessar recursos de automação usando os seguintes locais:
- Parceiro Android Build . Acesso programático concedido por conta.
- Sistema de arquivos local (ou similar). Para parceiros que não usam o Partner Android Build.
Para uso na atualização dos dispositivos posteriormente, os recursos incluem provedores de compilação para ambas as opções, estendendo-se a partir de um único build_provider.py que armazena as compilações em diretórios temporários locais.
Compilação do Android do parceiro
No Android 8.1 e versões anteriores, os parceiros do Android precisavam visitar o site Partner Android Build ( https://partner.android.com/build ), navegar até a conta e buscar as imagens mais recentes do sistema por meio da interface do usuário. Para ajudar os parceiros a evitar esse processo lento e trabalhoso, o Android 9 inclui suporte para baixar automaticamente esses recursos do PAB quando as credenciais apropriadas são fornecidas.
Estabelecer acesso
O acesso programático usa OAuth2 nas APIs do Google para acessar os RPCs necessários. Usando a abordagem padrão para gerar credenciais OAuth2, o parceiro deve configurar um par ID/segredo do cliente com o Google. Quando o PartnerAndroidBuildClient é apontado para esse segredo pela primeira vez, ele abre uma janela do navegador para o usuário fazer login em sua conta do Google, que gera as credenciais OAuth2 necessárias para seguir em frente. As credenciais (token de acesso e token de atualização) são armazenadas localmente, o que significa que os parceiros precisam fazer login apenas uma vez.
Solicitação POST para URL
Clicar em um link de recurso no PAB envia uma solicitação POST que inclui os dados necessários para esse recurso, incluindo:
- ID de compilação, destino de compilação
- nome do recurso
- filial
- nome do candidato a lançamento e se o candidato é ou não uma compilação interna
A solicitação POST é recebida pelo método downloadBuildArtifact do buildsvc RPC, que retorna uma URL que pode ser usada para acessar o recurso.
- Para recursos do Clockwork Companion APK, o URL é um URL legível hospedado no PAB (que é protegido por autenticação e acessível com as credenciais OAuth2 apropriadas).
- Para outros recursos, o URL é um URL longo e não protegido da API interna do Android Build (que expira após cinco minutos).
Obter o URL
Para evitar a falsificação de solicitação entre sites, o buildsvc RPC requer que um token XSRF seja POSTado com os outros parâmetros. Embora esse token torne o processo mais seguro, ele também torna o acesso programático muito mais difícil, pois o token (que está disponível apenas no JavaScript da página do PAB) agora também é necessário para acesso.
Para evitar esse problema, o Android 9 redesenhou o esquema de nomeação de URL para todos os arquivos (não apenas APKs) para usar nomes de URL previsíveis para acessar listas de artefatos e URLs de artefatos. O PAB agora usa um formato de URL conveniente que permite que os parceiros baixem recursos; Os scripts HC podem baixar esses APKs facilmente, pois o formato da URL é conhecido, e o HC pode ignorar os problemas de XSRF/cookie porque não precisa do buildsvc RPC.
Sistema de arquivos local
Dado um diretório com uma lista (ou arquivo zip) de artefatos, o provedor de compilação define as imagens relevantes com base no que está no diretório. Você pode usar a ferramenta gsutil para copiar arquivos do Google Cloud Storage para um diretório local.
Compilações em Flash
Após o download das imagens mais recentes do dispositivo para o host, essas imagens devem ser atualizadas nos dispositivos. Isso é feito usando os comandos padrão adb e fastboot e subprocessos do Python, com base nos caminhos de arquivos temporários armazenados pelos provedores de compilação.
Ações suportadas:
- Piscando apenas o GSI
- Piscando imagens individuais do sistema principal (por exemplo,
fastboot flash boot boot.img) - Piscando todas as imagens do sistema principal. Exemplo:
-
fastboot flashall(usando o utilitárioflashallintegrado) -
fastboot flash(um de cada vez)
-
Executar testes
No Android 9, a infraestrutura de teste automatizado VTS oferece suporte apenas ao equipamento de teste TradeFed, mas pode ser estendido para oferecer suporte a outros sistemas no futuro.
Após a preparação dos dispositivos, você pode invocar testes usando uma das seguintes opções:
- Ao usar o TradeFed localmente, use o comando
testno controlador do host, que recebe o nome de um plano de teste VTS (por exemplo,vts-selftest) e executa o teste. - Ao usar um cluster TradeFed (opcionalmente conectado ao MTT), use o comando
leaseno console do controlador do host, que procura execuções de teste não realizadas.
Se estiver usando TradeFedCluster, TradeFed é executado localmente como um gerenciador remoto . Caso contrário, os testes são invocados usando subprocessos do Python.
Resultados do relatório
Os resultados do teste são relatados automaticamente para alguns projetos de painel VTS por VtsMultiDeviceTest .