Google 的 Android 开源项目 AOSP 的提交活跃度，Google 还重视开源吗

Google 的 Android 开源项目 AOSP 的提交活跃度，Google 还重视开源吗

去年底例行公事地跑了一遍 repo sync，扫了眼 platform/manifest 的 commit history，那条曲线平得离谱。不是那种“代码质量高、提交原子化”的干净，而是“这里根本没人干活”的干净。Android 15 开发最火热的那个季度，AOSP 主分支的 frameworks/base、system/core、art 这些核心仓库，在长达数周的时间里只飘着几个翻译文件更新和版本号 bump。要知道，Android 15 可不是小修小补，ART 虚拟机换了新的 GC 实现，通知系统底层重构，隐私沙盒继续往里塞新策略——这些改动哪去了？答案是，它们都在 Google 的内部分支里长成了参天大树，然后带着完整的 merge commit 和一句冷漠的 “Snap for 15.0.0_rX” 一次性空投到 AOSP。

这早就不是什么新发现，但情况正在恶化。Google 的 Android 团队正系统性地把 AOSP 从一个开放协作的工地，改造成一个对外发布的代码归档馆。你我现在去 AOSP 上能看到的，与其说是“正在开发中的 Android”，不如说是 Google 允许你看到的历史快照。

AOSP 主分支的 commit 曲线，平得像停跳的心电图

如果你对 AOSP 的历史还有记忆，应该记得 Android 4.x 到 7.x 那段日子。那时候 platform/manifest 的 master 分支是真正的开发前线，每天几十上百个 commit 往里涌。外部开发者、SoC 厂商的工程师、学术界的贡献者，都能在 master 上看到下一个版本的方向。你想知道 Notification Shade 要怎么改？直接去 frameworks/base/packages/SystemUI 里看实时提交。你想了解 ART 的新优化？art 仓库的 master 分支每天都在迭代。那时候的 AOSP 虽然也很乱，虽然也需要 Google 的内部分支做整合，但至少主干是活的，是一个可以跟着跑的开发目标。

现在呢？Android 15 的绝大部分核心功能在 AOSP 公开之前，已经在 Google 的内部分支里封板了。公开的 AOSP master 分支经常落后于内部开发线数月之久。你看到的不是活代码，是裹尸布。那些真正有技术含量的提交——比如对 WindowManager 的重构、对 PowerManager 的调度策略调整、对 Storage 模块的现代化——几乎不会以“渐进式开发”的形态出现在 AOSP 上。它们以巨大的 merge commit 形式砸下来，附带数千个文件变更，让外部开发者根本无从 review，也无从参与。

这种开发模式的转变，对 AOSP 的生态环境是毁灭性的。因为 master 分支不再可靠，下游的芯片厂商、OEM 和第三方 ROM 维护者失去了跟踪目标。以前大家可以说“我基于 AOSP master 做 bring-up”，现在这句话近乎笑话。AOSP master 可能连启动都成问题，因为它不是给活人用的，是给 CI 机器人用的。

从“开放开发”到“代码投放”：Android 15 的黑箱周期

Android 15（内部代号 Vanilla Ice Cream）的发布过程，把这种“代码投放”模式演绎到了极致。如果你关注过 Google 的 Android Beta 计划，会发现一个诡异的现象：Pixel 用户早在春季就能刷上 Beta 版，体验到完整的新功能，但此时的 AOSP 公开仓库里，Android 15 的相关代码要么残缺不全，要么干脆没有。这意味着，Google 在向公众开放测试的同时，并没有向开发者开放同等进度的源码。

直到 Android 15 的 release tag（比如 android-15.0.0_r1）正式打出，那些代码才像档案解密一样被批量释出。这不是开源协作，这是开源广播。协作的本质是共同参与、共同 review、共同迭代，而广播的本质是我说你听。Google 现在的做法，完美符合后者。

更讽刺的是安全补丁的处理。Google 每月发布 Security Bulletins，修复大量 CVE。但这些补丁往往不是先在 AOSP 公开修复，而是先进入内部分支，然后延迟同步到 AOSP。对于那些试图基于 A