Android Studio Rabbit 2 Hosts 40+ Coding Agents Now: What Actually Changes on Monday

On October 28, 2026, the day of Android Dev Summit, Google moved Android Studio Rabbit 2 (2026.2.2) to the stable channel. The headline is not a new model. It is that the IDE stopped insisting on Google's own assistant: Bring Your Own Agent is stable, and more than 40 coding agents that speak the open Agent Client Protocol — Claude Agent, Codex, Junie and Antigravity among the ones Google names — can be installed from inside the IDE and handed the project. That last part is the interesting bit and the risky bit. An agent with a chat window writes code. An agent with the emulator, the build system and Logcat can find out whether the code works, and that is exactly the loop you used to own.

A laptop showing an IDE with a code review in progress

1. What Actually Shipped

Rabbit 2 includes Bring Your Own Agent, new XR Emulator features, a LeakCanary update, an agent skills manager, and AI Change Review. The mechanics: open the agent window and pick an agent, or go to Settings > Tools > AI > Agents, authenticate with your own subscription or enterprise plan, and start prompting. Connected agents get the IDE's knowledge of project structure and build, symbol resolution, Compose Preview rendering, the Emulator, and Logcat, and they can load Android skills to handle multi-step Android work. Skills are managed from the Agent panel's three-dot menu under Manage Agent Skills, by typing @ in the chat box, or from Settings > Tools > AI > Skills Manager.

#!/usr/bin/env bash
# verify-agent-work.sh — run this on every branch an agent produced.
set -euo pipefail
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
echo "== verifying $BRANCH =="

# 1. It compiles in the variant you actually ship
./gradlew :app:assembleDebug --offline=false

# 2. Unit tests still pass (agents love editing production code only)
./gradlew :app:testDebugUnitTest

# 3. Android Lint has no new errors
./gradlew :app:lintDebug

# 4. Nothing was added that nobody reviewed
git diff --numstat "$(git merge-base HEAD origin/main)" | sort -k1 -nr

# 5. No debug leftovers
git diff "$(git merge-base HEAD origin/main)" | grep -nE '\+.*(Log\.d|println|printStackTrace)' && {
  echo "debug output found in diff"; exit 1; } || true

2. The Protocol Is the Story, Not the Agent Count

Forty agents sounds like marketing, and the number is less important than what it implies: one integration point instead of forty. The IDE is the client; each agent is a process on the other side of a standard protocol. That is why a team on an enterprise agreement for one vendor and a team standardised on another can use the same tooling and the same review flow. It also means the interesting decisions are now policy decisions rather than vendor decisions — which agents are allowed, what they can reach, and what a merge requires — and policy is the part most teams have not written down.

#!/usr/bin/env bash
# capture-context.sh — give the agent evidence, but bound the firehose.
set -euo pipefail

DEVICE="${1:-emulator-5554}"
OUT="agent-context/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"

# Last 400 lines only; full buffers are 10 MB and useless in a prompt
adb -s "$DEVICE" logcat -d -t 400 > "$OUT/logcat.txt"

# Quiet assertions the agent can act on
adb -s "$DEVICE" shell dumpsys meminfo > "$OUT/meminfo.txt"
adb -s "$DEVICE" shell dumpsys gfxinfo com.example.app > "$OUT/gfxinfo.txt"

# Record the exact build under test so a regression has a name
git rev-parse HEAD > "$OUT/git-sha.txt"
echo "context written to $OUT"

3. Give the Agent the Project, Not the Runbook

The fastest way to make a hosted agent useless in an Android repo is to let it rediscover your conventions every session. Put them in a file the agent reads, keep it short, and make it say what not to do. Ours covers the build (wrapper only, no inline versions), the module boundaries, Compose-only UI, tests in the same commit, and a short list of things that require a human: schema migrations, permission changes, minSdk bumps, signing config and CI. That last list matters more than the rest, because it is the boundary between 'agent speeds us up' and 'agent quietly widens the attack surface'.

# AGENTS.md — point every ACP agent at the same rules

## Build
- JDK 21, Gradle wrapper only. Never edit `gradle-wrapper.properties`.
- Always run with `--offline` first; if it fails, say so, do not "fix" by adding deps.

## Modules
- `:app` shell only. Feature code goes to `:feature:*`; shared code to `:core:*`.
- New dependency requires an entry in `gradle/libs.versions.toml`. No inline versions.

## UI
- Jetpack Compose only. Do not add XML layouts for new screens.
- Previews are required for new composables; give them sample data, not mocks.

## Tests
- Any behaviour change needs a test in the same commit.
- Robolectric for logic, instrumented tests only for device APIs.

## Stop and ask
- Schema migrations, permission changes, `minSdk` bumps, signing config, CI YAML.

4. Review Is the New Bottleneck, and Change Review Knows It

Google's own framing is telling: as agentic tools write code faster, reviewing and verifying it has become the constraint. AI Change Review works from three entry points — agent changes, pending commits, and the Git log — starts by producing Recommended Fixes, and then generates a guided walkthrough that groups related diff chunks into themes instead of forcing you through files alphabetically. That is a good default, and it is still an LLM summarising an LLM's work. The walkthrough tells you what to read; it does not tell you what the agent touched that it should not have. That is what the scripts below are for.

# diff-triage.py — rank an agent's changed files by risk before you read them
import subprocess, sys

BASE = subprocess.check_output(
    ["git", "merge-base", "HEAD", "origin/main"], text=True).strip()
numstat = subprocess.check_output(
    ["git", "diff", "--numstat", BASE, "--"], text=True).strip().splitlines()

RISK = [
    ("app/src/main/AndroidManifest.xml", 9, "permissions / exported components"),
    ("build.gradle", 6, "build config"),
    ("gradle/libs.versions.toml", 6, "dependency versions"),
    ("/res/xml/", 5, "network & backup rules"),
    ("/src/main/res/", 2, "resources"),
    ("/src/test/", 1, "tests"),
    ("/src/main/", 3, "production code"),
]

rows = []
for line in numstat:
    added, removed, path = line.split("\t")
    score = next((w for frag, w, _ in RISK if frag in path), 3)
    churn = (int(added) if added.isdigit() else 0) + (int(removed) if removed.isdigit() else 0)
    rows.append((score * 10 + min(churn // 20, 9), path, churn))

for s, path, churn in sorted(rows, reverse=True)[:15]:
    print(f"{s:3d}  {churn:5d} lines  {path}")
print("\nRead the top five before approving anything.", file=sys.stderr)

5. What the Agent Can See Is What You Must Bound

Once an agent can drive the emulator and read Logcat, your device data is in its context. Two rules have kept this sane for us. First, agents get an emulator or a dedicated test device, never a phone with a signed-in account, and never a keystore that can sign a release. Second, never hand an agent an unbounded log: 400 lines with a timestamp, a git SHA and the exact build under test will do more than a 10 MB dump, and it costs a fraction of the tokens. The capture script below writes that bundle to disk so a regression can be reproduced by a human later.

# Makefile — one target the whole team can shout at an agent
.PHONY: agent-check
agent-check:
	@./scripts/verify-agent-work.sh
	@git diff --check
	@echo "--- changed files ---"
	@python3 scripts/diff-triage.py
	@echo
	@echo "Approval requires: build green, unit tests green, no new lint errors,"
	@echo "no new dependency without a catalogue entry, and a manual read of the top five files."

# Rules that keep the IDE honest:
# - agents get a device, not a signed production keystore
# - agents get a branch, never main
# - no agent output is merged on a green pipeline alone

6. A Reasonable First Week

Day one: install one agent, connect it to a throwaway branch, and have it do something you already know the answer to — a Compose preview, a Robolectric test, a LeakCanary fix in the Profiler. Day two: write the AGENTS.md boundary list and add the three prohibitions. Day three: put verify-agent-work.sh behind a make target and make it the required check. Day four: run diff-triage.py on the agent's changes and compare your read against the walkthrough. By Friday you will know two things that no demo tells you — whether the agent's output survives your CI, and how much of your week went into reviewing it. The second number is the one to watch, because it is the one that decides whether this was worth turning on.