AOSP代码更新减半，Android 16后第三方ROM将面临哪些挑战？

一直以来，“开放”无疑是 Android 系统的金字招牌，但谷歌过去几年的一系列举措都指向了同一个事实，那就是他们似乎也准备将 Android 打造成类似 iOS 的“围墙花园”。日前，谷歌正式宣布，将 AOSP（安卓开放源代码项目）的代码更新时间从一季度一次调整为半年一次。

这意味着从 2026 年开始，AOSP 源代码将固定在每年的第二和第四季度发布。对此，谷歌公司发言人解释称，这一改变有助于简化开发流程，减少多分支维护的负担，从而提升 Android 代码的稳定性和安全性，并与主干稳定开发模式更好地配合。

消息一出，Android 开发者社区一片哗然。开发者们普遍认为，此举是在进一步缩减第三方开发者对于 Android 生态的影响力，谷歌正试图通过这种方式挤压第三方 ROM 的生存空间。

众所周知，曾经的 MIUI、现在的 LineageOS 等知名三方 ROM，都是基于 AOSP 打造。源代码更新周期拉长，直接意味着第三方 ROM 将无法像过去那样及时获得关键的 Bug 修复和安全更新。

例如，在 Android 16 上曾出现过一个通知异常的 Bug，用户需要清除旧通知才能恢复提示音。这个 Bug 直到去年第三季度才被谷歌修复。按照以往的节奏，第三方 ROM 可以第一时间同步获得补丁；而在新规之下，第三方 ROM 的用户可能将被迫等待长达三个月的时间。

谷歌自家的原生 Android 以及合作伙伴的 One UI、澎湃OS 都能及时查漏补缺，而其他第三方 ROM 就只能在后方苦苦等待。这种局面下，用户自然会“用脚投票”。一如当年用户因为原生 Android 功能简陋而选择功能更丰富的第三方 ROM，如今也可能因为更新滞后而放弃它们。因此，Android 社区普遍吐槽，谷歌这是将“掏空 AOSP”的进程又向前推进了一大步。

事实上，从 Android 6 时代开始，谷歌就一直在不遗余力地缩减 AOSP 的内核功能。诸如搜索、音乐、日历、相机、键盘等一大批核心应用，陆续从 AOSP 转移到了需要授权才能使用的 Google Mobile Services (GMS) 套件中。到了 Android 13，谷歌甚至直接将 AOSP 中的拨号器和短信应用彻底移除。

相比于早期的 Android，如今想要打造一个功能完备的第三方 ROM，难度不降反升。谷歌的意图或许正是希望通过不断增加技术门槛和合规成本，让开发者知难而退，主动放弃维护自己的 ROM。毕竟，碎片化问题一直是 Android 生态的顽疾，它直接导致了用户体验的分裂。大家用的明明都是 Android，但谷歌却无法保证每一个应用都能在所有 Android 设备上正常运行。

从 Android 8 开始，谷歌通过 Project Treble、Project Mainline 等项目，陆续解决了与 OEM 合作伙伴之间的系统兼容性问题。然而，对于数量众多、版本各异的第三方 ROM，谷歌始终“束手无策”。从这个角度来看，不受控的第三方 ROM，恰恰成了谷歌彻底解决 Android 碎片化问题的“最后一道难关”。

偏偏“开放”是 Android 立身的“祖宗之法”，谷歌无法公然禁止开发者基于 AOSP 开发 ROM，因此只能采取这些“旁敲侧击”的手段。当然，谷歌不仅对第三方 ROM 开发者“看不顺眼”，他们其实对所有试图深度介入 Android 核心开发的外部力量都抱有警惕。

此次缩减 AOSP 代码更新周期，其实是去年春季 Android 转向“内部开发”模式的余波。当时，谷歌宣布将放弃对所有人开放的 AOSP 公共开发分支，转而仅维护已获得 GMS 许可的合作伙伴才能访问的内部分支。简而言之，Android 转为内部开发后，其未来的新特性都需要等待谷歌完全开发并整合完毕后才会一次性公开，开发过程中的早期代码将不再对外可见。

当然，谷歌也为外部开发者留下了一个“口子”：Android 会继续接受来自社区的代码贡献，开发者仍可以向 AOSP Gerrit 提交补丁。在 2026 年之前，提交者每三个月就能查询一次自己的代码是否被采纳；而新规实施后，这一查询间隔将延长至半年。

不要小看从三个月到半年的变化，这 100% 的时间成本提升，很可能会导致一大批开发者忘记跟进或失去耐心。谷歌打的算盘，或许正是通过增加这种隐性的时间成本，来“温和地”劝退第三方贡献者。类似的故事，在 Go 语言等由巨头主导的开源生态中已经上演过不止一次。

早期，充满热情的第三方开发者是谷歌宝贵的财富，他们的奇思妙想和代码贡献帮助 Android 度过了艰难的萌芽期。然而，随着 Android 日益成熟并关联着谷歌庞大的商业利益，这些曾经并肩作战的“伙伴”，在某些决策者眼中，或许早已变成了喜欢“指手画脚”的麻烦制造者。毕竟，此前旨在加强隐私保护的“隔离存储沙盒”机制，就曾因遭到第三方开发者的强烈抵制而被迫推迟上线。

对于关注此事的开发者和极客而言，这场围绕 AOSP 开放性的博弈远未结束。未来第三方 ROM 的生存空间将如何演变，或许值得我们持续关注和讨论。欢迎在 云栈社区 分享你的见解。