How to give Claude Code an Android phone: ADB, an emulator, or a cloud phone

#ai #android #mcp #claude

Disclosure: I work on Phonebox, one of the options below. The other three are free, and I've tried to be fair about when each is the better fit.

You can give Claude Code an Android phone four ways: a USB phone it drives with ADB, the same phone mirrored with scrcpy, a local emulator, or a cloud phone through a hosted MCP server. ADB is free if the phone is on your desk. A cloud phone is one command, works from any machine, and gives Claude Code the screen as text, so it taps by label instead of by coordinates.

The four options

	Needs	Claude Code sees	Works in CI / sandboxes	Cost
USB phone + ADB	A phone, a cable, USB debugging, platform-tools	Screenshots and UI dumps it parses itself	No	Free
ADB + scrcpy	The same, plus scrcpy	The same; scrcpy is for you to watch	No	Free
Local emulator	Android Studio, a system image, hardware acceleration	Screenshots and UI dumps through adb	Rarely (needs nested virtualization)	Free; uses your RAM and CPU
Cloud phone over MCP	One command and an API key	A numbered list of on-screen elements, plus a screenshot	Yes	Paid per minute

Option 1: a USB phone and ADB

Turn on developer options. Settings > About phone, tap Build number seven times, then turn on USB debugging.
Install platform-tools, plug the phone in, accept the prompt, and check that adb devices lists it.
Tell Claude Code to use adb. It can run adb install, adb shell input tap x y, adb shell input text and adb exec-out screencap -p in its terminal.

It works, and it's free. The limits show up quickly: Claude Code has to work out tap coordinates from screenshots, the phone has to stay plugged into the machine Claude Code runs on, and a dropped connection or a locked screen stops the run. ADB-based MCP servers wrap the same commands in tools, with the same requirement of a device next to the agent.

Option 2: add scrcpy to watch

scrcpy mirrors the phone to a window on your desktop and lets you control it with your mouse. It doesn't give Claude Code anything new, since the agent still acts through adb, but it's useful for watching the agent and stepping in.

Option 3: a local emulator

An emulator from Android Studio avoids the cable and can be reset. It needs gigabytes of SDK and system images and hardware acceleration, and it competes with your IDE for memory. Most CI runners and cloud sandboxes can't run it, because they don't offer nested virtualization.

Option 4: a cloud phone through MCP

A hosted Android MCP server runs the phone in the cloud. With Phonebox it's one command:

claude mcp add --transport http phonebox https://phonebox.dev/mcp \
  --header "Authorization: Bearer $PHONEBOX_API_KEY"

Claude Code then gets 13 tools: observe returns the screen as numbered elements with their labels, act taps and types by label, install_app installs the APK it just built, live_view_url hands the phone to you for a one-time code, and park_phone stops billing while keeping the apps and sign-ins. This is what the agent reads:

snapshot snp_4f2k7m3q6z3a
app com.android.launcher3
keyboard hidden
screen 1080x2400
[1] EditText "Search apps" #search clickable editable (540,250)
[2] TextView "Chrome" #icon clickable (200,1900)
[3] TextView "Settings" #icon clickable (500,1900)

It costs $0.06 per phone-minute while running and nothing while parked. There's a 56-second demo and a 3-minute setup video.

Which to choose

USB and ADB if a spare phone sits on your desk and Claude Code runs on that machine.
A local emulator for repeatable tests on a workstation that can run one well.
A cloud phone when Claude Code runs remotely, in CI or in a sandbox, when the phone has to stay signed in between sessions, or when you'd rather not set anything up.

The full comparison, kept up to date, is at phonebox.dev/guides/how-to-give-claude-code-an-android-phone.

DEV Community