English
Русский
简体中文
繁體中文
Tiếng Việt
Bahasa Indonesia
Português
Español
Um emulador Android no navegador pode significar duas coisas bem diferentes. Ou a própria aba emula um celular, ou a aba é uma janela para um Android que roda em outro lugar, com a tela transmitida para você e os seus cliques enviados de volta. Para qualquer versão atual do Android, só a segunda funciona.
Mesmo assim, sobram cinco opções práticas, de um experimento de fim de semana a um celular que você mantém por meses. Veja o que cada uma roda, o que exige para configurar e para quem serve, e depois uma tabela que coloca todas lado a lado.
1. Emulação dentro da aba
O WebAssembly tornou possível compilar um emulador de PC para rodar dentro de uma página web. O v86 é o exemplo mais conhecido: ele emula um PC x86 de 32 bits e inicializa pequenos sistemas Linux e sistemas operacionais antigos numa aba. Os projetos dessa família são uma engenharia impressionante e divertidos de testar.
Eles não são uma forma de rodar o Android atual. Um sistema Android moderno precisa de gigabytes de memória, uma CPU rápida e uma GPU, e um emulador rodando dentro de um motor JavaScript não tem nenhuma dessas folgas. Não conheço nenhum projeto que rode uma versão atual do Android numa aba a uma velocidade usável, então desconfie de promessas de "Android completo no navegador, sem instalar nada e sem streaming".
2. Seu próprio emulador, transmitido para o navegador
Se você controla um servidor Linux com KVM, as próprias ferramentas do Google conseguem colocar a tela de um emulador numa aba do navegador.
- Android Emulator em contêiner. Os android-emulator-container-scripts, de código aberto, do Google empacotam o emulador em Docker e acrescentam uma ponte WebRTC com um pequeno front-end web.
- Cuttlefish. O aparelho virtual do Google pensado para servidores tem sua própria interface WebRTC. Com um aparelho rodando, a tela e os controles abrem no navegador, por padrão na porta 8443 do host.
HOME=$PWD ./bin/launch_cvd --daemon adb devices
Esse caminho é software livre e dá controle total, incluindo ADB para cada instância. O preço é o host: KVM, imagens, atualizações, TLS, autenticação e planejamento de capacidade ficam todos por sua conta. Serve para equipes que já operam infraestrutura Linux e querem emuladores dentro da própria rede.
3. Streaming de emulador hospedado
Vários serviços rodam emuladores para você e os transmitem para uma página, muitas vezes como um player incorporável. Eles foram feitos para prévias de apps: uma demo numa landing page, uma captura de tela interativa na documentação, um atendente de suporte guiando um cliente pelas configurações, um revisor abrindo um build sem instalar nada.
As sessões costumam ser curtas e partem de uma imagem limpa a cada vez, e o aparelho é um perfil de emulador genérico. Isso é ideal para uma demo e limitante para tudo o que depende do modelo do celular ou de um estado que precisa sobreviver até amanhã.
4. Nuvens de aparelhos reais
As nuvens de aparelhos mantêm racks de celulares físicos e os transmitem para o seu navegador. Você recebe a coisa real: firmware e interface do fabricante, câmera, GPU e bateria. É o mais perto que dá para chegar de um celular na mão sem ter um.
As concessões vêm do hardware compartilhado. As sessões têm tempo limitado, o celular costuma ser apagado quando você sai, modelos populares podem estar ocupados, e o preço reflete o custo de manter aparelhos físicos funcionando. O Device Streaming do Android Studio segue o mesmo modelo, mas transmite celulares físicos para a IDE em vez do navegador, e muitas vezes é isso que o desenvolvedor que procura um emulador no navegador realmente quer.
5. Celulares na nuvem
Um celular na nuvem é um Android rodando num data center como um modelo específico de celular, guardado para você como um aparelho. Você abre a tela no navegador, controla com mouse e teclado e volta a ele depois: apps, logins e dados ficam até você redefinir.
O Clousd funciona assim: celulares feitos a partir de mais de 150 modelos reais com Android 12 a 17, prontos em cerca de um minuto, com uma API REST, um servidor MCP para agentes de IA e ADB por um relay, além da tela no navegador. Os limites são os mesmos de todo celular virtualizado: sem câmera nem sensores reais, e um desempenho gráfico que não representa o aparelho físico. A lista de modelos mostra o que está disponível.
As cinco lado a lado
| Emulação na aba | Auto-hospedado, com streaming | Streaming de emulador hospedado | Nuvem de aparelhos reais | Celular na nuvem | |
|---|---|---|---|---|---|
| O que roda | um emulador dentro da aba | Android Emulator ou Cuttlefish no seu servidor | Android Emulator no servidor deles | celulares físicos | Android em servidores, configurado como um modelo de celular |
| Android atual | não | sim | sim | sim | sim |
| Aparelho apresentado | não se aplica | genérico | genérico | o celular real | o modelo escolhido |
| Configuração | nenhuma | host Linux com KVM | nenhuma | nenhuma | nenhuma |
| Estado entre sessões | não | se você mantiver | em geral não | em geral apagado | mantido |
| ADB | não | sim | depende | em geral sim | em geral sim, por um relay |
| Melhor para | curiosidade | frotas internas | demos e prévias | testes que dependem do hardware | testes, celulares de longa duração, agentes |
Para entender melhor como um emulador num servidor difere de um celular feito a partir de um modelo real, veja o texto sobre emulador Android na nuvem.
O que verificar antes de escolher
- Latência. Cada toque viaja até o servidor e o novo quadro volta. A distância pesa mais que a banda: um servidor em outro continente acrescenta um atraso que você sente a cada deslize. Os servidores do Clousd ficam na UE, em Frankfurt e Helsinque, então as idas e voltas mais curtas são a partir da Europa.
- Entrada. Teste digitar com o teclado, colar da área de transferência, um gesto de pinça e a ação de voltar. É aqui que as sessões no navegador mais diferem.
- Google Play. Imagens de emulador vêm com ou sem Play; aparelhos físicos têm; celulares na nuvem variam conforme o provedor. Se o seu teste precisa do Play services, confira antes de começar.
- Logs. Uma sessão só no navegador mostra um crash, mas não o motivo. Garanta acesso ao logcat, de preferência por ADB. A documentação de ADB mostra como isso fica com um relay.
- Para onde vai o seu build. Enviar um APK para um serviço que você não consegue identificar é entregar o seu código a um estranho. Nunca envie um build com chaves de produção dentro.
Qual usar para cada trabalho
- Mostrar um app a um cliente ou revisor: streaming de emulador hospedado, ou um celular na nuvem se a pessoa precisar voltar a ele.
- Testar layouts nos celulares que seus usuários têm: um celular na nuvem ou uma nuvem de aparelhos reais.
- Câmera, sensores, desempenho: uma nuvem de aparelhos reais ou um celular na sua mesa.
- Emuladores dentro da sua própria rede: Cuttlefish auto-hospedado ou o contêiner do emulador.
- Um celular mantido por semanas, ou um para um agente de IA: um celular na nuvem.
- Depurar o app que você está escrevendo: nenhuma das opções acima. Use o emulador do Android Studio na sua própria máquina.
Se você vai fazer uma primeira sessão de testes, testar um app Android online mostra a instalação, os logs e um teste rápido que dá para repetir.
As opções grátis
A emulação na aba é grátis e não roda o Android atual. O streaming auto-hospedado é software livre num hardware que você paga e mantém. As nuvens de aparelhos reais e os serviços de emulador hospedado oferecem planos grátis limitados ou períodos de teste. Os celulares na nuvem também costumam ter um teste; o teste grátis do celular na nuvem dá 30 minutos sem cartão. Para o caminho mais curto entre um link e um app rodando, veja emulador Android online.
