Device farm Android: montar a sua ou usar a nuvem

Uma device farm Android é um conjunto de celulares de teste ligados a máquinas host, para que testes automatizados e pessoas possam usá-los sem pegá-los na mão. O termo vem do QA, e é nesse sentido que este artigo o usa: um pool compartilhado de aparelhos para rodar e reproduzir testes. Racks de celulares usados para operar contas em redes sociais em escala são outra coisa, violam os termos de todas as grandes plataformas e não são tratados aqui.

Toda equipe mobile chega ao ponto em que uma gaveta de celulares deixa de funcionar. Alguém levou o Pixel para casa, ninguém sabe qual celular está com qual build, e o CI roda num único emulador. Este guia mostra para que serve uma farm, o que um rack próprio envolve e custa e quando os celulares na nuvem fazem o mesmo trabalho.

Para que serve uma device farm

• Testes de interface automatizados numa matriz. Suítes de Espresso, UI Automator ou Appium em várias versões do Android e tamanhos de tela ao mesmo tempo, para que uma release candidate receba uma resposta clara.
• Reproduzir o bug de um usuário. O relato cita um modelo e uma versão do Android, e a farm tem esse celular ou algo próximo.
• Sessões manuais e exploratórias. Um tester abre um modelo específico remotamente em vez de pedir emprestado a um colega.
• Execuções longas. Sincronização em segundo plano, entrega de notificações e consumo de memória ao longo de horas, algo que um emulador descartado depois de cada job de CI não consegue mostrar.
• Smoke de release. O mesmo teste rápido em dez celulares em paralelo antes de um lançamento.

Anatomia de um rack próprio

Montar um rack não é difícil. O trabalho de verdade é mantê-lo saudável. Um rack típico tem cinco partes.

Celulares. Escolha-os pelos seus dados de analytics, não pelo que está em promoção: os modelos com mais sessões, a versão mais antiga do Android que você suporta e a mais nova. Compre dois do modelo mais comum, para que um fique em uso enquanto o outro roda o CI.

Energia e USB. Hubs com alimentação e corrente suficiente por porta, cabos curtos de boa qualidade e verba para controladoras USB do host. Como regra prática, o adb fica instável em algum ponto acima de dez a quinze celulares num mesmo host, dependendo da controladora e dos hubs.

Hosts. Pequenas máquinas Linux ou Macs, cada uma rodando o servidor adb da sua prateleira. Acompanhe os aparelhos pelo número de série e mantenha um mapa de qual celular está em qual porta, porque você vai precisar dele na pior hora.

Software. adb, um gerenciador de aparelhos como o DeviceFarmer (o sucessor comunitário do OpenSTF) para telas remotas e reservas, Appium com um grid se você testa via WebDriver, e o seu CI para agendar as execuções.

Manutenção. É a parte que ninguém coloca no orçamento. Baterias estufam quando os celulares passam meses no carregador, então use o limite de carga que alguns fabricantes oferecem ou tomadas inteligentes que cortam a energia em ciclos. Avisos de atualização do sistema aparecem no meio das execuções. Telas bloqueiam, notificações se acumulam, o armazenamento enche de mídia de teste, e um celular que travou de madrugada liga numa janela sem ninguém para tocar nela.

Quanto custa de verdade um rack

Para um rack de 20 celulares, uma estimativa aproximada para 2026 fica assim. Os celulares custam de $3 mil a $12 mil, conforme quantos topos de linha você precisa. Hubs, cabos, prateleiras e dois hosts somam de $1,5 mil a $4 mil. Depois, reserve todo ano de 20% a 30% do valor gasto em celulares para baterias estufadas, portas quebradas e os modelos novos que seus usuários compram.

A linha que surpreende as equipes é o tempo: de três a oito horas por semana de alguém destravando celulares, aplicando atualizações e reiniciando hosts. Os seus números vão ser outros, mas o formato não muda. O hardware é a parte menor da conta.

Os celulares na nuvem transformam isso num custo recorrente sem manutenção. No Clousd, o pagamento por minuto custa $0.004 por minuto enquanto o celular está ligado e nunca mais de $0.80 por celular por dia, e os planos começam em $20 por mês; os detalhes estão na página de preços. Dois exemplos com os mesmos 20 celulares:

• Duas horas por dia útil: 20 celulares × 120 minutos × $0.004 = $9.60 por dia, cerca de $211 em 22 dias úteis.
• 24 horas por dia: vale o teto diário, então 20 × $0.80 × 30 dias = no máximo $480 por mês.

Os minutos do pagamento por minuto param quando o celular para. Um modelo de que você precisa para um único relato de bug é um celular que você cria, usa e exclui.

Rack próprio, nuvem de aparelhos ou celulares na nuvem

O que a nuvem muda

• Começos limpos. Um celular é criado em cerca de um minuto e pode voltar a um estado limpo antes de cada suíte, então toda execução parte do mesmo lugar.
• Modelos como parâmetro. Android 12 a 17 em mais de 150 modelos reais, escolhidos a cada execução na lista de modelos, e não conforme o que está na prateleira.
• Remoto por padrão. Uma tela ao vivo no navegador para sessões manuais, uma API REST e ADB para o CI, e um servidor MCP quando um agente de IA faz a verificação.
• Sem tarefas de hardware. Nada estufa, nada precisa de cabo, nada precisa ser reiniciado às 2 da manhã.

O que ela não muda

Celulares na nuvem não são celulares físicos. Pipelines de câmera, precisão de sensores, desempenho de GPU, consumo de bateria, throttling térmico, NFC, Bluetooth e os gerenciadores de segundo plano de cada fabricante ainda exigem hardware real. A maioria das equipes acaba num modelo híbrido: três a cinco celulares físicos na mesa para essas verificações e a matriz ampla de modelos e versões na nuvem. Testar um app em diferentes versões do Android lista o que essa matriz deve cobrir.

Rodar testes na farm, esteja ela onde estiver

Os test runners identificam os celulares pelo serial do adb, então a mesma suíte roda num rack USB e em celulares remotos. O AndroidJUnitRunner pode dividir uma suíte entre aparelhos por shard:

R=com.example.app.test/androidx.test.runner.AndroidJUnitRunner
adb -s "$P12" shell am instrument -w -e numShards 3 -e shardIndex 0 $R
adb -s "$P14" shell am instrument -w -e numShards 3 -e shardIndex 1 $R
adb -s "$P16" shell am instrument -w -e numShards 3 -e shardIndex 2 $R

Rode as três linhas em paralelo e cada celular fica com um terço dos testes. O Appium escolhe o aparelho pela capability appium:udid, que recebe o mesmo serial. Celulares remotos entram no pool com adb connect; a documentação de ADB mostra como isso funciona através de um relay, e a página de testes de apps mostra o caminho pela API para o CI.

Conte com cada ação remota levando um pouco mais do que pelo USB e ajuste os timeouts dos testes de interface com isso em mente. Testes que passam num emulador local e estouram o tempo remotamente costumam ter uma pausa fixa no código ou uma espera apertada demais.

Farm de dispositivos móveis e farm de celulares na nuvem

Uma farm de dispositivos móveis é a mesma ideia, com iPhones e iPads na prateleira ao lado dos celulares Android. No QA, uma farm de celulares na nuvem é simplesmente o pool de celulares na nuvem em que a sua suíte roda. A palavra "farm" tem outros sentidos fora dos testes; o texto sobre phone farm trata deles.