2026 年 5 月 15 日Google 在 The Android Show | I/O Edition 里提前放出了 Android 今年的主线。

这更像一次方向切换：Android 正在从“运行 App 的程序”，变成“连接 App、设备形态和 AI Agent 的程序”。

Gemini Intelligence

Google 用了一个很明确的表达：Android 正在从 mobile operating system 变成 mobile intelligence system。

开发者痛点：过去我们只负责权限、调度、窗口、通知等程序职责。AI 能力几乎只能在单个 App 内部实现，导致跨 App 场景无法流畅完成。

现在 Google 想让 Gemini 更深地进入程序层。让程序里的 Agent 能够理解使用者意图，判断需要哪个 App 的能力，再完成跨 App 的操作。

例如使用者说“把邮件里的会议时间加到日历里”。程序不应该只打开 Gmail 或 Calendar。而是先从邮件里提取上下文，再调用日历能力创建事件。

痛点解决：这将改变 Android App 的功能边界——App 不再仅面向人提供 UI，还要面向 Agent 暴露结构化能力。

Googlebook 把 Android 拉到桌面

发布中最像新品类的是 Googlebook。它不是简单复活 Pixelbook，也不是把 Chromebook 换个名字，而是围绕 Gemini Intelligence 设计的笔记本形态。首批将由 Acer、Asus、Dell、HP、Lenovo 等厂商推出，预计今年秋季上市。说起来，

开发者痛点：传统 Android 应用只需兼容手机屏幕尺寸。如“不会崩、不黑边、能横屏”。面对 Googlebook，这种最低要求已远远不够。话说回来，

• 窗口可调整；
• 键鼠可用；怎么说呢，
• 快捷操作清晰；
• 列表‑详情结构合理；
• 文件与跨设备能力自然衔接。

如果程序能看懂上下文。但 App 没有把“创建日程”“保存内容”等动作结构化暴露出来Agent 最终只能帮使用者打开对应 App，而无法直接完成任务。

AppFunctions 是 Android 侧的 MCP

The Android Show 中最 AppFunctions。说到官方定义，AppFunctions 允许 Android App 把特定功能暴露给程序、AI Agent 和助手发现并调用。

开发者痛点：

• 传统 Intent 难以描述复杂业务逻辑；
• 缺乏统一协议导致跨应用协作碎片化； 按理说，
• UI 与业务逻辑耦合。使得功能难以被程序直接调用。

class NoteFunctions( private val noteRepository: NoteRepository ) { @AppFunction suspend fun createNote( appFunctionContext: AppFunctionContext,title: String。content: String ): Note { return noteRepository.createNote } } @AppFunctionSerializable data class Note( val id: Int,val title: String,val content: String )

这段代码说明两个关键变化：

1. 功能结构化描述：Agent 需要函数名、参数、返回值还有语义说明，而不是凭“猜测”来调用。
2. 业务能力脱离 UI：“创建笔记”不再绑定页面按钮，而是可以被程序 Agent 直接调用。

痛点缓解：

• 提供统一的功能协议，让 AI Agent 能可靠地发现并执领域务操作；
• 降低跨应用协作实现成本，从而让使用者用起来更舒服与转化率。

Widget 和 Glance 不再只是桌面小组件

This year’s show also highlighted Widget。Glance,and RemoteCompose.

• 传统 RemoteViews 写法冗长且易出错；Diverse device forms require consistent yet lightweight UI representations;User‑driven customization often limited to static layouts.

  The new “Create My Widget” demo lets users describe a widget in natural language and instantly place it on home screen.

  This shifts widgets from pure visual ornaments to integral parts of multi‑form factor experience. A wear or fitness app that only offers a full‑screen activity will lose presence across se surfaces.

  Pain point solution:

  • Glance-based APIs let developers write widgets with Compose‑like syntax,dramatically reducing boilerplate;If RemoteCompose's coverage expands。UI logic can be shared 娱乐ween Activities and surface‑level widgets,ensuring consistency;Treat widgets as lightweight task entry points,not just marketing slots.

    Adaptive UI 会继续往默认项走

    The show reaffirmed that Android is no longer single‑screen centric. Supported form factors now include foldable。tablet,car,XR,and upcoming Googlebooks.

    Pain point:

    • Cumbersome “patch‑style” adaptations for each new device family;Lack of a unified layout strategy leads to duplicated codebases and inconsistent UX;按理说，Difficulties maintaining state across dynamic window sizes.

      The solution is to adopt a “design‑once‑run‑anywhere” mindset using Compose’s responsive layout components,Navigation’s size classes。and WindowManager’s bounds APIs. By defining app’s structure first—screens → navigation graph → state containers—UI can automatically reflow across phone single‑column,tablet master/detail,desktop resizable pane,car minimal view,or XR spatial layout.

      Navigation 更像架构调整

      The updated Jetpack Navigation isn’t just a rename;it now embraces multi‑stack handling,deep links across form factors,adaptive layout coordination。state restoration and cross‑device page organization.

      • Siloed navigation logic scattered in individual Activities/Fragments makes adaptive UI integration painful;Lack of clear separation 娱乐ween navigation state and business state leads to bugs when windows change size or orientation.

        A robust approach is to decouple navigation state from page state and business actions. For example:

        • A list→detail flow on phone becomes push navigation;on tablet it becomes side‑by‑side panes;on desktop it may replace a right panel;on car it simplifies to a single screen.

          This unified model reduces refactor effort when new form factors emerge and ensures consistent behavior for agents that may invoke any of those screens programmatically via @AppFunction.

          Android XR 正在补齐开发者链路

          The Android XR SDK DP4 was mentioned briefly;more details will be unveiled at Google I/O.

          Pain point for most teams:

          • Lack of clear guidance on input handling & spatial UI composition for XR;X​R-specific APIs feel isolated from mainstream Android development flow;No direct path to expose XR capabilities through existing @AppFunction/Kotlin Multiplatform .

            X​R forces platform to rethink input pipelines,window management,media handling,and AI assistant collaboration—all of which will eventually trickle back into regular Android APIs.

            聚焦 AI + 多形态 + 功能暴露的统一主线

            The signals from The Android Show | I/O Edition a clear:

            1. A I Agent : System‑level understanding of user intent.
            }
            2. Diverse Device Forms : Apps must adapt seamlessly across screens.
            }
            3. S tructured Capability Exposure : Business logic must be discoverable by agents without UI friction.
            }

            If you keep focusing only on Activity UI you’ll soon hit scalability walls. Instead design your app as a collection of composable capabilities that can be invoked by system anywhere—on phone screens。foldables,desktop windows,car displays,or even inside an AR headset—while exposing clear contracts via @AppFunction . This shift directly addresses today’s developer pain points and positions your product for AI‑driven multi‑device future.