At the Android Dev Summit on October 28, 2026, Google announced the stable release of Android Studio Rabbit 2. Developers can now choose from more than 40 ACP-compatible AI agents, including Claude Agent, Codex, and Antigravity, directly from their development environment. As of September, integration with external AI agents was limited to a preview in the Canary build; it is now available in the stable IDE.
Google also announced a new set of APIs that let AI call a variety of app features at runtime. These include mechanisms that make use of on-device AI, though some of the APIs are still in alpha. Using AI agents to help write code is a separate matter from making a finished app's features operable by AI. To make sense of this announcement, you need to understand what role each mechanism plays and how their release stages differ.
From Canary to stable: AI agents can now use Android's development tools
"Bring Your Own Agent (BYOA)," which lets developers use external AI agents in Android Studio, was a Canary-only preview feature when it was announced on September 24. Comparing the official blog post from September with the October 28 announcement, the change is not the introduction of new external AI integration but the extension of an existing feature to the stable version of Android Studio.
The integration is built on the Agent Client Protocol (ACP), which connects AI agents to the development environment. Through ACP, Android Studio lets agents refer to a project's structure, build settings, and Android platform information. Agents can also work with diagnostics, Jetpack Compose previews, and SDK and emulator operations, which makes it easier to carry out the whole development workflow, from AI-assisted code creation to verifying behavior in an Android environment.
That said, being available from Android Studio does not mean every AI agent is free. The September announcement explained that users sign in with a plan supported by each agent's service. Pricing, usage limits, and other terms follow the conditions set by each agent provider.
The Android CLI, used to develop Android apps from the command line, is also gaining features to help with verification. In addition to remote operation of real devices through Firebase, it can now preview screens built with Jetpack Compose. According to Google, this preview lets you check a screen without launching an emulator or deploying an APK.
For performance analysis, integration with Perfetto makes it possible to diagnose issues such as slow app startup, rendering jank, and launches from the background. Official plugins for Claude Code and Codex are also available. This makes it easier to use Android-specific development information and tools not only when working mainly in Android Studio but also when operating AI agents from the command line.
How does AI integration at development time differ from AI integration at app runtime?
Google also announced a beta of "AppFunctions," which lets AI agents call an app's features. It is a common interface for exposing an app's capabilities to on-device and system AI agents, and it supports integration through Android MCP. While ACP connects AI agents to the IDE during development, this mechanism lets AI use an app's features at runtime.
In other words, ACP mainly supports AI-assisted app development, while Android MCP and AppFunctions make an app's features usable by AI. They connect different things and serve different purposes, so the stable release of Android Studio cannot be equated with the release stage of the app-facing APIs.
The main features announced on October 28 are organized below by where they are used and what role they play. Release stages are based on Google's announcement that day; BYOA reflects the September 24 explanation, and ML Kit also takes the developer documentation into account.
| Item | Purpose / role | Connection method / how it runs | Release stage |
|---|---|---|---|
| Android Studio Rabbit 2 / BYOA | Use external AI agents during development, with Android-specific information and tools | Connects the IDE and development agents via ACP | Rabbit 2 is stable. BYOA was a Canary preview as of September |
| AppFunctions | Expose app features to on-device and system AI agents | Function calls through Android MCP | Beta |
| ML Kit Agentic API | Supports in-app tool execution, history management, and iterative processing | Uses Gemini Nano 4 and AgentRunner. Also supports discovering and running features exposed through AppFunctions | Alpha |
| A2UI for Jetpack Compose | Display interactive screens using app-specific UI components | Handles UI display, not the connection to AI | Alpha |
| Connected Apps Platform / Google Connected Console | Prototyping and registration for integration with Gemini and Google Search | Uses Android MCP or remote MCP. Prototype in Gemini's developer mode, then register in the Console | Preview |
Note that AppFunctions being "beta" reflects its positioning in the October 28 announcement; it does not mean that every related Jetpack package has become beta.
Though these features all belong to AI-agent technology, each handles different processing. For example, "A2UI for Jetpack Compose" is a mechanism for combining app-specific UI components to display interactive screens. While AppFunctions deals with the app features AI is permitted to use, A2UI handles the screen display related to those operations. It is important to distinguish between calling a function and generating and displaying UI.
The "Connected Apps Platform" is a mechanism for connecting apps with Gemini and Google Search. The outlined flow is to use Android MCP or remote MCP, try out behavior in Gemini's developer mode, and then register for production through the preview-stage "Google Connected Console." However, this announcement alone does not settle availability in Japan or when it will be opened to the general public.
How far does on-device AI work offline?
The "ML Kit Agentic API," which Google announced as an alpha, uses Gemini Nano 4 to support in-app function execution, conversation history management, and iterative processing for AI agents. Its core component, "AgentRunner," runs on top of GenerativeModel, which calls the model. According to the ML Kit developer documentation, the model reasons from inputs and retrieved information, executes typed Kotlin tools, and evaluates the results, repeating this cycle until a termination condition is reached.
Normally, implementing this kind of processing by calling an AI model directly requires developers to manage conversation history, tool calls, and returning execution results to the model themselves. AgentRunner provides a mechanism that handles this iteration and history management. It can also discover and run app features exposed through AppFunctions and pass their return values to the model. This makes it possible to build AI agents that do more than generate text: they actually execute features and decide on the next action based on the results.
However, it is important to be careful about the scope of the claim that it "runs on-device." What is processed on the device is the model's inference and the generation of execution plans; the tools being called do not necessarily all run offline. Google explains that prompts stay on the device, while noting that individual tools implemented by developers may use network communication or cloud APIs.
Therefore, even if model inference is completed on the device, that does not mean the agent as a whole never communicates externally. When building this into an app, you need to check not only which tools the AI can call but also what information each one handles and where it communicates. The on-device nature of the AI alone is not grounds for concluding that all processing is completed offline.
AgentRunner also includes a setting that limits the number of iterations to prevent an agent's processing from continuing indefinitely. The default value of "maxTurns" is 10. However, this only limits the number of repetitions; it does not guarantee the safety of the AI's decisions or tool execution. The model may call the wrong tool or pass inappropriate arguments, so responsibility for verifying the validity and safety of execution results remains with the developer.
The ML Kit Agentic API is also currently in alpha and is not covered by an SLA or a deprecation policy. Changes that break backward compatibility may be made in the future. When adopting it, you need to consider not only confirming that the API works correctly but also how to handle erroneous tool execution and a design that can accommodate specification changes.
Decide on the stable IDE and the alpha APIs separately
With the stable release of Android Studio Rabbit 2, developers can more easily use external AI agents from the IDE they are used to. When considering adoption, what matters is whether an agent can properly understand the existing project structure and build settings, and whether code changes can be verified using Android-specific diagnostics and previews. The pricing and terms of use of each agent also need to be compared.
On the other hand, exposing an app's features to AI through AppFunctions or the ML Kit Agentic API calls for a different kind of evaluation. You must decide which features to make callable and check the communication and data handling involved in running them. Limiting the number of iterations does not prevent inappropriate operations caused by wrong tool selection or arguments, so verifying execution results and handling abnormal situations are also necessary. For the alpha APIs, you also need to plan for future specification changes.
This announcement shows that the groundwork for bringing AI agents into Android development is advancing. However, it would not be appropriate to lump the now-stable development environment together with the still-alpha app-facing APIs under a single "agent-ready" label. You do not need to build the Agentic API into your app in order to use development agents in Rabbit 2. By evaluating development support and runtime AI integration separately, teams can adopt each according to its maturity and risk.