Skip to content
Start with Hobby

Android test
infrastructure,
without the device
rack.

Run Appium and WebDriver suites on containerised Android 12–16. Manual sessions and hosted CI runners, without a device rack.

NewHosted Appium 3 runners
/Runs/Ember
EM

Ember

Ready

com.ember.coffee · v1.8.0 (140) · targets API 35 · 12.5 MB

Live·Pixel 8·00:38
9:41
Ember

Good afternoon, Alex

Ready when you are.

Featured today

Ethiopia Guji

Bright · floral · honey

€4.20 / cup

Pickup at Ember · 4 minChange

Today's menu

LogcatScoped to this applive buffer
10:00:00.120IActivityTaskManagerDisplayed com.ember.coffee/.MainActivity: +120ms
10:00:00.200EGraphicBufferAllocatorFailed to allocate (4 x 4) GPU memory
10:00:00.420EGraphicBufferAllocatorFailed to allocate (4 x 4) GPU memory
10:00:01.000IActivityManagerStart proc 4321:com.ember.coffee/u0a123
10:00:01.002DUiAutomator2session created · 38s to ready
10:00:01.004ITestRunnerember_menu_flow started
10:00:02.100WSurfaceFlingerCancelling draw of layer 42
10:00:02.118IActivityManagerSTART u0 {cmp=com.ember.coffee/.MenuActivity}
10:00:02.244DUiAutomator2session ready · emulator-5554 · arm64
10:00:03.019IOkHttpGET /v1/menu → 200 (61ms)
10:00:03.442WStrictModepolicy violation · disk write on main thread
10:00:04.007ITestRunnerember_menu_flow ✓
10:00:04.310DSessionartifact upload queued
10:00:04.512IInputDispatchertap (312, 884)
10:00:04.889DUiAutomator2findElement(By.id("featured-add"))
10:00:05.102IOkHttpPOST /v1/cart → 200 (84ms)
10:00:05.740DScreenshotruns/1842.png saved
10:00:06.015ISessionkeepalive 24ms · arm64-v8a
18 / 18 linesstreamed from adb logcat

Runs your Android stack

  • Native Android
  • Jetpack Compose
  • Kotlin Multiplatform
  • Flutter
  • React Native
  • Unity

From upload to result, on one device.

Upload a build and SpawnDroid does the rest: boot, install, and a runner that serves the browser stream and a hosted Appium endpoint at once.

  • No device to plug in, and no emulator to keep alive
  • The same device for people in the browser and tests in CI
  • Logcat and a screen recording retained for every run
sess_4f2aAppium endpoint ready

  1. Upload APK

    console or CI

  2. Device boots

    Android 14 · arm64

  3. Build installed

    not auto launched

  4. Runner ready

    browser stream + Appium URL

  5. Logcat streaming

    live from the device

Logcatlive
14:02:12.204 OkHttp GET /cart → 200 (84ms)
14:02:12.771 CheckoutApp render cart · 3 items

Everything you need to run the app, by hand or in CI.

One platform for the two jobs teams actually have: driving a build yourself, and letting your test suite drive it in a pipeline.

Real Android, not an emulator

Each session boots Android as a container on ARM64 hardware, so your APK links against real arm64-v8a libraries and runs against the same kernel interfaces a phone uses.

  • Android 12 to 16, phone or tablet
  • No QEMU device model, no hypervisor
  • Ready in well under a minute
new session · device profile
Android 16phone · API 36
Android 14phone · API 34selected
Android 12tablet · API 31

Hosted Appium runners for CI

Every CI session is an Appium 3 server with the UiAutomator2 driver and your build already installed. Point your existing WebDriver tests at the session URL. There is no SDK to vendor.

  • WebdriverIO, Selenium or any Appium client
  • Token gated WebDriver URL per run
  • Pass or fail reported straight back to the pipeline
ci · start an Appium runner
curl -X POST "$SPAWNDROID_URL/api/v1/sessions" \
  -H "Authorization: Bearer $SPAWNDROID_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "artifactId": "my-app" }'

# → { "webdriverUrl": "…/ci/sess_7f2c/wd/hub",
#     "device": { "apiLevel": 34 },
#     "app": { "package": "com.acme.checkout" } }

See what the app is actually doing

Stream Logcat beside the screen while you drive the app by hand, and keep the final logcat plus a screen recording from every CI run. Sessions are isolated and destroyed when they end.

  • Live Logcat with level filters and search
  • Retained logcat and recording per run
  • Nothing carried between sessions or workspaces
test logs · sess_4f2a · passed
LogcatRecordingCapabilities
14:02:11.482 ActivityManager Start proc com.acme.checkout
14:02:12.204 OkHttp GET /cart -> 200 (84ms)
14:02:12.771 CheckoutApp render cart · 3 items
14:02:13.006 Choreographer Skipped 4 frames
Read the quickstart
Integration

Wire it into your pipeline.

Upload the build, start a hosted Appium runner, and point your existing WebDriver tests at it. Pick your client below; the only changes are the WebDriver URL and capabilities.

CheckoutTest.java
import io.appium.java_client.android.AndroidDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import java.net.URL;

// Values from POST /api/v1/sessions
String webdriverUrl = "https://stream.spawndroid.io/ci/sess_.../wd/hub";
String deviceSerial = "emulator-5554";
String appPackage = "com.acme.checkout";

DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("platformName", "Android");
caps.setCapability("appium:automationName", "UiAutomator2");
caps.setCapability("appium:udid", deviceSerial);
caps.setCapability("appium:appPackage", appPackage);
caps.setCapability("appium:autoGrantPermissions", true);
// The build is already installed — do not set appium:app.

AndroidDriver driver = new AndroidDriver(new URL(webdriverUrl), caps);
driver.quit();

The build is already installed on the session device, so the capabilities never set appium:app. The endpoint is a standard W3C WebDriver URL, so WebdriverIO, Selenium and any Appium client work unchanged. See all integrations.

Compare

How teams run Android builds today.

Emulators, device farms and self-hosted racks each solve part of it. SpawnDroid is real Android in a container you can drive by hand or hand straight to Appium.

Local emulator

one per engineer

No emulator
No
Native arm64
No
Hosted Appium
No
No SDK to adopt
Yes
Device farm

Sauce Labs, BrowserStack

No emulator
Yes
Native arm64
Yes
Hosted Appium
Yes
No SDK to adopt
Partial
Self-hosted devices

a rack you maintain

No emulator
Yes
Native arm64
Yes
Hosted Appium
Partial
No SDK to adopt
Yes
SpawnDroid

containerised Android, on demand

SpawnDroid
No emulator
Yes
Native arm64
Yes
Hosted Appium
Yes
No SDK to adopt
Yes

“Partial” means it can be done, but only with a device to manage, a queue to wait in, or a framework to wire up first.

See the full comparisonLooking for an Appetize alternative?
Pricing

Start with Hobby. Scale when your team does.

Hobby is free forever with 200 device-minutes a month. Personal adds a second runner for side-by-side testing, 1,000 minutes and 60-minute sessions; Team adds five runners, five seats, 3,600 minutes and unlimited session length. Enterprise is contracted capacity with an SLA.

Hobby
Free forever
For your first build and your next side project.
$0/ mo

Free forever · no card

Included1 runner · 1 seat · 200 device-minutes
  • 1 parallel runner
  • 200 device-minutes / month
  • 15-minute sessions · 3-minute idle stop
  • 1 seat · 7-day history
  • 2 GB build storage
  • 1 share link (24h) · live Logcat
  • Community support
Start with Hobby
Personal
Cancel anytime
For solo developers, freelancers and demo-heavy work.
$190/ yr

Billed yearly · save $38

Included2 runners · 1 seat · 1,000 device-minutes
  • 2 parallel runners
  • 1,000 device-minutes / month
  • 60-minute sessions · 10-minute idle stop
  • 1 seat · 30-day history
  • 25 GB build storage
  • 5 share links · logcat and video downloads
  • Email support
Start Personal
Team
Recommended for teams
For a mobile team running a suite on every pull request.
$990/ yr

Billed yearly · save $198

Included5 runners · 5 seats · 3,600 device-minutes
  • 5 parallel runners
  • 3,600 device-minutes / month
  • Unlimited session length · 15-minute idle stop
  • 5 seats · 90-day history
  • 100 GB build storage
  • Unlimited share links and API keys
  • Crash reports, webhooks and priority support
Start Team
Enterprise
Sales-assisted
For regulated teams needing contracted capacity.
Custom

Annual contract · Talk to sales

Included25+ runners · unlimited seats · contracted minutes
  • 25+ parallel runners
  • Unlimited seats
  • Contracted device-minutes
  • Dedicated / isolated capacity
  • Security review and DPA
  • Named support
  • Annual contract
Talk to sales

What a 10-minute run costs

A run that holds a device for 10 minutes uses 10 device-minutes. Billing starts when the device is ready, not while it boots.

Hobby
20 runs
200 minutes, then a hard stop
Personal
100 runs
Then $0.15 per run, capped at $25/mo
Team
360 runs
Then $0.10 per run, capped at $250/mo

Prices in USD, excluding VAT · Overage is metered and capped · Cancel anytime

Trust

Where your build runs, and who can see it.

Real ARM64 servers, containerised Android and one device per session — all on infrastructure we operate. How the platform works.

ARM64 servers

Native arm64, with no hypervisor in the path.

Android 12–16

Containerised, sharing the host kernel through binder.

One session, every client

A browser stream and a hosted Appium endpoint at once.

One device per sessionEvery run gets its own isolated Android container, and it is destroyed when the session ends. Nothing carries between sessions or workspaces.
Workspace-scoped accessApps, runs and API keys belong to your workspace, and every console and API request is authenticated per workspace. A member only ever sees the workspaces they are invited to.
Scoped API keysA key carries a scope (upload, read or full), and only its hash is stored. Revoke one and pipelines using it stop immediately.
Bounded retentionBuilds, recordings and logcat are kept for your plan's retention window, then swept automatically. You can delete an app at any time.

Read the security page and the privacy notice for the full detail, or email engineering@spawndroid.io with a security question.

FAQ

Hard questions, straight answers.

If your question isn't here, talk directly to the engineers building SpawnDroid, not a sales bot.

Book a demoEmail engineering

Neither. SpawnDroid runs Android as a container on ARM64 server hardware — no QEMU device model, no hypervisor and no handset. Your APK links against real arm64-v8a native libraries and runs against the same kernel interfaces Android uses on a phone, which is what makes native crashes, ABIs and framework behaviour trustworthy. What you drive in the browser is the app actually running, not a simulation of it.

start with Hobby · no card required

Put your next build on real Android.

Upload an APK, then run it by hand or hand it to Appium in your pipeline. No device to plug in and no emulator to keep alive.

Start with HobbyRead the docs

One free parallel runner · 200 device-minutes a month · no card