2026 年 5 月 12 日，Google 在 The Android Show | I/O Edition 里提前放出了 Android 今年的主线。
它更像一次方向切换：Android 正在从"运行 App 的系统"，变成"连接 App、设备形态和 AI Agent 的系统"。
Gemini Intelligence
Google 这次用了一个很明确的表达：Android 正在从 mobile operating system 变成 mobile intelligence system。
这句话的重点不在营销词，而在系统职责变化。
过去 Android 系统更多负责权限、调度、窗口、通知、输入、后台限制、安装分发。AI 功能通常是某个 App 内部的能力，比如聊天、摘要、搜索、生成内容。
现在 Google 想让 Gemini 更深地进入系统层。
用户不一定要打开某个 App，再一步步点到目标页面。系统里的 Agent 可以理解用户意图，判断需要哪个 App 的能力，再完成跨 App 的操作。
比如用户说"把邮件里的会议时间加到日历里"，系统不应该只打开 Gmail 或 Calendar。更合理的是先从邮件里取到上下文，再调用日历能力创建事件。
这会改变 Android App 的功能边界。
过去 App 主要面向人提供界面。后面 App 还要面向 Agent 暴露能力。
Googlebook 把 Android 拉到桌面
这场发布里最像新品类的是 Googlebook。
它不是简单复活 Pixelbook，也不是把 Chromebook 换个名字。
Google 给它的定位是围绕 Gemini Intelligence 设计的笔记本形态。第一批会由 Acer、Asus、Dell、HP、Lenovo 等厂商推出，时间放在今年秋季。
这里对 Android 开发者更关键的是：Googlebook 基于 Android 技术栈，可以运行 Android App，并且强调和 Android 手机之间的连续体验。
这会把 Android App 推到一个更接近桌面生产力的窗口环境里。
过去很多 Android App 对大屏的要求只是"不崩、不黑边、能横屏"。Googlebook 如果真正铺开，要求会变成：窗口可调整、键鼠可用、快捷操作清晰、列表详情结构合理、文件和跨设备能力自然衔接。
Googlebook 还提到 Magic Pointer。它把 Gemini 放进鼠标指针场景里，用户指向屏幕上的日期、图片、内容片段时，系统可以给出上下文动作。
这类交互会继续推动 AppFunctions 这种能力暴露机制。
如果系统能看懂上下文，但 App 没有把"创建日程""保存内容""添加清单"这类动作结构化暴露出来，Agent 最后还是只能帮用户打开 App。
AppFunctions 是 Android 侧的 MCP
The Android Show 里最值得 Android 开发者盯住的是 AppFunctions。
官方文档里给的定义很直接：AppFunctions 允许 Android App 把特定功能暴露给系统、AI Agent 和助手发现并调用。
它不是再做一个分享面板，也不是 Intent 的简单替代。
它更像 Android 本地 App 侧的"工具协议"。
MCP 解决的是 Agent 怎么调用服务端工具。AppFunctions 解决的是 Agent 怎么调用设备上的 App 能力。
一个记事 App 可以暴露创建笔记、编辑笔记、列出笔记；一个购物清单 App 可以暴露添加商品；一个日历 App 可以暴露创建事件。
官方文档里的最小形态大概是这样：
bash
class NoteFunctions(
private val noteRepository: NoteRepository
) {
@AppFunction(isDescribedByKDoc = true)
suspend fun createNote(
appFunctionContext: AppFunctionContext,
title: String,
content: String
): Note {
return noteRepository.createNote(title, content)
}
}
@AppFunctionSerializable(isDescribedByKDoc = true)
data class Note(
val id: Int,
val title: String,
val content: String
)这段代码说明了两个变化。
第一，功能需要被结构化描述。Agent 不能只靠"猜这个 App 能做什么"，它需要函数名、参数、返回值和语义说明。
第二，App 的核心能力要从 UI 事件里拆出来。以前"创建笔记"可能绑定在某个页面按钮上，后面它也可能被系统 Agent 直接调用。
AppFunctions 当前还是 experimental preview，并且要求 Android 16 或更高版本。完整生产链路也只对有限 App 和系统 Agent 开放。
但方向已经很清楚：App 不再只提供 Activity，也要提供可编排的功能入口。
Widget 和 Glance 不再只是桌面小组件
这次 Android Show 还提到 Widget、Glance、RemoteCompose。
这里的变化不只是"小组件更好看"。
面向用户侧，Google 展示了 Create My Widget。用户可以用自然语言描述自己想要的小组件，再把它放到主屏幕上。
Widget 正在变成 Android 多形态体验的一部分。手机桌面、折叠屏、平板、车机、XR，这些形态都需要低成本展示信息和触发操作。
如果一个天气、运动、音乐、日程、健康类 App 只能通过完整页面使用，它在多形态系统里的存在感会越来越弱。
Glance 的价值在这里会放大。
它让开发者用更接近 Compose 的方式写 Widget，同时避免直接手写 RemoteViews 的大量模板代码。
未来如果 RemoteCompose 能覆盖更多场景，Android UI 就会进一步从"某个 Activity 里的页面"扩展到"系统表面上的可组合体验"。
对业务团队来说，这类能力最好不要只当成运营入口。
更合理的做法是把 Widget 看成轻量任务入口：查看状态、恢复播放、开始运动、记录体重、确认行程、完成待办。
这些功能一旦和 Gemini、AppFunctions 结合，Widget 就不只是展示层，也会成为 Agent 理解用户上下文的一部分。
Adaptive UI 会继续往默认项走
The Android Show 里还有一条明确路线：Android 不再只围绕手机屏幕设计。
Google 提到的形态包括 foldable、tablet、car、XR，以及新的 Googlebooks。
这意味着 adaptive UI 不再是"大屏专项"。
以前很多团队做适配，是等平板版本、折叠屏专项、车机专项来了再补。后面这类补丁式适配会越来越吃力。
原因很简单：系统形态变多以后，同一套业务不一定只运行在一个窗口模型里。
一个页面可能在手机上是单列，在平板上是列表详情，在桌面窗口里是可调整宽度，在车机上要极简，在 XR 里要考虑空间层级。
Compose 侧的 responsive layout 组件、Navigation 3、窗口尺寸分类，这些都在服务同一个目标：让应用结构先适配，再让具体 UI 跟着变化。
Navigation 3 更像架构调整
Jetpack Navigation 3 也出现在这次开发者内容里。
它不是单纯把 API 名字换一遍。
从 Android 现在的方向看，导航系统要处理的问题会更多：多返回栈、多窗口、深链、adaptive layout、状态恢复、跨形态页面组织。
如果应用还把导航逻辑散落在多个页面里，后面接 adaptive UI 会很难。
更稳的方式是把导航状态、页面状态、业务动作拆清楚。
比如列表详情页不要只按"点击 item -> push detail screen"理解。它在手机上可能是跳转，在平板上可能是同屏更新，在桌面窗口里可能是右侧面板替换。
Navigation 3 的价值要放在这个背景下看。
它不是为了让旧项目马上重写，而是为了让复杂形态下的页面组织有更清晰的模型。
Android XR 还在往开发者链路补齐
Android XR SDK DP4 也被提到，更多内容会在 Google I/O 展开。
XR 现在还不是大多数 Android 团队的日常需求。
但它对 Android 架构的影响会提前发生。
因为 XR 会逼着系统和应用重新处理输入、空间布局、多窗口、沉浸式内容、媒体、3D 场景，以及和 AI 助手的协同。
这些问题不一定只留在 XR 设备上。
很多能力会反向影响普通 Android：更强的窗口管理、更清晰的 adaptive UI、更结构化的 App 能力暴露，以及更自然的语音和多模态交互。
所以 XR 不一定马上带来业务增量，但它会影响 Android 平台后续几年怎么设计 API。
最后
The Android Show | I/O Edition 这次释放的信号很集中：Android 正在把 AI Agent、多设备形态、App 能力暴露放到同一条主线上。
Android 开发后面不只是写页面，还要设计 App 能被系统理解、被 Agent 调用、被不同设备形态承载的方式。