O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Infraestrutura de teste automatizado

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 do sistema genérico AOSP (GSI). Anteriormente, a execução desses testes era uma operação altamente manual; a nova infraestrutura de teste VTS foi projetada para suportar testes automatizados várias vezes ao dia em vários dispositivos.

Arquitetura

A infraestrutura de teste automatizado VTS usa a seguinte arquitetura:

Automated test architecture

Figura 1. Arquitectura VTS infra-estrutura de testes automatizados

Quando um teste é acionado, a infraestrutura de teste automatizado VTS executa as seguintes tarefas:

  1. Coleta artefatos de construção e recursos de teste em diferentes locais:
    • Desenvolver parceiro Android (PAB). Para a estrutura GSI, VTS e algumas outras compilações.
    • Sistema de arquivos local, Google Cloud Storage, ou outro sistema de construção específica do fornecedor. Para parceiros que não armazenam compilações na nuvem do Google.
  2. Flashes criam artefatos (do dispositivo) e o GSI (do AOSP) no (s) dispositivo (s) conectado (s).
  3. Executa testes VTS usando TradeFed local ou TradeFed na nuvem.
  4. Relatórios de resultados de teste para o painel VTS

O processo é coordenado pelo VTS host controller (HC), uma máquina do laboratório que direciona o comportamento de todos os dispositivos conectados em teste. O HC é responsável por buscar as compilações mais recentes, atualizá-las nos dispositivos e invocar testes (localmente ou por meio do comandante). Ele também se comunica com um planejador de nuvem e direciona o tráfego entre o planejador e a instância TradeFed (ou algum outro chicote) em execução no HC. Para mais detalhes sobre o controlador de host, consulte Host Controller Architecture .

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 construí-los regularmente a partir da ponta da árvore do que postar os artefatos para download.

Os parceiros podem acessar recursos de automação usando os seguintes locais:

  • Desenvolver parceiro Android. Acesso programático concedido por conta.
  • Sistema de arquivos local (ou semelhante). Para parceiros que não usam o Partner Android Build.

Para uso em piscar os dispositivos mais tarde, recursos incluem provedores de compilação para ambas as opções, que se estende desde um único build_provider.py que armazena as compilações em diretórios temporários locais.

Partner Android Build

No Android 8.1 e versões mais baixas, parceiros Android eram obrigados a visitar o site do Parceiro Android Construir ( https://partner.android.com/build ), navegar na sua conta, e buscar as imagens mais recentes do sistema através 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.

Estabelecendo 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 de cliente / segredo com o Google. Quando o PartnerAndroidBuildClient é apontado esse segredo, pela primeira vez, abre-se uma janela do navegador para o usuário para efetuar login em sua conta do Google, que gera as credenciais OAuth2 necessários para avançar. As credenciais (token de acesso e token de atualização) são armazenadas localmente, o que significa que os parceiros devem 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, alvo de compilação
  • nome do recurso
  • filial
  • nome do candidato de liberação e se o candidato é ou não uma construção interna

O pedido POST é recebido pelo downloadBuildArtifact método do buildsvc RPC, que retorna um URL que pode ser usado para acessar o recurso.

  • Para recursos de APK do Clockwork Companion, 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 Android Build interna (que expira após cinco minutos).

Obtendo o URL

Para evitar cross-site request forgery, o buildsvc RPC requer uma XSRF token para ser 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 PAB) agora também é necessário para o acesso.

Para evitar esse problema, o Android 9 reprojeta o esquema de nomenclatura 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; Scripts de HC pode baixar esses APKs facilmente, uma vez que o formato de URL é conhecido, e HC pode ignorar as questões XSRF / bolinho porque ele 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 construção define as imagens relevantes com base no que está no diretório. Você pode usar o gsutil ferramenta para copiar arquivos do Google Cloud Storage para um diretório local.

Flashing builds

Depois que as imagens mais recentes do dispositivo são baixadas para o host, essas imagens devem ser transferidas para os dispositivos. Isso é feito usando o padrão adb e fastboot comandos e subprocessos Python, com base nos caminhos de arquivos temporários armazenados pelos prestadores de construção.

Ações com suporte:

  • Piscando apenas o GSI
  • Intermitente de imagens individuais do sistema principal (por exemplo, fastboot flash boot boot.img )
  • Piscando todas as imagens do sistema principal. Exemplo:
    • fastboot flashall (usando o embutido flashall utilitário)
    • fastboot flash (um de cada vez)

Executando testes

No Android 9, a infraestrutura de teste automatizado VTS oferece suporte apenas para o equipamento de teste TradeFed, mas pode ser estendida para oferecer suporte a outros equipamentos no futuro.

Depois que os dispositivos estiverem preparados, você pode invocar testes usando uma das seguintes opções:

  • Quando se utiliza TradeFed localmente, usar o test comando no controlador hospedeiro, que recebe o nome de um programa de ensaio VTS (por exemplo vts-selftest ) e é executado o teste.
  • Quando se utiliza um TradeFed cluster (opcionalmente ligado a MTT), utilizar o lease de comando na consola do controlador hospedeiro, que olha para ensaios não satisfeitas.

Se estiver usando TradeFedCluster, TradeFed é executado localmente como um gerente remoto . Caso contrário, os testes são chamados usando subprocessos Python.

Resultados de relatórios

Os resultados do teste são automaticamente relatado para alguns projetos de painel VTS por VtsMultiDeviceTest .