ADB em grande escala: controlar muitos dispositivos ao mesmo tempo

Controlar um telemóvel a partir de um computador é uma parte rotineira do desenvolvimento de aplicações. Controlar mil telemóveis a partir de um computador é um problema de engenharia diferente, e é esse que faz as quintas de telemóveis funcionarem como infraestrutura utilizável, em vez de uma sala cheia de dispositivos operados individualmente. A ferramenta central por trás da maior parte disto no Android é o Android Debug Bridge, mais conhecido como ADB.

O que o ADB faz na prática

O ADB é uma ferramenta de linha de comandos, incluída no SDK padrão do Android, que permite a um computador host comunicar com um dispositivo Android ligado através de USB ou de uma ligação de rede. Pode instalar e desinstalar aplicações, enviar e obter ficheiros, emitir eventos de entrada simulados como toques e deslizes, capturar screenshots e transmitir os logs do dispositivo de volta para o host. Cada uma destas operações visa um único dispositivo por invocação — a unidade básica de controlo do ADB é um dispositivo, identificado por um número de série ou um endereço de rede.

De um dispositivo para muitos

Como o ADB se dirige aos dispositivos individualmente, controlar uma frota significa executar muitas sessões de ADB em paralelo em vez de inventar um novo protocolo. O software de orquestração assenta sobre o ADB (ou sobre uma API de automatização equivalente do fornecedor para plataformas não Android) e trata daquilo que o ADB não faz: manter uma lista de dispositivos ligados, colocar tarefas em fila, distribuí-las pelos dispositivos atualmente disponíveis, repetir falhas e agregar resultados num único relatório. Esta camada — uma primitiva de controlo simples por dispositivo mais uma camada de agendamento por cima — é o mesmo padrão básico descrito em como funcionam as quintas de telemóveis.

Endereçar e selecionar dispositivos

À escala de uma frota, uma tarefa raramente precisa de correr literalmente em todos os dispositivos sem distinção. As camadas de orquestração normalmente suportam a seleção de dispositivos por atributo — versão do sistema operativo, modelo, região ou estado de saúde atual —, de modo que um conjunto de testes de QA possa visar apenas dispositivos a correr uma versão específica do Android, ou uma tarefa de monitorização possa correr apenas contra dispositivos de um determinado conjunto geográfico. Este endereçamento seletivo é parte do que separa o uso básico de ADB por script de uma verdadeira orquestração de frota.

Paralelismo e os seus limites

Executar comandos em muitos dispositivos ao mesmo tempo não é infinitamente paralelo na prática. As máquinas host têm largura de banda USB ou de rede finita, e um único processo de servidor ADB a gerir demasiadas ligações de dispositivos em simultâneo pode tornar-se, ele próprio, um estrangulamento. As frotas maiores costumam repartir os dispositivos por várias máquinas host, cada uma a executar o seu próprio servidor ADB e um subconjunto da frota, com o software de orquestração a coordenar entre hosts em vez de assumir que um único computador consegue endereçar diretamente todos os dispositivos.

Fiabilidade em grande escala

Dispositivos individuais desligam-se, deixam de responder ou devolvem erros com frequência suficiente para que a automatização de frota tenha de esperar isso e lidar com isso, em vez de o tratar como excecional. Uma orquestração robusta repete comandos falhados, sinaliza dispositivos persistentemente sem resposta para uma verificação de saúde, e continua a operar o resto da frota em vez de parar por causa de um dispositivo problemático. Isto liga-se diretamente ao trabalho sobre o ciclo de vida do dispositivo abordado em ciclo de vida do dispositivo — um dispositivo que falha repetidamente em comandos ADB é muitas vezes candidato a manutenção ou substituição, não apenas uma falha transitória a repetir indefinidamente.

Onde isto se encaixa nos casos de uso da frota

A automatização orientada por ADB sustenta a maioria dos casos de uso comuns para quintas de telemóveis — os testes de QA instalam builds e leem os resultados através dele, as tarefas de monitorização programam interações repetidas através dele, e qualquer fluxo de trabalho que precise de controlar hardware Android real de forma programática acaba por passar pela mesma primitiva de controlo básica. O mesmo desafio de coordenação aplica-se quer a frota execute dispositivos físicos quer emulados, uma distinção abordada em emuladores vs dispositivos reais — o ADB trata ambos de forma idêntica, já que, para o protocolo, um emulador e um dispositivo real parecem muito semelhantes.

Para além do Android

As frotas que incluem hardware iOS dependem de uma stack diferente em vez do próprio ADB, uma vez que o ADB não tem homólogo em iOS. O controlo de interface no próprio dispositivo vem do XCUITest, controlado através de uma instância do WebDriverAgent a correr no telemóvel; a gestão de dispositivos do lado do host (instalar aplicações, ler o estado do dispositivo, gerir o provisionamento) passa normalmente por libimobiledevice ou go-ios. Tudo isto requer um host macOS — não há forma de executar o equivalente iOS de um servidor ADB em Linux ou Windows.

A natureza do problema é a mesma que no Android: uma primitiva de controlo por dispositivo, com orquestração sobreposta para colocar tarefas em fila, distribuí-las pelos dispositivos disponíveis e lidar com falhas de forma controlada. O que difere é a profundidade e a abertura — o ADB é uma ferramenta única e bem documentada que cobre, de raiz, a maior parte do que o controlo de frota necessita; a stack iOS é composta por várias ferramentas que fazem a ponte com a plataforma mais fechada da Apple, e exige a camada de host macOS de que o Android prescinde. Consulte frotas iOS vs Android para uma comparação mais completa das duas stacks de automatização e do que custa operá-las.