ReDroid vs an emulator.
SpawnDroid runs Android as a container on ARM64 servers. ReDroid is the container runtime underneath; there is no QEMU device model and no hypervisor in the path. Here is what that changes, and what it does not.
At a glance
- Runtime
- Android as a container (ReDroid) on ARM64 server hardware
- Native libraries
- Your APK links against real arm64-v8a libraries
- Device model
- No QEMU device model and no hypervisor in the path
- Profiles
- Android 12 to 16, phone or tablet; Android 14 phone default
- Same session
- A browser stream and a hosted Appium endpoint at once
How it compares
| Feature | Typical emulator | SpawnDroid |
|---|---|---|
| What runs Android | A software device model plus a translation layer | Android userspace in a container on ARM64 |
| CPU instruction set | Depends on the image; often x86 on a desktop host | ARM64, the same instruction set a modern phone uses |
| Hypervisor | Usually required for hardware acceleration | None in the path |
| Native arm64 apps | Needs a matching image or translation | Runs arm64-v8a natively |
| Where it runs | Your laptop or a cloud VM | SpawnDroid's ARM64 servers, streamed to the browser |
Emulator behaviour depends on the image and host. This table is deliberately general; check your emulator or device cloud’s current documentation before deciding.
What an emulator does
An emulator models a device in software. Your app runs against that model, which is useful when you need an exact OS image, an x86 ABI, or dozens of API levels at once. The trade is a translation layer between the app and the hardware: behaviour can differ from a phone, especially for native libraries, performance and framework timing.
What a container does
SpawnDroid runs Android as a container on ARM64 server hardware. The Android userspace boots in the container and shares the host kernel through binder, the interface Android exposes on a device. There is no device model to translate through, and no hypervisor to boot.
ReDroid is the open-source Android container runtime underneath. SpawnDroid runs ReDroid with its own device profiles, branding and orchestration, and exposes the running session as a browser stream and a hosted Appium endpoint.
Why ARM64 matters
Modern Android phones are ARM64. When an APK contains arm64-v8a native libraries, those libraries run natively here rather than through an x86 translation layer. That is the difference that makes native crashes, ABIs and framework behaviour trustworthy for teams shipping native code.
What ReDroid does not give you
- It is not a physical handset. There is no handset body and no radio.
- It is not a full device matrix. SpawnDroid offers Android 12 to 16 on a phone or tablet screen.
- It is not iOS. SpawnDroid runs Android only.
- GPS is a test provider, not a radio fix. Mock location is flagged as mock, and apps that reject mock locations will ignore it.
When an emulator is still the right tool
If you need the exact OS image, an x86 ABI, or dozens of API levels at once, a local emulator or a device farm may fit better. SpawnDroid is built for running and testing a build on real Android, not for emulating every device in a lab.
How to try it
- Upload a universal APKBuilds up to 512 MB are supported. An .aab is converted to a universal APK on the device host; split APKs are not supported.
- Start an Android sessionPick Android 12 to 16 on a phone or tablet. Android 14 on a phone is the default profile.
- Drive it or automate itUse the browser stream by hand, or point an Appium/W3C WebDriver client at the same session.
Frequently asked questions
No. SpawnDroid runs Android as a container on ARM64 server hardware. There is no QEMU device model and no hypervisor in the path.
Keep reading
Start free
Run your APK on native ARM64.
Upload a build and open a real Android session. The Hobby plan includes one parallel runner and 200 device-minutes a month, and needs no card.