Android 16 的早期爆料，预测功能列表
Android 16 的早期爆料：Google 真的在听开发者说话吗？
从 Android 15 的"稳定版"闹剧说起
Android 15 的稳定版推送节奏，大概是近几年最让人哭笑不得的一次。Pixel 设备在九月底收到 OTA，结果不到两周，Google 突然暂停了部分机型的 rollout——不是发现什么惊天大 bug，而是某些用户反馈升级后指纹解锁变慢了。这个"变慢"不是不能用，是从 0.3 秒变成 0.8 秒那种级别的感知差异。Google 的应对方式是把整个推送停了，重新发了一版增量补丁。
这件事放在苹果身上几乎不可能发生。iOS 的发布节奏是铁打的，每年九月发布会后一周全球推送，bug 再多也是边推边修。Google 这边倒好，一个指纹延迟能把稳定版撤回，既说明 Pixel 软件团队现在的谨慎程度有点过头，也暴露出 Android 大版本发布在 Google 内部的优先级正在下滑。Android 15 本身没什么革命性功能，Material You 的调色算法微调了一下，隐私沙盒继续拖，最大的卖点大概是"更流畅的动画"——这话说出来我都替他们尴尬。
所以当我看到 Android 16 的早期爆料开始从各种渠道漏出来时，第一反应不是兴奋，是警惕。Google 这几年有个很不好的习惯：把本该属于大版本的功能拆成 Quarterly Platform Releases（QPR）和 Pixel Feature Drops 分批放送，导致每年夏天的 I/O 大会越来越像走过场。Android 16 会不会继续这个套路？爆料里的那些"重磅功能"，有多少能真正跟着明年夏天的正式版一起到来？
爆料源头的可信度排序
目前关于 Android 16 的信息主要来自几个渠道，按可信度排个序的话：
最硬的是 AOSP 主分支的 commit 记录。Google 的代码仓库是公开的，虽然很多功能提交时的描述写得像密码（"Add new system service for XYZ" 这种），但配合文件路径和修改范围，能猜个七八分。比如十月份有几个 commit 在 SystemUI 里加了新的 Toast 动画框架，不是简单的淡入淡出，是带物理回弹的弹簧曲线。这个改动目前被 flag 保护，默认关闭，但代码结构很完整，不像临时实验。
其次是 Android Gerrit 上的 code review。这是 Google 内部工程师审代码的地方，偶尔会有功能描述泄露比 commit 更详细的信息。最近一个引起讨论的是关于"预测性返回动画"的扩展——Android 15 引入了 Predictive Back，但只支持系统级返回手势，应用内的自定义返回还没打通。Gerrit 上有个正在审的 patch 在尝试把 Predictive Back 的 API 暴露给 OnBackPressedDispatcher，让第三方应用也能做那种"手指往回拉、页面跟着变形"的效果。这个 patch 的作者不是普通 contributor，是 Google 的 frameworks 团队的人，所以落地概率很高。
再次是各种"熟悉内情的人士"向 9to5Google、Android Police 这些媒体的爆料。这类信息要打折听，因为爆料人往往只看到自己负责的那一块，容易把局部功能吹成全局变革。比如最近有说法称 Android 16 会"彻底重构通知系统"，但追根溯源，可能只是 NotificationListenerService 的权限模型有调整，离"彻底重构"差得远。
最不靠谱的是 X 上那些靠渲染图涨粉的账号。每年 Android 大版本前都会有人发"基于泄露信息制作的 Android XX 概念设计"，做得越漂亮越不可信。真正的 Android 开发团队 UI 迭代速度很慢，Material Design 3 的规范从 2021 年用到现在，组件库更新都是渐进式的，不可能突然冒出什么颠覆性的视觉语言。
锁屏小组件：迟到三年的"新功能"
爆料里反复出现的一个点是"锁屏小组件回归"。这个功能在 Android 4.2 到 5.0 时代其实存在过，当时叫 Lock Screen Widgets，后来因为安全考量和安全团队的压力，在 Android 5.1 被砍了。现在传要回来，形式可能跟 iOS 的 Live Activities 有点像，但更深地集成到 Android 的 widget 框架里。
我对这个功能的态度很矛盾。从用户需求角度，锁屏看天气、看快递进度、控制音乐播放，确实是高频场景。iOS 16 的 Live Activities 推出来之后，Android 用户 envy 的声音没停过。但 Google 现在才想起来补这个课，时间窗口已经不太对了。国内厂商的定制系统早就自己做了各种锁屏信息卡片，小米的"锁屏右滑进入智能助理"、OPPO 的"乐划锁屏"、甚至三星的 LockStar 模块，都把这块空间占得七七八八。Android 16 即使推出官方 API，第三方应用开发者也要面对一个尴尬问题：我要为 Google 的纯血 Android 用户单独适配一套锁屏小组件，还是继续用厂商提供的 SDK 覆盖更多设备？
更深层的问题是权限边界。当年的 Lock Screen Widgets 被砍，核心原因是任何拿到 BIND_APPWIDGET 权限的应用都能在锁屏显示内容，恶意应用可以借此做钓鱼界面。现在的 Android 权限模型比 2014 年严密得多，但锁屏的特殊性没变——它是用户解锁前唯一能看到的界面，伪造一个 Google Pay 的付款码界面在锁屏显示，技术上是可行的。Google 安全团队这几年越来越保守，我怀疑锁屏小组件的 API 开放程度会极其有限，可能只允许系统应用和极少数白名单应用使用，最后变成又一个"看起来很美、用起来很残"的功能。
桌面模式的真实进展
另一个被频繁提及的是"增强的桌面模式"（Enhanced Desktop Mode）。Android 从 10 开始就有个隐藏的 Desktop Mode，连上显示器可以跑窗口化应用，但这么多年一直是实验性质，flag 藏在开发者选项里，普通用户根本找不到。
爆料说 Android 16 要把这个扶正，做成类似三星 DeX、摩托罗拉 Ready For 那样的正式功能。证据是 AOSP 里 frameworks/base 下面新加了一个 desktopmode 目录，里面在重构窗口管理的逻辑，特别是多显示器场景下的 DisplayArea 层级。还有一个值得注意的 commit 在修改 InputManager 的鼠标指针行为，加了系统级光标加速曲线——这明显是在为桌面场景优化外设体验。
但我对 Google 做桌面模式的执行力极度怀疑。三星 DeX 做了八年，到现在还是小众功能，核心瓶颈不是窗口管理，是应用生态。Android 应用绝大多数没有为键盘鼠标优化，右键菜单、快捷键、拖拽逻辑都是残缺的。Google 自己家的应用在这方面做得也很差，Gmail 的 Android 平板版直到 2023 年才支持拖拽附件，Docs 的键盘快捷键跟网页版完全两套体系。Android 16 即使把桌面模式的系统层打磨得再光滑，没有开发者跟进适配，最后就是个能跑窗口的超大号手机。
而且 Google 内部对这个功能的优先级很成谜。Chrome OS 团队和 Android 团队的关系历来微妙，Chrome OS 现在能跑 Android 应用，Android 又要做桌面模式，两边在"谁才是 Google 的跨平台未来"这个问题上一直在暗暗较劲。2023 年有传闻说 Google 要把 Chrome OS 合并进 Android，后来被否认了，但代码层面的融合确实在发生。Android 16 的桌面模式如果做得太像 Chrome OS，会不会触动内部政治？这个外人很难判断，但历史经验告诉我们，Google 的产品线内耗往往比外部竞争更能杀死一个功能。
AI 集成：Gemini 的系统级渗透
这大概是爆料里最没悬念的部分。Android 15 已经开始了 Gemini 的深度集成，Pixel 设备上长按电源键唤醒 Gemini 替代了原来的 Google Assistant，截图后直接唤起 Gemini 分析内容，这些在 Android 16 肯定会继续深化。
具体的爆料点包括：系统级的"AI 回复"功能，在通知栏直接生成回复建议，不局限于 Gboard 的 Smart Reply；相册的 AI 编辑功能从 Pixel 独占下放到 AOSP；以及一个争议很大的"AI 通话摘要"要变成系统 API，任何拨号应用都能调用。
我对 AI 功能本身没有意见，但 Google 的集成方式让我越来越不舒服。Gemini 在 Android 15 的替代逻辑是很粗暴的——你之前用 Google Assistant 设置的所有智能家居场景、语音训练数据，一键迁移的承诺至今没完全兑现。很多用户发现升级后"Hey Google"唤醒词的行为变了，以前能控制的设备现在 Gemini 说不认识。这种强行切换产品身份的做法，放在任何其他公司都会被骂死，但 Google 仗着 Android 的垄断地位就这么做了。
Android 16 如果继续把 Gemini 往系统更底层塞，可能会触发新的反垄断监管。欧盟的 DMA（数字市场法）已经把 Google 列为"守门人"，强制要求开放默认搜索引擎、应用商店等选择权。AI 助手会不会成为下一个监管焦点？Google 现在把 Gemini 绑在电源键长按这种系统级交互上，竞争对手的 AI 应用根本没有对等的入口。这个雷埋在那儿，迟早要爆。
技术层面还有一个隐患：Gemini Nano 的端侧模型越来越大。Pixel 9 系列的 Gemini Nano 是 3.2B 参数，比 Pixel 8 的 1.8B 涨了近一倍。Android 16 如果要支持更复杂的端侧推理，对设备内存和 NPU 的要求会进一步提高。这可能导致一个尴尬局面：Google 在 I/O 大会上 demo 的 AI 功能，实际只有当年旗舰 Pixel 能跑流畅，中低端设备要么云端 fallback（延迟感人），要么直接灰掉。这种"旗舰专属"的做法跟 Android 的开放生态承诺是矛盾的。
隐私沙盒的拖延症晚期
Android 16 的隐私相关爆料出奇地少，这本身就很说明问题。Privacy Sandbox 是 Google 应对苹果 ATT（App Tracking Transparency）的招牌项目，承诺用 Topics API、Protected Audience API 等替代第三方 Cookie 和设备级标识符。原计划 2024 年全面上线，现在拖到了 2025 年，而且 Google 最近几个月的公开表态越来越软。
九月份有个不太被注意的新闻：Google 把 Chrome 上禁用第三方 Cookie 的计划又推迟了，这次是"2025 年某个时候再评估"。Android 的 Privacy Sandbox 跟 Chrome 是同一套技术架构，Chrome 那边一退，Android 不可能独善其身。AOSP 代码里 adservices 模块的更新频率明显降低了，以前每周好几个 commit，现在有时候半个月没动静。
我的判断是，Android 16 不会把 Privacy Sandbox 作为强制要求推出，最多是继续扩大 beta 范围，给开发者更多"准备时间"。这个"准备时间"已经给了三年，广告技术行业该适应的早适应了，不适应的也在积极找绕过方案。Google 真正怕的不是开发者没准备好，是广告主大规模转向 iOS 或者 TikTok 这类封闭生态。Meta 最近几个季度的广告收入反弹，很大程度上得益于 AI 驱动的上下文广告优化，证明没有设备级追踪也能赚钱。Google 的 Privacy Sandbox 技术路线是对的，但执行层面的优柔寡断正在消耗行业信任。
对普通 Android 用户来说，Privacy Sandbox 的拖延反而有个意外"好处"：那些靠设备指纹追踪的灰色 SDK，还能再苟一段时间。国内应用市场的隐私合规审查越来越严，但"合规"和"实际行为"之间永远有缝隙。Android 16 如果不强制切断 Advertising ID 的可重置性（苹果 ATT 的核心机制），隐私保护就还是隔靴搔痒。
性能与电池：被低估的底层改动
爆料里不太 glamorous 但可能最影响实际体验的是内核和电源管理的改动。Android 16 据说要基于 Linux 6.6 内核，比 Android 15 的 6.1 跨了两个大版本。Linux 6.6 有个重要的调度器改进叫 EEVDF（Earliest Eligible Virtual Deadline First），替代了用了很多年的 CFS（Completely Fair Scheduler）。EEVDF 在理论上能更好地保证交互任务的延迟稳定性，简单说就是减少那种"点击后顿一下才响应"的卡顿。
但内核升级对 Android 的实际影响从来不像数字看起来那么大。Google 的 Generic Kernel Image（GKI）项目把厂商定制内核的空间压缩了很多，但芯片厂商——高通、联发科、三星 Exynos——仍然会在 HAL 层和驱动里做大量修改。一个 Linux 6.6 的新特性，从 AOSP 合入到高通 SM8750（预计 2025 年旗舰平台）的 BSP，再到 OEM 厂商适配到具体机型，中间要经过三四层转手，每一层都可能把特性削掉或者改坏。Android 16 的"内核升级"最后能有多少传递到用户手里，我持保守态度。
电源管理方面，爆料提到一个新的 BatteryService 架构，把电池健康度估算从简单的循环计数改为基于实际化学特性的模型。这个改动如果属实，对延长设备寿命有意义。现在 Android 手机的电池健康度显示普遍不准，有些机型 500 次循环后还显示 95%，实际续航已经崩了。但 Google 做电池管理的记录并不好，Pixel 设备的电池衰减速度在旗舰机里算是偏快的，软件优化能不能弥补硬件选型的问题，要打问号。
开发工具链的隐形变革
最后想聊一个爆料很少涉及、但对开发者影响巨大的领域：构建工具和 API 演进。
Android Gradle Plugin 8.x 系列已经推了很久，但大量项目卡在 7.x 甚至 6.x 升不上去，因为每次 major 升级都伴随一堆 breaking changes。Android 16 的 SDK 可能会把 minSdk 的推荐底线抬到 API 28（Android 9），这意味着如果你的应用还想支持 Android 8.1 及以下，Google Play 可能会给警告或者限制某些功能。这个"软性强制"升级的节奏，Google 这几年玩得很熟练。
更值得关注的是 Jetpack Compose 的地位。Android 15 的 Settings 应用已经全面 Compose 化，Android 16 的系统 UI 组件——通知面板、快速设置、锁屏——据说也在逐步迁移。这对 Compose 的稳定性是个终极考验，以前系统 UI 用 Java/XML 写了十几年，现在换成 Kotlin/Compose，内存泄漏和重组性能的问题会不会在系统级放大？我注意到 AOSP 的 SystemUI 模块最近在频繁修复 Compose 相关的 crash，有些 bug 的描述是"重组时状态丢失导致 NPE"，这种在应用层开发里常见的坑，出现在系统进程里就是直接重启 SystemUI 的灾难。
还有一个被很多人忽略的信号：Android 16 可能会正式废弃 AsyncTask。这个类从 Android 1.5 存在到现在，标记 deprecated 也好几年了，但一直还能用。Google 的废弃策略通常分三步：deprecated -> 编译警告 -> 运行时抛异常 -> 彻底移除。AsyncTask 现在处于第二阶段，Android 16 可能会推到第三阶段。这对老项目维护是个麻烦，国内很多银行、政务类应用，代码库里还大量存在 AsyncTask，升级 targetSdk 的成本不低。
我的预测清单与质疑
综合以上信息，我对 Android 16 的最终形态有几个比较确定的判断，也有几个明确的质疑：
确定会来的：Predictive Back 的完整 API、Gemini 更深度的系统钩子和端侧模型、基于 Linux 6.6 的内核升级、Material You 的调色算法微调（可能叫 Material Expressive 之类的新名字）。这些在代码层都有足够证据，只是具体形态可能调整。
大概率会来但会缩水：锁屏小组件、增强桌面模式。这两个功能的技术债务和生态障碍太多，Google 可能选择有限开放或者 Pixel 独占首发，AOSP 代码里有但其他厂商不一定跟。
大概率继续拖：Privacy Sandbox 的全面强制、通知系统的"彻底重构"。前者是商业策略问题，后者是工程复杂度问题，都不是一个 Android 大版本能解决的。
我想明确质疑的是：Android 大版本本身的定义正在模糊。QPR（Quarterly Platform Release）机制让每年夏天的"大版本"越来越像营销事件，真正的功能通过季度更新分批交付。Android 16 如果继续这个趋势，版本号的仪式感会进一步贬值。对开发者来说，这意味着 targetSdk 的升级节奏被打乱，你不得不更频繁地适配行为变更，而不是一年集中处理一次。
Google 有必要想清楚：Android 的竞争力到底在哪里？是每年 I/O 大会上 demo 几个 AI 功能，还是让十亿级设备的日常体验更稳定、更流畅、更安全？从 Android 15 的表现来看，Google 的重心明显偏向前者。Android 16 的爆料列表里，AI 相关的篇幅占了至少一半，而基础性能、电池寿命、应用启动速度这些"无聊"但核心的指标，几乎没有人讨论。
这不是 Google 一家的问题，整个行业的注意力都在往 AI 倾斜。但 Android 的特殊性在于，它是一个承载全球数十亿设备的底层平台，不是某个可以频繁 pivot 的互联网产品。当 Google 把越来越多的 engineering resource 投到 Gemini 的集成和 demo 效果上，谁来修那个存在了三个大版本的 RecyclerView 预加载 bug？谁来优化低端设备的编译耗时？这些不 sexy 的工作，才是 Android 生态健康的根基。
Android 16 最终会怎样，明年夏天的 I/O 大会和秋季的正式版会给出答案。但在那之前，我想留一个问题：如果 Google 继续把 Android 当作 Gemini 的载体来运营，而不是一个独立的、为所有开发者和用户负责的平台，五年后我们还会像现在这样关心它的版本号吗？