Android 17 最值得盯的，不是又加了几个系统功能，而是 Google 给 Android 换了一个方向词：从 operating system 走向 intelligence system。

这句话不能当成已经落地的 AI 操作系统。Gemini 调用应用能力还在 private preview。可路线已经摆出来了：Android 不只想运行 App，还想调度 App、组合 App，让 AI 代理替用户完成一段工作流。

Android 17 已经向多数受支持 Pixel 设备发布，AOSP 源码也开放了。开发者现在要看的，不是“能不能晚点适配”，而是 Google 正在把哪些旧自由收回去。

Android 17 先看三条硬变化

变化Android 17 做了什么影响谁
AI 调用应用AppFunctions 让应用把内部能力暴露出来，供 Android MCP 和 AI 代理发现、执行；Gemini 集成仍是 private preview做工具、内容、交易、效率类 App 的团队，要考虑哪些能力能被代理调用
大屏强制适配target API 37 起，大屏设备上系统会忽略方向锁定、不可调整窗口、宽高比限制等旧规则；游戏豁免平板、折叠屏、桌面模式应用，不能继续只按竖屏手机写
Compose-first新 Android API、库、工具和开发指导转向 Jetpack Compose；View、Fragments、RecyclerView、ViewPager 进入维护模式新项目会更自然地走 Compose，老项目要重新评估迁移节奏

AppFunctions 是最像“未来接口”的部分。

开发者可以把创建笔记、下单、查状态这类能力，用 Kotlin 注解和文档描述暴露出来。AI 代理在用户授权语境下，理论上能发现这些能力，并执行一串任务。

但边界要说清。Gemini 集成仍在 private preview。现在不是“AI 已经接管 Android”，而是 Google 先把接口铺下去，等应用把能力结构化交出来。

大屏这条更硬。

从 Android 17 API level 37 开始，在 sw > 600dp 的大屏设备上，系统会忽略 screenOrientation、setRequestedOrientation()、resizeableActivity=false，以及 minAspectRatio/maxAspectRatio 这类旧限制。手机场景不是一刀切。游戏也暂时豁免。

App Bubbles、Bubble Bar、交互式 PiP、Continue On，也都在推同一个结果：应用要能在浮窗、任务栏、跨设备接续、桌面窗口里正常工作。

这会直接打到 UI、状态管理和性能策略。过去很多 App 默认“全屏、竖屏、单窗口”。Android 17 开始，这套偷懒空间变小了。

Google 要把 App 从入口改成零件

我更在意的是，Android 17 把三件事绑到了一起：AI 代理、大屏桌面化、Compose-first。

AI 代理需要应用交出结构化能力。大屏生态需要应用放弃对窗口、方向、比例的过度控制。Compose-first 则把开发者推向 Google 更容易承载新能力的 UI 栈。

这是一套平台规则，不是一串功能清单。

过去 Android 的自由，很大一部分是开发者的自由。你可以锁方向，可以写死比例，可以依赖 Activity 重建，可以长期守着 View 体系。

代价也很清楚：生态碎，平板体验差，桌面模式像拼装。很多应用到了横屏和分屏场景，立刻露馅。

Google 现在的答案很直接：设备形态变多了，AI 要调度应用了，平台不能继续让每个 App 自成一国。

这个判断有现实基础。大屏 Android 设备规模已经够大，折叠屏、平板、桌面模式、车载、XR 都在逼 Android 离开“6 英寸竖屏手机”的舒适区。如果应用还只按手机壳写，硬件再多也撑不起生态。

这有点像早期 PC 平台从 DOS 程序走向图形界面规范。软件还能各写各的，但平台会慢慢告诉你：想进主流入口，就得按新规矩来。

不完全一样。Android 还要兼容海量旧应用，也不能一夜之间切断 View 体系。但方向类似：平台要把散落的应用，压进更可编排、更可管理的形态。

“天下熙熙，皆为利来。”放到平台生态里尤其准。

Google 给开发者的是新入口：AI 代理、大屏用户、桌面窗口、跨设备接续。Google 收回的是规则解释权：你怎么暴露能力，怎么写 UI，怎么适配窗口，怎么控制内存。

真正的账，落在开发团队身上

View 没有被废弃。Fragments、RecyclerView、ViewPager 也不是明天不能用。

但“维护模式”已经够重。只保留关键 bug 修复，不再承载新功能。这对老项目不是小事。

很多团队不是不想迁移，而是不敢轻易动。大型商业 App 的 UI 栈，往往和埋点、广告、支付、风控、无障碍、AB 实验绑在一起。Compose-first 在新项目里顺，在十年老项目里就是手术。

Android 17 还会按设备 RAM 执行更严格的应用内存限制，超限进程可能被终止。重媒体应用、常驻服务、大型电商和内容流 App，都要重新看内存峰值和后台策略。

开发团队接下来最现实的动作，不是立刻全量重写。

更可行的是三件事：

  • 新功能优先用 Compose，旧 View 页面按业务风险分批迁移。
  • 针对 target API 37，提前审查方向锁定、窗口尺寸、宽高比和分屏表现。
  • 把可被 AI 调用的核心能力列出来，但先控制边界，不要把敏感交易链路裸奔给代理。

做平板、折叠屏和企业设备采购的人，也要换个看法。

过去买 Android 大屏设备，最怕应用只是“放大版手机界面”。Android 17 至少说明 Google 准备从系统层面逼应用适配。采购可以更积极评估 Android 大屏，但不该只看硬件参数，要看关键业务 App 是否跟上 target API 37 和多窗口规则。

最该观察的变量也很具体。

Gemini 的 AppFunctions 集成什么时候从 private preview 扩大，是第一条。头部应用愿不愿意把创建、查询、交易、内容生成等能力暴露出来，是第二条。Google 后续如何把 target API 37 和大屏规范推到生态执行层，是第三条。

如果这三条都推进，Android 17 就不是一次普通版本更新。它会把应用从“用户打开的界面”，逐步改成“系统和代理可调用的能力模块”。

开发者得到新入口，也失去一部分随意性。

门开了，门槛也抬高了。