Google's Open-Source Android Automation Agent

Google's ARTEMIS turns plain-English instructions into reliable Android automation — driving real phones and plugging into Claude Code and Cursor via MCP.

Google just open-sourced something worth your attention: an agent that takes a sentence like "Open Settings, find Battery, and tell me the current level" and actually does it on a real Android phone.

It's called ARTEMIS — you can grab it at github.com/google/artemis — it's Apache 2.0 licensed, and on Google Research's AndroidWorld benchmark (100+ multi-step tasks across 20+ apps) it reports a 99%+ completion rate.

Android automation has always meant picking your poison. UiAutomator and Appium are precise but brittle — your test shatters the moment a designer moves a button. Pure computer vision is flexible but slow and unreliable.

ARTEMIS does both. It reads element indices from the accessibility tree when they exist, and falls back to coordinates and vision models when they don't — Canvas charts, Flutter surfaces, custom Compose layouts. Not either/or. Structure first, vision as backup.

That single design choice is why it holds up on apps that were never built to be testable.

Two modes: Flash and Pro

Flash is the fast path. One model observes the screen, thinks, and acts — roughly 3–5 seconds per step, token-efficient, no planning overhead. Great for smoke tests and quick "go check this screen" jobs. The tradeoff: no task plan, no safety checks, no final report.

Pro is the careful path. A Planner writes a living Markdown plan with milestones. An Operator executes it with the full toolset. Every single action passes a Safety Net before firing. A read-only Checker verifies checkpoints and reviews the result against your original goal. Cost: 15–40 seconds per step.

Use Flash to check something. Use Pro to prove something.

Also nice: when an action fails in Pro, it opens an "incident" that stays in the Operator's context until a later action succeeds. Recovery is handled by the agent that already understands the situation — not punted to a separate repair agent that has to relearn everything.

The feature that'll actually get it adopted

ARTEMIS ships a native MCP server.

Translation: Claude Code, Cursor, Codex, Windsurf, VS Code, and Antigravity can drive a real device from inside your editor chat — and read back Logcat output and screenshots.

One prompt in your IDE can build the APK, install it, walk the login flow with a test account, watch for unexpected popups, and hand you screenshots of the final screen. That's not a unit test. That's end-to-end verification, triggered conversationally, on the phone already plugged into your machine.

One thing people miss: Google ships a rules file (mcp_server/rules.md) with a "mobile testing mindset." Mount it into your IDE's rules. Without it, you're asking a general-purpose assistant to reason about mobile testing with zero domain grounding — and it will confidently hallucinate UI interactions.

Try it in ten minutes

You need an Android device with USB debugging on, or an emulator. That's it. Clone the repo from github.com/google/artemis and run:

bashCopy

git clone https://github.com/google/artemis.git && cd artemis
./start.sh

(Windows: use .\start.bat — PowerShell needs the .\.)

The script auto-installs the toolchain — ADB, scrcpy, FFmpeg, uv — then opens a web console at localhost:8000 with live screen mirroring, a prompt sandbox, and execution replays.

Or skip straight to the CLI:

bashCopy

uv run artemis run "Open Settings, find Battery and tell me current level" --profile flash

There's also a Python SDK for CI pipelines with typed Pydantic outputs, and the client is thin — the models and image processing stay on the device host, so your CI runner just needs network access.

The honest caveats

The 99% figure is self-reported — Google's own repo, Google's own benchmark, Google's own system. It's a strong signal, but AndroidWorld tasks are clean and verifiable in a way your production app's janky onboarding flow is not.

The repo is young, too: roughly 4.1k stars and 119 commits, well short of Appium's maturity. Pro at 15–40s/step across a long workflow is a coffee break, not a CI gate. And there's no iOS support — it's on the roadmap, not in the code.