English
Русский
简体中文
繁體中文
Tiếng Việt
Bahasa Indonesia
Português
Español
An Android emulator in the browser can mean two very different things. Either the tab itself emulates a phone, or the tab is a window onto Android running somewhere else, with the screen streamed to you and your clicks sent back. For any current Android release, only the second works.
That still leaves five practical options, from a weekend experiment to a phone you keep for months. Here is what each one runs, what it takes to set up and who it suits, followed by a table that puts them side by side.
1. Emulation inside the tab
WebAssembly made it possible to compile a PC emulator so that it runs inside a web page. v86 is the best-known example: it emulates a 32-bit x86 PC and boots small Linux systems and old operating systems in a tab. Projects in this family are impressive engineering and fun to try.
They are not a way to run current Android. A modern Android system wants gigabytes of memory, a fast CPU and a GPU, and an emulator running inside a JavaScript engine has none of that headroom. I know of no project that runs a current Android release in a tab at a usable speed, so treat promises of "full Android in your browser, nothing installed, nothing streamed" with suspicion.
2. Your own emulator, streamed to a browser
If you control a Linux server with KVM, Google's own tools can put an emulator's screen in a browser tab.
- Android Emulator in a container. Google's open-source android-emulator-container-scripts package the emulator in Docker and add a WebRTC bridge with a small web front end.
- Cuttlefish. Google's server-oriented virtual device serves its own WebRTC interface. Once a device is running, its screen and controls open in a browser, by default on port 8443 of the host.
HOME=$PWD ./bin/launch_cvd --daemon adb devices
This route is free software and gives you full control, including ADB to every instance. The price is the host: KVM, images, updates, TLS, authentication and capacity planning are all yours. It suits teams that already run Linux infrastructure and want emulators inside their own network.
3. Hosted emulator streaming
Several services run emulators for you and stream them into a page, often as an embeddable player. They are built for app previews: a demo on a landing page, an interactive screenshot in documentation, a support agent walking a customer through settings, a reviewer opening a build without installing anything.
Sessions are usually short and start from a clean image each time, and the device is a generic emulator profile. That is ideal for a demo and limiting for anything that depends on the phone model, or on state that has to survive until tomorrow.
4. Real-device clouds
Device clouds keep racks of physical phones and stream them to your browser. You get the real thing: vendor firmware and skin, camera, GPU and battery. It is the closest you can get to a phone in your hand without owning it.
The trade-offs come from sharing hardware. Sessions are time-limited, the phone is usually wiped when you leave, popular models can be busy, and the price reflects the cost of keeping physical devices alive. Android Studio's Device Streaming follows the same model but streams physical phones into the IDE instead of a browser, which is often what a developer searching for a browser emulator actually wants.
5. Cloud phones
A cloud phone is Android running in a data center as a specific phone model, kept for you like a device. You open its screen in the browser, control it with mouse and keyboard, and come back to it later: apps, logins and data stay until you reset it.
Clousd works this way: phones built from 150+ real models on Android 12 to 17, ready in about a minute, with a REST API, an MCP server for AI agents and ADB through a relay alongside the browser screen. The limits are the ones every virtualized phone shares: no real camera or sensors, and graphics performance that does not represent the physical device. The model list shows what is available.
The five side by side
| Tab emulation | Self-hosted, streamed | Hosted emulator streaming | Real-device cloud | Cloud phone | |
|---|---|---|---|---|---|
| What runs | an emulator inside the tab | Android Emulator or Cuttlefish on your server | Android Emulator on theirs | physical phones | Android on servers, set up as a phone model |
| Current Android | no | yes | yes | yes | yes |
| Device presented | not applicable | generic | generic | the real phone | the chosen model |
| Setup | none | Linux host with KVM | none | none | none |
| State between sessions | no | if you keep it | usually not | usually wiped | kept |
| ADB | no | yes | depends | usually | usually, through a relay |
| Best for | curiosity | in-house fleets | demos and previews | hardware-specific testing | testing, long-lived phones, agents |
For a deeper look at how an emulator on a server differs from a phone built from a real model, see the cloud Android emulator explainer.
What to check before you choose
- Latency. Every tap travels to the server and the new frame travels back. Distance matters more than bandwidth: a server on another continent adds a delay you feel on every swipe. Clousd's servers are in the EU, in Frankfurt and Helsinki, so the shortest round trips are from Europe.
- Input. Try typing with your keyboard, pasting from your clipboard, a pinch gesture and the back action. Browser sessions differ most here.
- Google Play. Emulator images come with or without Play; physical devices have it; cloud phones vary by provider. If your test needs Play services, check before you start.
- Logs. A browser-only session shows you a crash but not why. Make sure you can reach logcat, ideally with ADB. The ADB docs show what that looks like with a relay.
- Where your build goes. Uploading an APK to a service you cannot identify hands your code to a stranger. Never upload a build with production keys inside.
Which one for which job
- Show an app to a client or a reviewer: hosted emulator streaming, or a cloud phone if they need to come back to it.
- Test layouts on the phones your users own: a cloud phone or a real-device cloud.
- Camera, sensors, performance: a real-device cloud or a phone on your desk.
- Emulators inside your own network: self-hosted Cuttlefish or the emulator container.
- A phone kept for weeks, or one for an AI agent: a cloud phone.
- Debug the app you are writing: none of the above. Use the emulator in Android Studio on your own machine.
If you are about to run a first test session, testing an Android app online walks through install, logs and a repeatable smoke pass.
The free options
Tab emulation is free and does not run current Android. Self-hosted streaming is free software on hardware you pay for and look after. Real-device clouds and hosted emulator services offer limited free tiers or trials. Cloud phones usually offer a trial as well; the free cloud phone trial gives you 30 minutes with no card. For the shortest route from a link to a running app, see Android emulator online.
