跪拜 Guibai
← Back to the summary

Android Dev Summit 2026: IDE Agents, CLI Device Testing, and Built-in Performance Tooling

What's New in Android: Technical Analysis from Android Dev Summit 2026

Android Studio Officially Opens Up Agents, ACP Moves IDE Capabilities Along

This was actually discussed before. The most direct change is that Bring Your Own Agent (BYOA) entered stable in Rabbit 2. It was already in Canary in September, which we covered. Now Android Studio can connect to over 40 compatible Agents through the open Agent Client Protocol (ACP), and you can install several Agents and switch between them anytime. The entry point is at Settings > Tools > AI > Agents, where you can use your own subscription or API Key:

ACP can be simply understood as a universal communication interface between the IDE and programming Agents. Android Studio provides project structure, symbol resolution, build diagnostics, Logcat, Compose Preview, emulators, and other capabilities, which Agents can call during conversations.

ACP's position is different from MCP: ACP mainly solves how the editor connects to Agents, while MCP is more about how Agents connect to external tools.

Google has also put official Android Skills into the IDE manager. You can type @ to pick them, like agp-9-upgrade, android-profiler, r8-analyzer, camerax. Officially, there are over 30 Skills covering more than 20 types of Android development problems, focusing on areas where models don't know new APIs, performance, and security rules:

But who knows how long it's been since you opened Android Studio? The memory for Agents isn't even enough — wouldn't opening AS blow it up?

Additionally, Android Studio added support for who reviews the code after Agents make changes. Change Review can start from Agent Changes, pending Git Diffs, or even historical Commits. It supports finding potential issues first, then organizing related changes scattered across multiple files into a Walkthrough, letting developers review changes by feature relationship. Agents can also continue handling discovered issues:

Of course, that assumes you still review code.

Google's own Android Bench 2.0 has already taken tasks to long chains like migrating across files and creating Apps from design mockups. According to the October 29 leaderboard, Claude Sonnet 5.5 (max) with Claude Code only achieved a 40% pass rate across 30 tasks.

Another example is migrating XML Views to Compose. Now you can right-click XML and select AI > Migrate to Compose. The Agent first analyzes the layout, associated ViewBinding, and control logic, forms a migration plan, then executes step by step. Progress is saved across sessions, but this Migration Assistant is currently a Canary feature, and migration involves navigation, state, and coexistence with old Views:

Android CLI Brings Real Devices and UI Verification into the Terminal

Somewhat fragmented, Google also knows many people don't open the IDE much. So another line is Android CLI. It already had commands for installation, running, reading page structure, and interacting with UI. This time it adds android preview:

Directly renders @Preview to PNG in the terminal, and can also export a component tree JSON with --component-tree. No emulator startup, no Android Studio needed.

For example, after an Agent modifies a Compose page, it can directly get the preview image and component structure, then check the layout against task requirements.

Google says in internal UI task tests, Agents using android preview completed tasks 77% faster, with Token usage reduced to as little as one-third.

Real devices are also connected to this line. android device remote lets you reserve a physical device from Google's device lab, then connect it to your local adb. Subsequent installation, running, and debugging work like a local device. android device hub also provides a standalone device screen and interaction window, letting you view local emulators and remote real devices at the same time:

For instance, to have an Agent check a page after login, you can build and install the App, then use android layout to read the accessible UI structure, android input to click, type, and swipe, and finally capture a screenshot for verification.

If you only need to check Compose static layout, run android preview first to skip the overhead of booting a full device. Google even released official Android CLI plugins for Claude Code and Codex:

codex plugin marketplace add android/android-cli-plugin
codex plugin add android-cli@android-cli-plugin

Of course, this has implications for Flutter too. Flutter has its own AI Plugin, and here the Android-side APK installation, device operations, screenshots, and system Trace can reuse the same underlying tools.

Three, Performance Analysis

Google also showed a very complete example:

Give Claude Code a batch of user flows to find memory leaks in an App. The Agent runs the flows in parallel across different emulators, captures Heap Dumps, and sends them to LeakCanary on the development machine for analysis. This way the device doesn't bear the full heap analysis, then it follows the object reference chain back to the code to fix it, and finally reruns the flows to confirm.

That is the same Claude Opus 5.5, same Prompt, same batch of 45 user flows, 6 Android emulators, on an open-source App with 40,000 lines of code, running on an Apple M4 Pro.

So roughly 1.9x faster, 24% fewer Tokens.

As for how the leak was found: it discovered that ConnectivityManager's internal callback collection holds an anonymous NetworkCallback, which implicitly references MainActivity. The Activity had already exited, but the system service still holds the callback, so GC can't collect the Activity:

Figure 7: LeakCanary's GC Root reference chain, and AI's explanation of the unregistered NetworkCallback

Following this reference chain, the Agent can inspect the code that registers the NetworkCallback, add the unregister operation in the correct lifecycle position, then rerun the page entry/exit flows to see if the old Activity is still retained.

Additionally, android signals brings Firebase Crashlytics' production crashes, ANRs, and memory issues to the terminal. Production OOMs and Android 17 Memory Limiter Kill Heap Dumps also require Crashlytics' pre-approved access capability. After obtaining them, you can restore information with R8 Mapping, then use Perfetto and code to locate the issue.

Four, Compilation Optimization Also Becomes Quantifiable

This round of Android also updated Android Performance Analyzer (APA) and androidx.tracing 2.0. Previously with Perfetto, you often saw that a segment of work took a long time, but the next step was to find the code yourself. Now application Trace can include source files, line numbers, and parameters. Coroutine cross-thread work can also be associated through Flow, so Agents can match slow operations to specific call sites.

Compose 1.13's Recomposition Tracing is even more direct: it writes the State Read/Write that causes recomposition into the Trace. Selecting a State Write shows the call stack and which Composable recomposition it triggered. For example, if an animation state writes frequently, the page recomposes continuously. Previously you could only see the recomposition count; now you can trace back to who is writing that value.

One important condition: Recomposition Tracing has much higher overhead than ordinary Composition Tracing.

R8 can solve problems from another angle. For example, when App size won't come down, everyone knows to check ProGuard/R8's -keep, but not which broad rule from a third-party library blocks the most optimization. As we discussed before, the R8 Configuration Analyzer from AGP 9.3 can separately calculate coverage scores for shrinking, optimization, and obfuscation, rank Keep Rules by impact, and generate reports without building a full APK:

./gradlew :app:analyzeReleaseR8Config

There's also an experimental project called Lightbuild, which replaces traditional executable Gradle configuration with declarative YAML and saves pre-parsed dependencies, making it easier for Agents to read, edit, and query the build structure. This idea is quite interesting, but Google explicitly recommends that existing and production projects continue using Gradle/Kotlin DSL. For now, Lightbuild is mainly suited for small new projects and prototypes; it's still a concept.

Overall, Android is also aligning with AI, but KMP has been lagging behind. JetBrains has been falling behind in the AI era. This time, Google officially starts unifying compilation, devices, UI previews, production exceptions, Heap, and Trace into tool interfaces that Agents can call and check results from. The overall trend, like Flutter, is AI toolization and AI framework-ization. The old-style programming looks like prosperity of the past.

Comments

Top 4 of 8 from juejin.cn, machine-translated. The original thread is authoritative.

栈与烟火

Direct native interop is out—Xiao Guo, aren't you going to mention it? https://dart.dev/interop

恋猫de小郭

Hasn't this been around for a long time?

栈与烟火  → 恋猫de小郭

It's not that—the earlier one was native interop, and now there's an additional one: direct.

莫憎

In the era of AI, far fewer people read technical documentation. Guo Bao, what's your take on this?

恋猫de小郭

You don't write it, so this is how AI sees it, right?

路人甲酱100399

Bro, there's a typo: 林外

余小二126

https://mp.weixin.qq.com/s/G6hCtavWEkw710SexTGJFg