If you've ever asked a coding agent to build an Android app, you know the failure mode: it burns thousands of tokens screen-scraping menus, guessing at Gradle output, and choking on Android Studio's GUI, which was never designed for a machine to drive. At Google I/O '26 in May, Google shipped its fix. Android CLI reached stable 1.0 — a scriptable interface that hands the entire Android toolchain to any agent through the terminal.

What it actually is#

Android CLI is a lightweight command-line layer over the tools that used to live inside Android Studio's GUI. Per Google's command reference, an agent can now create projects (create), install SDK components (sdk install), spin up and drive emulators (emulator create/start), deploy an app (run), capture the screen (screen capture), inspect the live UI layout as JSON (layout), and query current docs (docs search) — all from the shell, without a human opening the IDE.

It's agent-agnostic. Google names support for Gemini in Android Studio, Google Antigravity, Anthropic's Claude Code, and OpenAI's Codex — anything that can run a shell command. (Undecided on which of those to drive? Our Claude Code vs. Codex CLI vs. Gemini CLI breakdown covers the trade-offs.)

Who it's for#

If you're a solo founder trying to get a mobile app from idea to installable APK with an agent rather than a mobile team, this is aimed squarely at you. Google's own framing is a workflow, not a replacement: prototype quickly with an agent through Android CLI, then open the project in Android Studio to fine-tune the UI, debug, and profile. The CLI is the fast front door; the IDE is where you polish.

The cost win, and why it matters#

Here's the number that should get a founder's attention. In Google's internal experiments, Android CLI cut LLM token usage by more than 70% on project and environment setup, and completed tasks 3x faster than an agent using the standard toolsets.

Fewer tokens is not a nice-to-have. It is the difference between an agent that finishes your build loop and one that stalls out mid-context.

The mechanism is the interesting part. A raw toolchain firehoses an agent with full build logs, entire file dumps, and verbose SDK-manager chatter — most of which the model has to read, pay for, and reason around. Android CLI's machine-friendly interface, as InfoQ describes it, returns compact, structured results instead. The savings aren't really "CLI vs. GUI" — they're compressed, machine-readable answers vs. raw text you're paying to parse.

How to get started#

Installation is a single curl command for your OS, run in your terminal; after it lands, you initialize it so your agent knows how to use it:

# 1. install via the curl command for your OS (see the download page)
# 2. teach your agent the tool by installing the android-cli skill
android init

# check you're set up, then list what you can do
android --version
android skills list

Once initialized, the deep semantic commands live under android studio. These are the ones that replace clicking around the IDE:

# find where a symbol is defined
android studio find-declaration HotelDetailScreen

# lint a single file with the IDE's own inspections
android studio analyze-file app/src/main/java/com/example/MainActivity.kt

# render a Compose preview to an image
android studio render-compose-preview --output-image-file=preview.png \
  app/src/main/java/DetailScreen.kt HotelDetailScreenPreview

Every command above is drawn from Google's official reference at developer.android.com/tools/agents/android-cli.

Where Android Skills fit#

Alongside the CLI, Google ships Android Skills — modular, markdown-based SKILL.md files, each a technical spec for one task. It's the same portable agent-skills standard spreading across tools, now pointed at the Android toolchain. They trigger when your prompt matches a skill's metadata, so the agent pulls in Google's canonical approach instead of hallucinating one. You browse and add them with android skills find and android skills add. Backing all of it is a live Android Knowledge Base, reachable via android docs search and docs fetch, so the agent isn't relying on a stale training cutoff.

The honest trade-off#

"Without opening the IDE" deserves an asterisk. The powerful android studio subcommands — symbol resolution, Compose rendering, IDE-grade lint — don't run headless. They proxy into a running instance of Android Studio (Quail 2 Canary 1 or higher, with Gemini in Android Studio enabled and signed in); android studio check exists precisely to verify that connection. So you're not eliminating Android Studio for those features. You're demoting it to a background daemon your agent talks to, while you stay in the terminal. The core pieces — project creation, builds, emulators, SDK installs, deployment — stand alone; the deepest semantic features still need Studio breathing behind them.

That's a fair deal — but budget for the install, the disk, and a machine that can keep Studio resident.

What it means for you#

If shipping a mobile app has been blocked by "I don't want to learn Android Studio," that excuse just got weaker and cheaper. Install the CLI, run android init, point Claude Code or Codex at it, and let the agent drive — at roughly a third of the token cost you'd have paid a month ago. Prototype in the terminal, then open Studio only when you need human eyes on the UI. Just don't expect fully headless: the deepest features still ride on a live IDE.