Crewdroid

crewdroid

An Android emulator your AI agent drives on under half the RAM of Android Studio's, with the phone's conditions set per device: network, battery, location, screen, font, Android version.

crewdroid is for the build-and-check loop while you develop an app; a real phone is still where you test push notifications, Play services, Google sign-in and the camera app (Limits).

• Faster to a tested app. In one run per side, an AI agent built and 3-device tested the same app in 13 min 42 s on crewdroid and 40 min 30 s on Android Studio's default AVD, with the same result (details).
• Light. 1472 MB of host RAM and 2.09 GiB of disk per device, against 3388 MB and 7.29 GiB for Android Studio's default AVD; a screen read through the CLI takes 370.7 ms against 2074.1 ms (table).
• Made for an agent. screen returns a text outline ([3] btn "Send" #send @540,1210) in about a third of a screenshot's tokens (1882 vs 6183 per task), tap --text Send taps by name on any screen size, and every command is both a CLI with --json and an MCP tool.
• Conditions on demand. Per device: net airplane|nodata|slow|flaky, env battery / location / dark mode / font size / locale / rotation, Galaxy S24 · Fold · Flip screens with fold / unfold, Android 12 / 14 / 16, a used-phone load.

Also in the box: judging your server's data for duplicate, missing and silently overwritten records after a multi-device run, a layout sweep across screens and fonts, crash / ANR triage.

One app, built by an agent on both

We gave an AI agent the same empty project, spec and buggy server twice: build a designated-driver app, check every feature on screen, fix what breaks, then test 3 drivers against the server. Same model, no human. One run per side, 2026-11-02 (method and limits, files to repeat it).

Same result, about a third of the time. Boot explains nearly half of the gap: without those 759 s the Studio side takes about 28 minutes, and an agent reusing a running emulator would not pay all of it. This is one run per side, not a benchmark.

The run command then took about 5 minutes for 3 devices x 5 rounds with network faults. It failed the buggy server 2 of 2 times and passed the fixed server 2 of 2 times.

One device, against Android Studio's default emulator

If you found crewdroid because an AI agent on the stock emulator is slow, start here. One device, medians of 3 runs, measured on the same PC (raw runs in docs/measurements/single-vs-studio.json):

Bold = crewdroid clearly ahead. Cold boot and snapshot boot are a tie, and idle CPU varies too much between runs to call. The CLI rows time the installed crewdroid command (node bin/crewdroid.mjs, a new node process per call; it starts in 79 ms, --version); the MCP rows time calls to one crewdroid mcp server kept running. npx crewdroid adds about 0.4 s to every call (cli-speed.json), so install it once (npm i -g crewdroid) or use the MCP server. Per-phase numbers in single-vs-studio.md.

An AI agent driving one device (Field Notes demo app, "add a note and confirm it", 5 runs per path, API 34, s24ultra; raw in docs/measurements/agent-bench.json): path A reads crewdroid's text outline and taps by text, path B reads a screenshot after every action and taps by x,y.

What crewdroid adds over mobile-mcp + the stock emulator: a lighter device (table above, single-vs-studio.json), per-device network faults (net), layout checks across screens and fonts (layout.md) and judging the server's data (run-app.json). What it does not add: tap / type speed, which is the same (agent-bench.json; mobile-mcp itself was not benchmarked, path B stands in for screenshot-driven agents).

Setup: Android 16 (API 36); the Studio side is a pixel_9 AVD from google_apis_playstore with default 2 GB RAM and 4 cores, window on, -gpu auto, quickboot; the crewdroid side is up with no flags (headless, 2 cores, google_atd image); Ryzen 7 5700X, 64 GB, Windows 11, emulator 37.1.11.0. The CLI rows include starting node.

What only crewdroid does

1. Judges the server, not the screen. After a run, crewdroid judge reads your API's data and checks rules: unique (no duplicates), count (nothing missing), noLostUpdate (no silent overwrite). A bug comes back as VIOLATION lines and exit code 1, not as a screenshot to interpret. No export endpoint? crewdroid proxy start --target http://127.0.0.1:8080 records every request the emulators send (through the Android system proxy, no app or server change), and crewdroid judge --rules judge/proxy.rules.json --log proxy.jsonl checks dupSuccess (one write applied twice), lostUpdate (two edits on the same version both accepted), lostWrite (a failed write never retried) and idle from that log. Plain HTTP only for now (ADR 0008).
2. Breaks one device at a time, mid-flow. Network airplane / nodata / slow / flaky per device on its own schedule, fold / unfold during an upload, Doze, trim-memory, full storage, a low-end CPU / RAM spec. Every setter reads the state back.
3. Runs a mixed fleet from one command. Android 12 / 14 / 16 and S24 · Fold · Flip or any WxH@dpi, headless, all clones of one base image: 3 devices in 3.93 GB of host RAM and 6.99 GiB of disk (allocated).

Also in the box: crash / ANR triage, cold start and jank, APK inspection. Every command has --json and an exit code, and every command is an MCP tool.

npx crewdroid setup --yes        # Android SDK + emulator images, if you have none

npx crewdroid up --count 3 # S24 Ultra / API 34, Fold5 / API 34, Flip7 / API 36 npx crewdroid run --apk app.apk --flow flows/add-item.yaml --server http://127.0.0.1:8080 # your app: your Maestro flow on every device + network faults + judge, exit 1 on a bug

New to it? Try the bundled sample first (sample app + sample server with a race condition): npx crewdroid run scenarios/photo-upload.json --seed 1. Your own app step by step: docs/guide-your-app.md.

Why not just the Android Emulator?

The stock emulator is one phone with a window, driven by hand. crewdroid is a *fleet* driven by a program.

Resources for 3 devices (3 API levels each; stock = avdmanager defaults, headless, fresh):

"Allocated" = bytes really on disk (sparse holes and NTFS compression excluded), the only disk number comparable to crewdroid's slimmed clones; the google_apis figure was taken as file length, so it overstates that column. Disk and RAM are lighter than both stock images, but idle CPU is not: crewdroid's ~600 % is higher than 3 stock google_atd AVDs (~248-352 % over 6 runs; one 60 s sample is noisy), so the CPU gap against google_apis comes from the image, not from crewdroid. Measured on one Windows 11 PC (Ryzen 7 5700X, 64 GB, WHPX), 3 devices. Raw JSON and method in docs/measurements/ (baseline.md, baseline-atd.md).

No barrier, by design. Real concurrency bugs come from retries, offline queues and late edits overlapping — not from pressing a button at the exact same millisecond. crewdroid gives each device its own delays and network schedule and lets the overlap happen, then reads the truth from the server (ADR 0002).

60-second tour

Boot a mixed fleet (headless, no emulator windows; on Windows a tray icon shows what runs):

$ crewdroid up --count 3 --json

[ { "serial": "emulator-5580", "profile": "s24ultra", "api": 34, "screen": "1080x2340@450", "bootSeconds": 6.4, "readySeconds": 42.1 }, { "serial": "emulator-5582", "profile": "fold5-main", "api": 34, "screen": "1812x2176@420", "bootSeconds": 6.7, "readySeconds": 41.8 }, { "serial": "emulator-5584", "profile": "flip7-main", "api": 36, "screen": "1080x2520@480", "bootSeconds": 3.1, "readySeconds": 39.9 } ]

Cut one device's data mid-upload, let another go flaky:

$ crewdroid net emulator-5580 nodata

$ crewdroid net emulator-5582 flaky

Run your own app (a release APK is fine): `r