An Android emulator in your browser, with a real phone's toolbar
Genuine Android on our machines, streamed to your tab. Install your APK, set location and timezone, read the device log, inspect the view hierarchy, capture evidence — and switch to a real phone the moment the question turns physical.
Same session rail as a real Android phone · switch to hardware in one click
Six Android versions to check, two phones in the drawer
A back-navigation bug on Android 13, a permission prompt that changed on 14, a layout that overflows at a larger font scale. You need to see them today, not after a phone ships to your desk. Open any of several Android versions in a tab and install your APK on it.
Everything a real Android session has
The emulator reports the same capability surface as a real Android phone. This is the rail you get.
Install and run your APK
Upload a build; it installs and launches the way it would on a phone.
Set a real location
Coordinates set at device level, so location-aware apps and pages see them.
Per-app language, device timezone
Set both from the rail; the page reloads as that user would see it.
Live device logs
Read the log stream as a crash or warning happens, not after.
Inspect native elements
Open an installed app's view hierarchy — ids, text, classes, bounds.
Capture and file it
Screenshot, record, or diff against your baseline, then file a bug with proof attached.
Network capture
Record the session's traffic as a HAR, the same control a real Android session gets.
Files and media in
Push a file into the device to exercise an upload or an import path.
Switch to a real phone
One click from the rail; the session and everything you captured come with you.
Iterate on the emulator, sign off on the phone
The emulator carries the fast, repeatable work: layout, app logic, permission flows, a version sweep before lunch. When a bug turns physical, switch device from the rail. The session stays in the tab, the gallery keeps every capture, and the bug you file carries both.
A test written against the emulator behaves the same way against the phone, because the agent reports the same Android surface for both.
Frequently asked questions
Yes. The emulator runs genuine Android, so an APK installs and launches as it would on a phone. Upload the build, install it from the session, and restart it from the rail whenever you need a clean start. Android App Bundles (.aab) are not accepted — upload a built APK.
The session reports the same capability surface as a real Android phone: location, per-app language, device timezone, device logs, restart app, the native element inspector for installed apps, network capture, and the full capture toolbar. The exceptions are physical: camera, sensors, radio and battery are synthetic or absent, and there is no VPN routing.
Several current Android releases, chosen from the same picker as real phones. The list is generated from what is actually running rather than typed into this page, so open the picker for the current set.
For layout, JavaScript, app logic, Chrome engine behaviour and most functional flows — yes, because the operating system and browser are real. For anything that depends on physical hardware — camera, sensors, radio, battery, gesture feel, performance — no, and this page says so plainly. The mistake is not using an emulator; it is asking it a question it cannot see.
Yes, at device level, so location-aware apps and pages see the coordinates rather than only the browser. Move a delivery app to another city, test a geofence, or check regional content without a phone.
A Pixel, largely — emulators run stock Android, which is what Pixels run. A Samsung, Xiaomi or other manufacturer device, no: their own software layer changes notifications, permission prompts, battery management and sometimes the default browser, and none of that exists on a stock image. Manufacturer-specific behaviour is the most common source of 'only on that phone' bugs, and it is a real-device question — switch to hardware from the rail when you hit one.
When the answer depends on something physical: camera and sensor behaviour, cellular radio, call and message interrupts, battery and thermal throttling, gesture and scroll feel, or load and frame-rate numbers, which describe the host rather than any phone your users hold. The last sign-off pass before a release should also run on hardware. Switch device from the rail and the session continues in the same tab.
Not fidelity — this runs the same kind of image. It is that this one is not on your laptop competing with your IDE for memory and GPU, is not yours alone, produces evidence anyone on the team can open, and sits one click from a real phone in the same tab.
Open an emulator now, and a phone next to it when you need one
The same picker, the same rail, the same evidence. Iterate virtually, confirm on hardware.