Android Dev Summit 2026 六个关键变化

如果只把 Android Dev Summit 2026 理解成“又发布了一批手机功能和 API”，就会漏掉开发链路层面的变化：Android Studio、Android CLI、官方 Skills 与验证工具正在形成一套可被 Agent 调用、被人审查、可由工具验证的执行环境。

这些变化主要体现在六条主线：Android Studio 从固定开发助手转向可接入多种 Agent 的工作台；CLI、Skills 与模型选择组成命令行执行基础；Change Review、性能分析和构建优化补齐验证链；Compose 用统一 API 简化多设备适配；ML Kit 与 Gemini Nano 把生成式 AI 延伸到应用侧；Play、XR、多设备媒体和健康服务则继续扩大 Android 的生态边界。

Android Studio 为什么会变成 Agent 工作台？

过去，IDE 通常提供代码补全、静态检查和调试工具，AI 助手则主要处理对话与代码片段。Rabbit 2 | 2026.2.2 逐步向外部 Agent 开放这些 IDE 能力。Agent 不只生成代码，还能获得项目上下文并调用真实开发工具。

ACP 和 MCP 到底差在哪？

ACP，即 Agent Client Protocol，解决的是“编辑器如何与编程 Agent 对接”；MCP 更偏向“Agent 如何连接外部工具”。两者不在同一个连接层级。

对比维度	ACP	MCP
主要连接对象	IDE 与编程 Agent	Agent 与外部工具、数据源
解决的问题	Agent 如何进入开发环境并使用 IDE 能力	Agent 如何获得工具并执行外部操作
Android 中的落点	Android Studio 接入、切换和调用 Agent	Agent 扩展自己的工具访问范围

ACP 并不决定模型本身有多聪明。它是一套 IDE 与 Agent 之间的通用通信接口：模型负责推理，ACP 负责把推理接入 Android Studio 的项目上下文和执行环境。

40 多种兼容 Agent 是怎样接入 IDE 的？

Rabbit 2 中的 BYOA，即 Bring Your Own Agent，已经进入稳定状态。开发者可以在 Settings > Tools > AI > Agents 中安装兼容 Agent，并使用自己的订阅或 API Key；多个 Agent 可以并存，再根据任务需要切换。

支持 40 多种兼容 Agent，意味着团队不必把开发流程绑定在单一产品上。例如，一个 Agent 可以负责日常代码修改，另一个用于迁移或专项分析。但“能接入更多 Agent”不等于“同时启用越多越好”：模型切换也会带来输出风格、工具调用、成本和行为可预测性的差异。实际项目中，更稳妥的做法通常是先固定一个主 Agent，再为确有需要的专项任务配置第二个入口。

Agent 为什么能理解当前项目？

Android Studio 向 Agent 开放的不只是文件读取，还包括项目结构、符号解析、构建诊断、Logcat、Compose Preview 和模拟器等能力。

这改变了 Agent 处理代码的上下文范围。它可以看到工程模块和符号关系，通过构建诊断定位编译问题，读取运行日志，也能在模拟器或 Preview 中检查界面。因此，Agent 的工作对象不再局限于几个孤立代码片段，也可以覆盖“修改工程—触发构建—检查诊断—观察运行结果”的一组连续动作。

这并不意味着上下文越多，结果就必然越好。符号解析、构建输出和运行日志也可能包含大量噪声，Agent 仍需要明确任务边界，并让开发者在关键节点确认它调用了哪些能力。

命令行和 Skills 怎样把 Android 知识变成动作？

ACP 解决了接入问题，但要让 Agent 真正完成 Android 开发任务，还需要三部分配合：Android CLI 提供操作入口，官方 Skills 补充专业知识，模型选择决定推理与工具调用能力。

Android CLI 能替开发者完成哪些操作？

Android CLI 把 Android 官方工具、Android Skills 与专业知识带入智能体工作流。资料中明确提到的能力包括终端真机控制、UI 截图和组件树导出。

这些能力改变了 Agent 调试界面的方式。没有真实设备信息时，Agent 往往只能根据代码推测布局；有了截图，它可以检查文字截断、遮挡和间距；有了组件树，它则可以定位具体控件及其层级。CLI 因而承担了“让 Agent 观察和操作真实应用”的接口角色。

不过，CLI 输出仍然只是诊断证据，不是正确性的证明。截图能够显示异常现象，却无法单独解释异常原因；组件树可以说明节点结构，也不代表交互逻辑一定正确。实际使用时仍需要结合日志、构建结果和人工判断。

输入 @ 之后，Agent 多了什么能力？

官方 Android Skills 已进入 IDE 管理器，开发者输入 @ 即可选择。官方称目前提供 30 多个 Skill，覆盖 20 多类 Android 开发问题，其中包括 agp-9-upgrade、android-profiler、r8-analyzer 和 camerax 等示例。

Skill 把特定领域的知识与操作方式提供给模型，其作用不只是增加一段通用提示词。它可以补足模型在新 API、性能规则、安全要求或 Android 最佳实践方面的知识缺口，也可以把复杂任务拆成更稳定的步骤。

以性能分析为例，单纯告诉 Agent“检查内存泄漏”并不够，因为模型可能不了解项目中可用的工具、诊断入口和判断标准。专项 Skill 提供的实际上是完成任务所需的上下文。

选择模型时，为什么不能只看模型名称？

Android Studio 支持开发者选择模型并引入开发环境，接入方式包括自带模型、第三方原生端点、本地推理和多模型路由。官方资料建议结合多模态、推理、工具调用能力以及 Android 专用基准测试进行选择。

这四个维度分别对应不同任务：

• 多模态能力决定模型能否同时理解代码、截图、设计稿和构建输出。
• 推理能力影响跨文件迁移、依赖分析和复杂故障定位的稳定性。
• 工具调用能力决定模型能否有效使用 CLI、构建诊断和 IDE 上下文。
• Android 专用基准则更接近真实任务，而不是通用问答表现。

因此，模型选型不应停留在排行榜名次。对团队而言更重要的是：同一模型能否稳定调用所需工具、输出是否便于审查、失败时能否给出可定位的信息，以及成本是否与任务复杂度匹配。

为什么 XML Views 到 Compose 的迁移适合先试 Skill？

XML Views 到 Jetpack Compose 的迁移涉及组件映射、状态管理、布局表达和交互行为变化。它既需要理解旧工程，也需要掌握 Compose 的组织方式，是典型的专项任务。Android 官方已经将 XML 到 Compose 迁移作为 Skill 的应用场景。

Skill 可以帮助 Agent 理解迁移规则与 Android 最佳实践，减少它凭空生成 Compose 代码的概率。比较合理的用法，是让 Agent 先识别旧组件及其依赖，再分批迁移，并通过编译、预览和 Change Review 检查结果，而不是一次性重写整个界面。

这类任务适合试 Agent，不代表适合完全自动化。迁移是否成功，最终仍取决于业务状态、生命周期、测试覆盖和人工验收。

Agent 写完代码后，开发者怎样确认它真的可用？

生成代码只是开发闭环的一部分。Android Dev Summit 2026 的另一项重要变化，是补齐了审查、基准测试、性能分析与构建优化组成的验证链。

Change Review 为什么是人机协作的关键环节？

Change Review 可以从 Agent Changes、待提交的 Git Diff 甚至历史 Commit 发起审查。它不仅列出代码差异，还能先查找可能存在的问题，再把分散在多个文件中的相关修改组织成 Walkthrough，让开发者按功能关系查看改动。

逐文件查看 Diff 适合检查局部实现，按功能关系组织则更适合回答“这次修改整体改变了什么”。发现问题时，开发者可以继续让 Agent 处理，形成“生成—审查—修正—再审查”的循环。

对团队而言，Walkthrough 还提供了一个可讨论的修改边界。审查重点也不只是语法问题，还包括行为变化和架构影响。

40% 的任务通过率说明了什么？

Android Bench 2.0 已经覆盖跨文件迁移、从设计稿创建 App 等长链路任务。资料所列 10 月 29 日榜单中，Claude Sonnet 5.5（max）配合 Claude Code 在 30 个任务上的通过率为 40%。

这个数字不能被解释为“Agent 只有 40% 的能力”。它只是特定日期、模型和配置下的一个基准快照，而且长链路任务会放大任何环节的错误：一次错误的组件选择、一次遗漏的状态迁移，都可能让整个任务无法通过。

它说明的是，Android 开发中的复杂任务尚不适合无条件自动化。Agent 可以显著缩短探索和修改时间，但任务越长，开发者越需要中间检查点、明确验收条件和可回退的修改范围。

性能与构建工具如何补上验证闭环？

本次更新把 LeakCanary、Firebase Crashlytics 与跨设备堆分析纳入 Android 性能诊断链路，并在构建侧加入 R8 配置分析与声明式 Lightbuild 实验项目。

这组工具分别处理不同阶段的验证问题。LeakCanary 与 Crashlytics 补充运行时诊断信息，跨设备堆分析让开发者可以结合不同设备样本观察问题；R8 配置分析则把注意力引向构建规则本身，帮助团队理解配置与产物之间的联系。声明式 Lightbuild 仍以实验项目形式出现，资料并未给出足以支持全面生产采用的完整细节，因此更适合作为后续方向跟踪。

把这些能力与 Change Review 放在一起，才形成相对完整的闭环：Agent 负责修改，Change Review 检查差异，性能与崩溃工具提供运行证据，构建分析解释构建行为，最终仍由开发者决定是否合并。

Compose 的 MediaQuery API 会怎样改变多设备适配？

多设备适配中，窗口尺寸、屏幕类别、姿态和输入设备往往由不同 API 分别表达，开发者需要在多个判断之间组织布局逻辑。新的 Compose API 开始提供统一获取设备 UI 能力的方式。

过去与现在的适配方式差在哪里？

过去的常见做法，是分别判断窗口大小、输入设备等信息，再为手机、折叠屏和平板编写适配分支。新的 Compose API 可以通过 MediaQuery 获取窗口大小、设备姿态和连接输入设备等 UI 信息，让开发者从一组较统一的能力信号出发组织界面。

变化不在于完全取消尺寸判断，而在于减少重复查询和分散条件。开发者可以先取得当前窗口与设备状态，再决定布局应该如何响应。

折叠屏和大屏为什么更容易复用同一套布局？

MediaQuery 提供了按可用空间调整内容的基础。例如，同一套内容布局可以在手机上显示两列，在折叠屏或更大设备上展示更多列，而不必为每种设备尺寸单独维护一套规则。

对内容型应用而言，这种方式通常比按设备名称分支更容易维护。窗口变化后，布局可以基于实际可用空间重新组织，而不是等待应用识别“这是不是某一款具体设备”。

但“减少尺寸分支”不等于“不需要设备测试”。输入方式、系统栏、分屏、折叠状态变化和厂商差异仍然可能影响最终体验。MediaQuery 解决的是信息获取与布局组织问题，不是把所有设备适配工作自动消除。

ML Kit 与 Gemini Nano 带来的是哪类端侧 AI？

开发侧 Agent 改变的是代码生产、审查和调试过程；应用侧 GenAI 改变的是用户直接使用到的功能。ML Kit 生成式 AI API 与 Gemini Nano 把这种能力带到了 Android 应用运行时。

开发侧 Agent 和应用侧 GenAI 有什么区别？

开发侧 Agent 主要服务于工程师，输出是代码、修改建议、诊断结果和构建反馈；应用侧 GenAI 则可能成为产品功能的一部分，直接出现在用户交互中。

两者的评价方式也不同。开发侧 Agent 的核心问题是修改是否正确、能否通过审查和测试；应用侧 GenAI 则还要回答输出是否稳定、延迟是否可接受、结果是否符合产品预期，以及不同设备上的体验是否一致。

哪些场景更适合先在设备上处理？

ML Kit 生成式 AI API 提供面向生产环境的解决方案，并可与 Gemini Nano 结合。资料指出，端侧处理意味着提示词和数据可以直接在设备上处理，无需发送到服务器，适合探索敏感数据处理、个性化体验和短文本处理等场景。

“无需发送到服务器”改变的是数据处理路径，但不等于可以跳过完整评估。团队仍需要确认设备覆盖、输出质量、失败处理和产品交互。端侧 AI 更适合先从边界明确、输入输出较短、能够在本地验证的任务开始，而不是直接承担复杂的长链路生成任务。

Android 生态为什么不再只围绕手机？

Android 的变化已经超出手机系统功能本身，延伸到应用发现、XR、多设备媒体和健康服务。对开发者而言，需要处理的问题也从“同一个 App 如何适配更多屏幕”，扩展到“同一项能力如何进入更多设备与分发入口”。

应用发现方式发生了什么变化？

Android 开发者峰会介绍了 Ask Play 的智能应用比较功能，以及 Gemini Live 的对话式搜索，目标是帮助用户更智能地发现内容，并提升应用或游戏在应用商店内外的曝光度。

这意味着应用发现正在从关键词搜索和固定页面，向更自然的比较、问答式交互延伸。对开发者而言，曝光不再只取决于商店页面本身，应用的描述信息、功能表达以及与用户问题之间的关联也可能影响被发现的机会。

不过，更好的展示入口不等于获得流量保证。产品描述仍然需要清晰，隐私政策、权限说明和商店规范也不能被忽视。

Android XR 为什么会改变应用形态？

Android XR 支持的首款有线 XR 眼镜，把 Android 带入了新的设备形态。Android 官网列出的 XREAL AURA 是一款由 Android 驱动的有线 XR 眼镜；开发者峰会也强调，应开始把应用扩展到 XR 这一维度。

对现有移动应用来说，XR 并不是简单增加一个横屏布局。空间交互、输入方式、视觉层级和性能约束都会影响设计。短期内，更现实的方向通常是先挑选明确适合空间计算的功能进行验证，而不是把整个手机应用机械地搬进 XR。

多设备与健康服务意味着哪些生态机会？

多设备生态让媒体体验可以跨设备延续，开发者需要考虑内容如何在不同屏幕和设备之间保持一致，而不是只优化手机端。健康服务与 Health Connect 的结合，则为健康和健身应用提供了新的扩展方向。

这两类机会都更依赖具体业务。拥有跨设备媒体需求的产品，需要先处理账户、状态同步和输入差异；健康应用则要围绕 Health Connect 的数据边界设计功能。生态覆盖面在扩大，但投入是否合理，最终仍取决于产品是否真正服务这些场景。

普通开发者应该按什么顺序采用这些更新？

我的建议是把采用过程分成三层：先建立可控制、可审查的 Agent 开发闭环，再根据多设备和端侧处理需求扩展，最后评估 XR、Play 与健康生态。后几类能力同样会放大前期流程中的不稳定因素，因此这个顺序不能颠倒。

哪些能力现在就值得试用？

可以先安装 Android Studio Rabbit 2 | 2026.2.2，从 Settings > Tools > AI > Agents 接入一个 Agent，并使用自己的订阅或 API Key。随后在一个范围可控的模块中，通过 @ 调用官方 Skill，尝试构建诊断、日志分析或专项迁移。

接着再测试 Android CLI 的真机控制、UI 截图和组件树导出，并用 Change Review 检查 Agent Changes 与 Git Diff。第一个任务不宜直接覆盖核心业务，最好具备可快速回退、结果容易人工确认的特点。

这样能先回答三个问题：Agent 是否真正使用了 IDE 上下文，CLI 输出能否帮助定位问题，Change Review 是否能减少人工逐文件检查的成本。

哪些能力应该根据产品条件选择？

多设备产品可以优先验证 MediaQuery 驱动的布局，重点观察折叠、分屏和不同输入方式下的内容密度，而不是只看一张设备截图。

存在敏感数据、个性化或短文本处理需求时，再评估 ML Kit 生成式 AI API 与 Gemini Nano，确认本地处理路径、输出稳定性和设备覆盖。

Play、XR 与健康服务则应按业务相关性投入。应用比较和对话式搜索值得运营与产品团队关注；XR 适合有明确空间交互需求的团队；Health Connect 更适合已经具备健康数据能力的应用，而不是为了生态概念临时接入。

哪些实验能力更适合继续观察？

声明式 Lightbuild 目前更适合持续观察。团队可以跟踪其接口、构建覆盖范围和生产使用反馈，再决定是否扩大试验。R8 配置分析则相对更容易纳入现有构建排查流程，但也应先在可对比的构建任务上验证收益。

实验能力不应因为出现在发布材料中就立即进入关键生产链路。判断标准应是可复现的构建结果、可量化的耗时收益，以及失败时明确的回退路径。

这次 summit 的关键变化，是 Android 官方开发链路开始提供可由 Agent 调用、可由工具验证的接口，并支持人工审查。Android 下一阶段的竞争重点在于 Agent 开发闭环的稳定性和可控性，接入模型的数量只是其中一项。