Android Dev Summit 2026: Google brings developers back together after four years and puts agents at the center of Android

Mountain View, October 28, 2026 — After four years without a dedicated event, Google brought back the Android Dev Summit. The last edition was in 2022; since then, platform news had to share the stage with the rest of Google I/O. This time it was two days devoted entirely to Android, at the Bay View campus, with the keynote streamed on YouTube and an extended edition in London.

The keynote's message was blunt: Android is now built with AI agents and for AI agents. Android Studio opened its doors to agents from other companies, such as Claude and Codex. Android CLI gave those agents access to real devices. And apps gained a standard way to offer their functions to Gemini.

In this briefing I gather what was announced, how mature each piece is and — the part the keynote moves through quickly — how to use each one day to day, with code.

Event fact sheet

When	October 28–29, 2026
Where	Google's Bay View campus, Mountain View (US), plus an extended edition in London
Context	First Android Dev Summit since 2022
Tracks	AI experiences, Android XR, Apps foundation, Tools & performance
Keynote	About one hour, with live demos — watch on YouTube

The headlines

• Android Studio Rabbit 2 reaches stable and accepts any ACP-compatible coding agent — Claude, Codex, Antigravity and 40+ others.
• Android CLI gains remote physical devices, Compose Preview rendering in the terminal, a LeakCanary-powered profiler and official plugins for Claude Code and Codex.
• A traffic-light release checklist: the play-policy-insights skill audits your app before you submit to Google Play and flags 🟢🟡🔴 what's missing.
• XML-to-Compose migration with a right-click, driven by an agent inside Android Studio.
• AppFunctions goes beta: functions in your app become tools for Gemini and other agents, through Android MCP.
• A2UI (alpha): agents can now answer with native Compose screens built from your design system.
• Gemini Nano 4 + ML Kit Agentic API (alpha): a whole agent running on the device, with function calling.
• Jetpack AppState (alpha) brings Compose's state model to ViewModels and repositories.
• Googlebook, foldables and Android XR: one codebase for many screens. XREAL AURA debuts as the first wired XR glasses running Android XR.

---

1. What you can ship today (and what is still a lab)

Before installing everything, check how mature each announcement is.

My rule of thumb: stable goes to production, beta goes behind a feature flag, alpha and preview stay in POCs and study projects.

---

2. Android Studio Rabbit 2: bring your own agent

Android Studio is no longer "the IDE with Gemini". With Bring Your Own Agent (BYOA), now stable in Rabbit 2, it hosts any agent that speaks the Agent Client Protocol (ACP).

How to turn it on:

1. Open Settings > Tools > AI > Agents.
2. Install agents from the marketplace (Claude Agent, Codex, Antigravity…). You can keep several and switch.
3. The agent now sees what only the IDE knows: project and build structure, symbol resolution, Compose Preview rendering, the Emulator and Logcat.

Three more features change the daily workflow:

• Change Review — agentic review of the changes your agent made. Start it from pending agent changes, the Git window, or with /review. You get an issues report and a guided walkthrough for large changes.
• Migration Assistant (Canary) — right-click an XML layout > AI › Migrate to Compose and the agent migrates the screen to Compose. There's a full section on it further down.
• Android Bench 2.0 — a leaderboard that scores models and agent harnesses on long Android tasks (migrating UI, building an app from mocks), measuring whether the result actually works, plus cost and time. Great for picking your team's agent: developer.android.com/bench.

ACP vs MCP: don't mix them up

This is the point I see causing the most confusion. Two protocols, two jobs:

---

3. Android CLI: the whole toolchain in your agent's hands

Android CLI is the tool-first interface for any terminal, agent or CI pipeline. The idea is simple: your agent stops burning tokens guessing how Android works and uses official tools instead.

# install the CLI and set up your agent
android init

# a real physical device from a Google device lab (via Firebase)
android device remote connect
android device hub            # window to view and control devices and emulators

# Compose Previews with no emulator and no IDE
android preview

# performance and memory
android profiler systemtrace
android profiler heapdump capture
android profiler leakcanary

# binary quality and production signals
android analyze app-release.aab
android signals

# skills and docs
android skills list
android skills add jetpack-compose-performance
android docs search "predictive back"

Google's numbers stand out: agents using android preview finished UI tasks 77% faster with up to 3x fewer tokens.

Official plugins for Claude Code and Codex

# Claude Code (inside a session)
/plugin marketplace add android/android-cli-plugin
/plugin install android-cli@android-cli-plugin

# Claude Code (terminal)
claude plugin marketplace add android/android-cli-plugin
claude plugin install android-cli@android-cli-plugin

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

The plugin gives your agent what it needs to create projects, manage emulators, inspect live layouts, run Journeys, install official skills and search the Android Knowledge Base.

Official skills

There are 30+ skills across 20+ areas, each backed by evaluations. They target the areas where models tend to fall short: Compose performance, new camera APIs, security audits. A few worth installing now:

• jetpack-compose-performance
• android-profiler
• r8-analyzer
• play-policy-insights (audits code, manifest and SDKs against Play policies before you submit)
• android-intent-security and android-permissions-security

Repo: github.com/android/skills.

---

4. Validation: the agent checks its own work

The "Validating apps with Android Prototype" segment of the keynote (12:45) drives home one idea: a good agent verifies what it did. The most memorable demo used Claude Code:

Google gave the agent a list of critical user journeys and a single prompt — find and fix memory leaks. Claude ran each journey on a separate device in parallel, used android profiler leakcanary, followed each reference chain back to the code, fixed it and re-ran everything to confirm.

What powers this workflow:

• Journeys — user flows written in natural language. Your team writes them; the agent runs them.
• Built-in LeakCanary — in the CLI and in the Studio Profiler, with Fix with AI (Canary).
• Android Performance Analyzer (APA) — the Profiler's engine now powers the CLI too. With the android-profiler skill, the agent captures a trace, analyzes it, proposes a fix and measures the impact.
• androidx.tracing 2.0 — trace sections with file, line and arguments; coroutines show up as connected flows. Start with androidx.tracing:tracing-wire.
• Recomposition tracing (Compose 1.13) — shows why something recomposed, back to the state write that caused it.

From a production crash to a fix

android signals brings crashes, ANRs and memory issues to the terminal. Crashlytics now collects heap dumps from real OOMs and Android 17 Memory Limiter Kills, deobfuscated with your R8 mapping and opened in Perfetto (early access).

R8 without fear

# AGP 9.3: a score for your config and a ranking of the costliest keep rules
./gradlew :app:analyzeReleaseR8Config

Pair it with the r8-analyzer skill and replace broad keep rules with Jetpack Keep (alpha), type-safe annotations that lint can add for you.

---

5. Before you ship: the traffic-light checklist

One of the most practical moments of the event: instead of a manual release checklist, you ask the agent to audit the app and it returns a traffic-light report — 🟢 what's fine, 🟡 what needs a review, 🔴 what blocks submission.

The official skill: play-policy-insights

This format comes from the official play-policy-insights skill, which audits your code, manifest and SDKs against Google Play policies and cross-checks your Data safety declaration.

1. Install the skill

android skills add play-policy-insights

# alternative, outside Android CLI:
npx skills add https://github.com/android/skills --skill play-policy-insights

2. Run it with a prompt (this is the one Google suggests):

Audit this app for Google Play policy compliance before I submit it.

3. What it checks

• Data safety — compares what your code collects and transmits with what you declared in the Play Console.
• Demo login credentials — whether Play reviewers can actually get into the app.
• Restricted permissions — sensitive or deprecated permissions where a scoped alternative is expected.

4. How to read the report

Overall status	Meaning	What to do
🟢 Compliant	No active violations found	Go ahead and submit
🟡 Needs Review	No critical violations, but manual Play Console declarations or restricted permissions need attention	Review before submitting
🔴 Non-Compliant	Violations or Data safety mismatches	Fix before submitting

Each finding has a severity — 🔴 Critical (verified violation), 🟡 Important (for example, a deprecated permission where a scoped one is expected), 🔵 Suggestion (advisory) — and lists the policy, affected files, evidence, a confidence level, a recommendation and reference links. The report ends with Data safety discrepancies, local data access and a remediation checklist.

Two caveats:

• The report is advisory: it is not legal advice or a guarantee of approval.
• The skill writes scratch files to .scratch/play_policy_insights_<uuid> at the project root. Add .scratch/ to your .gitignore.

In Android Studio, Play Policy Insights also shows up as lint checks right in your code.

Going further: a "release readiness" skill with every gate

Play policy is only one gate. With Android CLI's tools you can write your own skill that runs every gate and returns a single traffic light. Here's an example I wrote for study — adapt paths and thresholds to your project:

---
name: release-readiness
description: Use before publishing a release. Runs build, size, Play policy, security, stability and critical-journey gates and returns a traffic-light report.
---

# Release readiness

Run every gate below, in order. Do not stop at the first failure: the report must show all gates.

## Gates

1. **Build** — `./gradlew :app:bundleRelease`. 🔴 if it fails.
2. **Size and R8** — run `android analyze` on the release AAB and `./gradlew :app:analyzeReleaseR8Config`.
   🟡 if the shrinking score dropped vs. `docs/release/last-analyze.json`. 🔴 if obfuscation is off.
3. **Play policy** — run the `play-policy-insights` skill and copy its overall status.
4. **Security** — run the `android-permissions-security` and `android-intent-security` skills. 🔴 for any Critical finding.
5. **Stability** — `android signals` for the current production version. 🟡 for new crash or ANR clusters.
   🔴 if crash-free users fell below the threshold in `docs/release/thresholds.md`.
6. **Critical journeys** — run the Journeys in `journeys/`. 🔴 if any fails.

## Output

Write `release-report.md` with:
- the overall status (the worst gate wins);
- one row per gate: status, gate, evidence, next action;
- a remediation checklist.

Do not publish, upload or tag anything. Shipping is a human decision.

In Claude Code, save it as .claude/skills/release-readiness/SKILL.md and call it with /release-readiness. In other agents, use their equivalent skills folder. The "worst gate wins" rule is what turns six checks into one honest traffic light.

---

6. Compose-first in practice: from XML to Compose with a right-click

Another keynote highlight: migrating a screen from XML Views to Jetpack Compose is no longer a manual project. The Migration Assistant (Android Studio Canary) shows up in the layout's context menu and hands the work to an agent.

Step by step

1. Install the latest Android Studio Canary — the feature lives in that channel.
2. Pick your agent. It works with Studio's built-in agent or with any agent added through Bring Your Own Agent (Claude, Codex…). It's also worth installing the official Migrate to Compose skill, listed in android skills list.
3. Right-click the XML layout (for example, res/layout/fragment_profile.xml) and choose AI › Migrate to Compose. To migrate the whole project, open the action palette and run the migration from there.
4. Scope it with the agent. It asks what to migrate now, what stays in interop, and how to handle custom views.
5. Review the plan. The agent drafts a step-by-step plan before touching any file.
6. Conversion. The agent converts the layout, the view-binding code and the related logic into idiomatic Compose.
7. Follow the timeline. The agent window shows which step is running and where to resume if it stops. Progress is saved with the conversation, so you can step away and come back.
8. Validate. Check the Compose Previews (or android preview in the terminal) and run Change Review with /review before committing.

Example: what goes in and what comes out

An illustrative example of this kind of conversion — a profile screen using ViewBinding.

Before (XML + ViewBinding):

<!-- res/layout/fragment_profile.xml -->
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical"
    android:padding="16dp">

    <TextView
        android:id="@+id/name"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textAppearance="?attr/textAppearanceHeadlineSmall" />

    <TextView
        android:id="@+id/role"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

    <Button
        android:id="@+id/follow"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/follow" />
</LinearLayout>

class ProfileFragment : Fragment(R.layout.fragment_profile) {
    private val viewModel: ProfileViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        val binding = FragmentProfileBinding.bind(view)
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { state ->
                    binding.name.text = state.name
                    binding.role.text = state.role
                    binding.follow.isEnabled = !state.isFollowing
                }
            }
        }
        binding.follow.setOnClickListener { viewModel.follow() }
    }
}

After (idiomatic Compose, with hoisted state):

@Composable
fun ProfileRoute(viewModel: ProfileViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()
    ProfileScreen(state = state, onFollow = viewModel::follow)
}

@Composable
fun ProfileScreen(state: ProfileUiState, onFollow: () -> Unit, modifier: Modifier = Modifier) {
    Column(modifier.padding(16.dp)) {
        Text(state.name, style = MaterialTheme.typography.headlineSmall)
        Text(state.role)
        Button(onClick = onFollow, enabled = !state.isFollowing) {
            Text(stringResource(R.string.follow))
        }
    }
}

@Preview
@Composable
private fun ProfileScreenPreview() {
    ProfileScreen(ProfileUiState(name = "Ada", role = "Android Engineer"), onFollow = {})
}

During the transition, the Fragment can stay and simply host Compose:

class ProfileFragment : Fragment() {
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?) =
        ComposeView(requireContext()).apply {
            setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
            setContent { MaterialTheme { ProfileRoute() } }
        }
}

Checklist to review what the agent produced

• [ ] Is state hoisted (stateless Composable + a Route that collects the ViewModel)?
• [ ] Do texts use stringResource instead of hardcoded strings?
• [ ] Was the XML theme mapped to MaterialTheme (colors, typography, shapes)?
• [ ] Is accessibility preserved: contentDescription, touch target sizes, reading order?
• [ ] Were UI tests moved to composeTestRule (or screenshot tests)?
• [ ] No needless recompositions? Use Compose 1.13's recomposition tracing and the jetpack-compose-performance skill.
• [ ] Were the old XML and binding class removed once the screen settled?

Recommended strategy: migrate screen by screen, starting with the simplest ones or the ones you're about to touch anyway, and use ComposeView as the bridge. Migrating the whole app at once produces a diff nobody can review — even with an agent.

---

7. Compose-first: state beyond the UI with Jetpack AppState

If you have ever fought a five-Flow combine, you will like this one. Jetpack AppState (alpha) runs the Compose runtime outside the UI, in ViewModels, repositories and services. Two pieces:

• Transform — runs a @Composable block with no UI and returns a State<R> that recomposes whenever any state it reads changes.
• StateStore — a type-safe map of state shared across activities, services and widgets, with optional DataStore persistence.

[versions]
appstate = "1.0.0-alpha01"

[libraries]
androidx-appstate-transform = { module = "androidx.appstate.transform:transform", version.ref = "appstate" }
androidx-appstate-transform-testing = { module = "androidx.appstate.transform:transform-testing", version.ref = "appstate" }
androidx-appstate-statestore = { module = "androidx.appstate.statestore:statestore", version.ref = "appstate" }

Note: any module that calls transform needs buildFeatures { compose = true } and the Compose Compiler plugin, even without UI.

A ViewModel that switches sources based on connectivity:

class HomeViewModel(
    private val mediaRepository: MediaRepository,
    private val networkMonitor: NetworkMonitor,
) : ViewModel() {
    val uiState: State<HomeUiState> = transform<HomeUiState>(
        initialValue = HomeUiState.Loading,
        scope = viewModelScope,
    ) {
        val isOnline by networkMonitor.isOnline
        val tracks = if (isOnline) {
            mediaRepository.allTracksFlow.collectAsState(initial = null).value
        } else {
            mediaRepository.downloadedTracksFlow.collectAsState(initial = null).value
        } ?: return@transform HomeUiState.Loading

        HomeUiState.Success(tracks = tracks, isOnline = isOnline)
    }
}

No flatMapLatest, no stateIn — a plain if decides which source to observe.

Search debounce with LaunchedEffect, inside transform:

var query: String by mutableStateOf("")

val searchResults: List<String> by transform<List<String>>(
    initialValue = emptyList(),
    scope = coroutineScope,
) {
    var results by remember { mutableStateOf(emptyList<String>()) }
    LaunchedEffect(query) {
        if (query.isBlank()) { results = emptyList(); return@LaunchedEffect }
        delay(300.milliseconds)
        results = api.search(query)
    }
    results
}

When NOT to use transform: it represents the current value, not a stream of events. Rapid updates before recomposition are dropped, and equal consecutive values trigger nothing. For running totals, logs, one-time events and backpressure, stick with Flow.

Testing is simple with transformTest:

@Test
fun testStateUpdate() = transformTest {
    var sourceState by mutableStateOf(0)
    val state = transform(initialValue = 0, scope = backgroundScope, dispatcher = testDispatcher) {
        sourceState
    }
    sourceState = 1
    advance()
    assertThat(state.value).isEqualTo(1)
}

Rounding it out: Compose 1.13 (stable soon: Grid and FlexBox stable, Progressive Blur, Formatted Text) and Navigation 3 1.2 (stable: deep links and richer predictive back). Examples: github.com/android/appstate-recipes.

---

8. A2UI: when the agent's answer is a screen

A wall of chat text is poor UX. With A2UI (Agent-to-UI), the agent sends declarative JSON and your app renders native components from your own catalog — no arbitrary code is executed.

dependencies {
    implementation("androidx.a2ui.compose:compose-runtime:1.0.0-alpha01")
    implementation("androidx.a2ui.compose:compose-ui:1.0.0-alpha01")
    androidTestImplementation("androidx.a2ui.compose:compose-ui-testing:1.0.0-alpha01")
}

ViewModel:

class AgenticUiViewModel : ViewModel() {
    private val parser = A2uiMessageParser()
    private val processor = A2uiMessageProcessor(catalogs = listOf(CustomDesignSystemCatalog))

    val a2uiSurfaces: StateFlow<List<A2uiSurfaceModel>> = processor.activeSurfaces

    init {
        viewModelScope.launch(Dispatchers.Default) { processor.collectMessages() }
        // clicks and errors flow back to the agent
        viewModelScope.launch(start = CoroutineStart.UNDISPATCHED) {
            processor.outboundEvents.collect(::handleOutboundA2uiEvent)
        }
    }

    fun onNetworkMessage(json: String) = processor.processInput(parser, json)
}

Screen:

@Composable
fun AgenticUiScreen(viewModel: AgenticUiViewModel) {
    val surfaces by viewModel.a2uiSurfaces.collectAsStateWithLifecycle()
    Column(Modifier.fillMaxSize()) {
        surfaces.forEach { surface ->
            key(surface.id) { A2uiSurface(surfaceModel = surface) }
        }
    }
}

My favorite part: hallucination defenses come built in. An unknown component becomes an error reported back to the agent so it can self-correct; payloads are validated against a schema; absurd list indexes switch to a sparse map so they can't blow up memory.

---

9. Gemini Nano 4: a whole agent on the device

Gemini Nano 4 brings native function calling, and ML Kit gained an Agentic API (alpha) that runs the complete agent loop on the device, on top of AICore.

Requirements: Android 14+ enrolled in the AICore Developer Preview, a supported device, minSdk 26, Kotlin 2.3+.

dependencies {
    implementation("com.google.mlkit:genai-agent:1.0.0-alpha1")
    // optional: tools via AppFunctions
    implementation("androidx.appfunctions:appfunctions:1.0.0-alpha13")
    ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha13")
}

val agent = Agent.builder()
    .setName("Assistant")
    .setInstructions("You are a helpful on-device assistant.")
    .build()

val runner = AgentRunner(agent)
val session = runner.getOrCreateSession("chat_session")

val prompt = Content.builder().text("Can you help me organize my day?").build()

lifecycleScope.launch {
    session.runAsync(prompt)
        .textTokens()
        .collect { token -> Log.d("Agent", token) }
}

// no history: runner.runSingleTurnAsync(prompt)
// on destroy: runner.close()

Limits you need to know:

• maxTurns defaults to 10, to prevent runaway loops and save battery.
• Inference only runs while your app is in the foreground; too many calls return ErrorCode.BUSY.
• The model can pick the wrong tool or argument: the safety of actions is your app's job. Confirm sensitive actions with the user.
• For huge knowledge bases, Google itself recommends a hybrid architecture with cloud models.

---

10. Android MCP and AppFunctions: your app as a Gemini tool

To me, this is the most strategic change of the event. AppFunctions is the mobile equivalent of MCP tools: your app becomes an on-device MCP server, and Gemini (or any authorized agent) discovers and calls your app's functions to fulfill a user's request. It is in beta and runs on Android 16+.

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "TaskAppFunctionService",
    appFunctionXmlFileName = "task_app_function_service",
)
abstract class BaseTaskAppFunctionService : AppFunctionService() {
    @Inject internal lateinit var taskRepository: TaskRepository

    /**
     * Creates a task based on [createTaskParams].
     *
     * @param createTaskParams The parameter to describe how to create the task.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createTask(createTaskParams: CreateTaskParams): Task =
        withContext(Dispatchers.IO) {
            if (createTaskParams.title == null && createTaskParams.content == null) {
                throw AppFunctionInvalidArgumentException("Title or content should be non-null")
            }
            val id = taskRepository.createTask(createTaskParams.title, createTaskParams.content)
            taskRepository.getTask(id)?.toTask()
                ?: throw AppFunctionElementNotFoundException("Task not found for ID = $id")
        }
}

/** The parameter to create the task. */
@AppFunctionSerializable(isDescribedByKDoc = true)
data class CreateTaskParams(
    /** The title of the task. */ val title: String?,
    /** The content of the task. */ val content: String?,
)

Two details worth noticing:

1. The KDoc is the prompt. With isDescribedByKDoc = true, your docs become the description the agent reads to decide when to call the function. Write them for the model.
2. Typed exceptions (AppFunctionInvalidArgumentException, AppFunctionElementNotFoundException) tell the agent why a call failed, so it can try another way.

Testing without Gemini:

adb shell cmd app_function list-app-functions

AppFunctions vs a remote MCP server: AppFunctions runs locally, uses the app's real state and needs no backend. A remote MCP server is platform-agnostic and depends on the network. Agents consider both together.

To reach users, the Connected Apps Platform (preview) brings your app's services to Gemini and Search: build with Android MCP or remote MCP, prototype in Gemini dev mode, and register through the Google Connected Console.

⚠️ Reality check (Oct 2026): the Gemini integration is still limited to selected apps. You can implement and test today; for production there is an Early Access Program.

---

11. One codebase, many screens: Googlebook, foldables and XR

Googlebook is the new category of laptops built on an Android foundation, with partners such as HP, Dell, Lenovo, Acer and Asus. The same app runs on the phone and the laptop, with no separate codebase.

The Compose adaptive skill was updated so your agent can do the heavy lifting: keyboard shortcuts, pointer cursors, hover states and tooltips; migration to Grid, FlexBox and mediaQuery; end-to-end state handling; and foldable postures, such as tabletop layouts for media and camera screens.

📌 Heads-up from Google Play: in 2027 Play will look closely at how apps and games run on foldables. Follow the adaptive app quality guidelines.

Android XR and XREAL AURA

XREAL AURA is the first wired XR glasses running Android XR. It stays under 95 g because the compute lives in a puck powered by Snapdragon Reality Elite. It has a Sony Micro-OLED 1200p display at 120 Hz, runs Google Play apps and up to five virtual windows. Price: US$1,099 launch price through December (US$1,279 after), available in the US, Canada, Japan and South Korea.

For developers, the key news: the Jetpack XR core is now stable (SceneCore, ARCore for Jetpack XR and XR Runtime), and so are the XR glasses emulators in Android Studio and the Android XR Engine Hub. Compose for XR is still alpha.

The first step is spatializing a screen you already have:

Subspace {
    SpatialPanel(
        SubspaceModifier
            .height(824.dp)
            .width(1400.dp)
            .resizable()
            .transformingMovable(),
    ) {
        MyExistingScreen() // your current Compose screen
    }
}

Content inside Subspace only renders when spatialization is on. On a phone it is ignored, so the same code serves both worlds.

---

12. Beyond the keynote: 5 labs to try this week

1. An agent with eyes and hands (stable) — install Android CLI and the plugin in Claude Code or Codex, write 3 Journeys for your critical flows, and ask: "run the journeys, capture a startup trace and propose the highest-impact fix". Measure cold start before and after.
2. Quality gates in CI (stable) — run android analyze on your release AAB, store the JSON as a pipeline artifact and fail the build if the shrinking score drops. Use analyzeReleaseR8Config to go after the 5 costliest keep rules.
3. A ViewModel without combine (alpha) — rewrite a ViewModel with 3+ sources using transform and test it with transformTest. Compare readability and check whether any event got lost.
4. Your app as a tool (beta) — use the AppFunctions skill to find your 3 highest-value functions, implement one and validate it with adb shell cmd app_function list-app-functions.
5. An answer as UI (alpha) — build an A2UI catalog with 3 components from your design system and feed it fixed JSON before wiring a real model. Test the error path.

---

What the Dev Summit leaves behind

The return of the Android Dev Summit was not defined by a single API. It was defined by a shift in the Android developer's role: orchestrating agents that build, validate and optimize the app — and designing the app to be used by agents.

If you want to act now, here is my read:

• Adopt today: Rabbit 2 with BYOA, Android CLI with skills, Change Review and the traffic-light checklist in your team's workflow.
• This quarter: migrate the XML screens you touch most, map which app functions become AppFunctions, and get the UI adaptive for foldables and Googlebook.
• As POCs: A2UI, Gemini Nano 4 and AppState, following the APIs on their way to stable.

Which of these will you try first? Tell me in the comments. 👇

---

Sources

• Android Dev Summit 2026 keynote
• Agentic and Flexible: A next era of Android development
• What's new in Android developer tools and performance at Android Dev Summit
• Android skills (catalog) and play-policy-insights
• Overview of AppFunctions
• Render A2UI surfaces in your app
• Build agentic workflows with Gemini Nano
• Jetpack AppState and Transform
• Develop UI with Jetpack Compose for XR
• TechCrunch — Xreal Aura

This article is also available in Portuguese and Spanish.