Translated from the original Japanese article
Tech 7 min read

Google Ships Android CLI v0.7 Preview with android create and skills for Agents

Android CLI AI Agents Google Gemini Claude Code Codex
IkesanContents

Working on Android apps through Flutter, most of the Android toolchain hides behind flutter build apk.
The parts that still stop me cold are sdkmanager updates and Gradle syncs in Android Studio, and I’ve been curious whether those could be handed off to an agent.
Google dropped Android CLI v0.7 in preview on April 16, 2026, so this is a spec rundown based on the Android Developers Blog and the release notes. I haven’t tried it myself yet.

What Android CLI Is

Android CLI is the official command-line interface for Android development from the terminal.
Google positions it as “the primary interface for Android development,” sitting alongside the Android Studio workflow as a thin layer agents can drive.

The initial version is v0.7 (preview), downloaded from d.android.com/tools/agents.
Google’s messaging is consistent: not just Gemini in Android Studio / Gemini CLI / Antigravity, but Claude Code, Codex, and third-party agents should all hit the same CLI.

It’s not a wrapper tied to Google’s own agents. It’s aimed at being a shared base that returns the same structured output no matter which agent calls it.

Main Commands

Based on the official blog and ByteIota’s breakdown, the initial release covers these commands.

  • android sdk install — install platform-tools, build-tools, platforms individually
  • android create — scaffold a new project from official templates
  • android emulator — create and manage virtual devices
  • android run — build and deploy to a device or emulator
  • android skills — list and apply Android Skills (see below)
  • android docs — query the Android Knowledge Base
  • android update — update the CLI and its components

The documentation shows examples like these.

android sdk install --packages "platform-tools,build-tools;35.0.0,platforms;android-35"
android create \
  --name BookManager \
  --template compose-empty \
  --package com.example.books
android skills implement-edge-to-edge

The mess of shell scripts and sdkmanager invocations gets consolidated into a single android command dispatching to subcommands.

Android Skills (SKILL.md-Format Instructions)

Android Skills are SKILL.md-format markdown instructions written to be read by agents.
The structure mirrors Claude Code skills and OpenClaw-style skills, and they’re listable and runnable through android skills.

Skills available at launch include:

  • Configuration and migration to Navigation 3
  • Edge-to-edge UI support (extending content under status and navigation bars)
  • AGP 9 (Android Gradle Plugin 9) support and migration from XML layouts to Jetpack Compose
  • R8 (Android’s code shrinker and obfuscator) configuration analysis

When you tell an agent “make this project edge-to-edge,” it reads the Skill body and follows the steps.
Rather than having the LLM RAG its way through human-facing docs, feeding it the SKILL.md that Google explicitly wrote as “do this” produces less drift.

Android Knowledge Base (Inside android docs)

android docs is a query interface for what Google calls the Android Knowledge Base, pulling guidance and recommended patterns from sources like:

  • Android official documentation
  • Firebase
  • Google Developers (Google Developers Blog and related references)
  • Kotlin documentation

Ask the agent “what’s the recommended way to handle PendingIntent for notifications on Android 15?” and instead of dredging up a stale blog post, it only pulls from sources Google endorses as authoritative.

The Performance Claim and Where It Comes From

Google claims “70% or more token reduction and 3x speedup” from internal experiments.
ByteIota’s write-up gives a concrete example: a typical setup task going from ~400 tokens to ~120.

The mechanism is simple. A traditional agent walks through something like this:

flowchart TD
  A[User instruction] --> B[Agent fumbles through shell]
  B --> C[Parse sdkmanager output in natural language]
  C --> D[Parse Gradle output in natural language]
  D --> E[Retry on errors]
  E --> F[Build succeeds or fails]

The logs here are noisy, and all of it was getting fed to the LLM.
With Android CLI in the middle, the flow becomes:

flowchart TD
  A[User instruction] --> B[Agent calls android CLI]
  B --> C[CLI returns structured output]
  C --> D[Reference a Skill if needed]
  D --> E[Success or clear error code]

In short, a formatting layer keeps verbose stdout out of the agent’s context.
Hacker News pointed out that “3x speed is only for initial setup or formulaic tasks — the real day-to-day dev loop doesn’t get 3x faster.”

Agent Integration in Practice

At publication time, Google says support covers “Gemini CLI, Claude Code, Codex, and third-party agents.”
But the specifics — “here’s how to teach Claude Code about android CLI” or “here’s how to register it as an MCP server” — aren’t in the official docs yet.

Android CLI is just a local command, so agents can invoke it through normal subprocess calls and things work.
Feed the LLM the README and android --help and it’ll start calling it reasonably.
Whether this gets standardized as an MCP server shape is up to future versions.

Day-One Concerns

Reading through the Hacker News thread, these concerns show up early.

  • Windows install failures
    404s on download, socket errors on install, failed manual downloads. Android tooling’s tradition of being shaky on Windows continues.
  • Telemetry and data collection pushback
    No environment variable to opt out of Google’s metrics collection. What’s being sent requires reading the privacy notice at d.android.com/tools/agents.
  • Skepticism about “3x”
    As above, only setup time shrinks. The actual dev loop (build waits, emulator waits, Gradle sync waits) is unchanged.

Separately, Flutter developers have structural skepticism: “the underlying Android developer experience can’t be fixed by a CLI,” and “Android Studio is still unstable, but they shipped agent support first.” The sense that Google has prioritized AI integration over the basics of Android development for years now tracks.

A World Where SaaS + App CLIs Are Enough

Line up the last few months and the agent-callable layers are starting to close in from both sides.

From the Flutter seat, the shape of app development starts to look like: build the backend in Supabase and let Claude drive it, then build the app in Flutter (or native) and push it through the iOS/Android CLIs — with no IDE in the loop.
Less time fighting Android Studio bugs, more time letting the agent hit CLIs and return results.

That said, the parts CLIs can’t hide — Gradle syncs getting stuck, certificate dances in Xcode — don’t go away.
If Skills and Knowledge Bases grow enough to cover that, shipping apps without ever opening an IDE might be closer than it feels.

References:

  • Android Developers Blog: Build Android apps 3x faster using any agent — https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html
  • Release notes for the Android CLI (v0.7, 2026-04-16) — https://developer.android.com/tools/agents/android-cli/release-notes
  • ByteIota: Android CLI 70% Faster Agent Development (April 2026) — https://byteiota.com/android-cli-70-faster-agent-development-april-2026/
  • Hacker News discussion — https://news.ycombinator.com/item?id=47797665