Emulador Android na nuvem ou celular na nuvem

Pesquise por emulador Android na nuvem e você vai encontrar dois produtos diferentes com o mesmo nome. Um é o Android Emulator, o mesmo que vem com o Android Studio, rodando num servidor que você aluga ou que outra empresa opera. O outro é um celular na nuvem: um Android rodando num data center, configurado como um modelo específico de celular e guardado para você como um aparelho.

Para dar uma olhada rápida num app, qualquer um serve. Para testes, automação e trabalho de longa duração, eles se comportam de forma diferente, e escolher o errado custa tempo. Este texto mostra o que roda por baixo, o que o seu app enxerga e quando cada um é a ferramenta certa.

Três formas de rodar Android num servidor

O Android Emulator. Uma máquina virtual baseada em QEMU com hardware virtual que o Google chama de goldfish e, nas versões atuais, ranchu. Ele inicializa as imagens de sistema que você baixa no SDK Manager. Só é rápido com virtualização de hardware, que num servidor Linux significa KVM, então rodá-lo numa VM de nuvem exige virtualização aninhada ou uma instância bare metal. Sem aceleração, ele cai para a emulação por software e fica lento demais para uso interativo.

Cuttlefish. O aparelho virtual do Google feito para servidores, e não para desktops. Ele roda sem tela, entrega a tela para o navegador via WebRTC e é muito usado nos testes da plataforma Android. É a melhor base se você está montando a sua própria frota de emuladores, e pressupõe que você esteja à vontade com hosts Linux e builds do AOSP.

Android em contêiner. O espaço de usuário do Android roda num contêiner sobre o kernel Linux do host, que precisa ter suporte a binder. Projetos de código aberto como Anbox, Waydroid e redroid funcionam assim, assim como muitos serviços de celular na nuvem, muitas vezes em servidores ARM em que os apps arm64 rodam sem tradução. Não há uma máquina virtual completa por celular, e é por isso que essa abordagem escala para muitos celulares por servidor.

O que o seu app enxerga

Rode três comandos num emulador e a resposta fica evidente:

adb shell getprop ro.product.model
adb shell getprop ro.hardware
adb shell wm size

Uma imagem de sistema do Google responde com um modelo como sdk_gphone64_x86_64 ou sdk_gphone64_arm64, hardware ranchu e o tamanho de tela que a definição do AVD deu a ela. Isso serve para testar a sua própria lógica. Mas esconde tudo o que depende da classe do aparelho: bugs de layout que só aparecem no tamanho e na densidade de uma tela real, verificações de recursos via hasSystemFeature e código de mídia que escolhe um codec conforme o que o chipset oferece.

Um celular na nuvem feito a partir de um modelo real informa esse modelo: o nome, a resolução e a densidade da tela, a versão do Android e a descrição do hardware. Os seus layouts encontram as telas que os seus usuários têm, e um relato de bug de um celular específico pode ser reproduzido no mesmo modelo.

Duas ressalvas mantêm a conversa honesta. Primeiro, pergunte o que "modelo real" significa em cada serviço: a tela e a descrição de hardware do modelo, ou o próprio firmware do fabricante com a sua interface. Bugs que moram no otimizador de bateria ou no launcher de um fabricante precisam desse firmware, o que na prática significa o celular físico. Segundo, os gráficos em qualquer Android virtualizado são traduzidos ou renderizados por software, então nem um emulador nem um celular na nuvem dizem a velocidade com que o seu app desenha em hardware real.

A arquitetura também importa. Numa imagem de emulador x86_64, as bibliotecas nativas arm64 rodam por uma camada de tradução que o Google inclui nas imagens a partir do Android 11. Funciona para a maioria dos apps e quebra alguns, principalmente jogos e apps com muito código nativo. Em hosts ARM, as imagens arm64 rodam esse código nativamente.

Lado a lado

Se você também está avaliando um VPS Android, celular na nuvem, emulador ou VPS Android compara os três em oito critérios.

Quando o emulador é a ferramenta certa

O emulador vence sempre que a velocidade de iteração e o controle das condições importam mais do que a classe do aparelho.

• O ciclo de editar e rodar. Depurador, layout inspector, previews do Compose e deploys instantâneos pressupõem um emulador local ou um celular no cabo.
• Testes instrumentados no CI. Os Gradle Managed Devices definem AVDs no arquivo de build e rodam os testes com uma única task, por exemplo ./gradlew pixel6api34DebugAndroidTest. Num host de CI comum, uma inicialização sem tela fica assim:

emulator -avd ci-api34 -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect
adb wait-for-device
./gradlew connectedDebugAndroidTest

• Condições simuladas. O console do emulador define localização, bateria e qualidade da rede quando você quiser, algo que nenhum celular real ou na nuvem faz com a mesma facilidade:

adb emu geo fix 13.405 52.52
adb emu power capacity 5
adb emu network speed edge

• Todos os níveis de API, inclusive prévias. O Google publica imagens de sistema para versões novas antes de os celulares as receberem.

Quando um celular na nuvem é a ferramenta certa

Um celular na nuvem vence quando o próprio aparelho faz parte da pergunta, ou quando o celular precisa durar mais que uma sessão de teste.

• Modelos reais. Reproduza um relato de um celular específico ou confira layouts nas telas que os seus usuários realmente têm. A lista de modelos mostra o que está disponível.
• Celulares que persistem. Continue logado com contas de teste, mantenha dados de um dia para o outro e acompanhe o comportamento ao longo de horas, algo que um emulador de CI descartado a cada job não consegue fazer.
• Nada para instalar. Um tester, designer ou engenheiro de suporte abre o celular no navegador. Desenvolvedores que querem a experiência do cabo usam ADB.
• Agentes de IA. Um agente precisa de um celular que possa observar e operar pelo tempo que a tarefa durar; a página de agentes trata desse uso.
• Países. Os apps se comportam de forma diferente conforme a região, e o celular pode se conectar a partir do país de que você precisa.

No Clousd, por exemplo, um celular é criado em cerca de um minuto com Android 12 a 17, se conecta a partir do país que você escolher com fuso horário e idioma correspondentes e pode voltar a um estado limpo entre execuções.

Quando só um celular físico resolve

Guarde o hardware real para qualidade de câmera, precisão de sensores, desempenho gráfico e de bateria, comportamento térmico, NFC e Bluetooth e tudo o que depende do firmware de um fabricante. A atestação baseada em hardware também entra aqui: não espere isso de nenhum Android virtualizado.

Opções grátis

As buscas por "emulador android grátis na nuvem" costumam terminar em um de três lugares.

1. A sua própria máquina. O Android Emulator é grátis e rápido em qualquer notebook recente. Para muitos desenvolvedores, essa é a resposta certa, e nenhuma nuvem é necessária.
2. Runners de CI. Muitos serviços de CI hoje expõem o KVM nos runners Linux, então o emulador roda com aceleração dentro de um plano grátis, principalmente em repositórios públicos. Confira a documentação do seu provedor; alguns exigem antes uma mudança de permissão em /dev/kvm.
3. Testes de celulares hospedados. Para uma olhada rápida num app em um modelo real sem instalar nada, um teste grátis de celular na nuvem dá 30 minutos sem cartão.

Um alerta. Sites que oferecem um emulador online grátis e pedem que você envie um APK sem criar conta estão entregando o seu build a alguém desconhecido. Não envie builds de release e nunca envie um build com chaves de produção dentro. Se o objetivo é só abrir um app no navegador, um emulador Android online de um provedor que você consegue identificar é o caminho mais seguro, e emulador Android no navegador compara as opções.