8 月 19 日，以安全加固闻名的 Android 衍生系统 GrapheneOS 在社交平台发文，指出谷歌正在用 Google Drive 网盘链接，取代部分 Android 源代码原有的 Git tag 发布方式。消息随后被搬运到 Hacker News 讨论。对普通用户而言，这则新闻几乎没有存在感；但对 ROM 开发者、安全研究者乃至整个 Android 生态，它可能是「开源 Android」叙事里又一根被悄悄抽走的支柱。
发生了什么
据 GrapheneOS 的说法，AOSP 部分源码已不再以携带完整历史的 Git 仓库与 tag 形式提供，而是改为网盘压缩包下载。谷歌并未就此发布正式公告，变化是在下游项目实际拉取代码时被发现的。
值得注意的是，这不是孤例，而是一条持续一年多的轨迹：
- 2025 年 4 月起，谷歌大幅限制 AOSP Gerrit 的外部贡献，大量组件的代码评审转入内部进行；
- 随后谷歌确认，自 Android 16 起，主要版本先在私有分支开发，发布时才放出源码，季度更新（QPR）也不例外；
- 如今，连「发布源码」的形态本身也开始降级：从可追溯的 Git 历史，退化为一次性的源码快照。
谷歌给出的理由是简化流程、加快发布节奏，避免同时维护内外两套分支。从工程效率看，这套说辞并非全无道理——只是代价不由谷歌承担。
失去 Git 历史，失去的不只是便利
有人会觉得「反正源码还是给了，换个格式而已」。但对下游生态来说，差别是本质性的：
安全研究变得困难。 追踪某个安全补丁何时合入、回溯到哪些分支、是否遗漏了变体，靠的是 commit 粒度的历史。快照只剩下「结果」，整个「过程」消失了。
下游维护成本陡增。 GrapheneOS、LineageOS、CalyxOS 这类项目需要持续跟进上游变更；从压缩包起步，意味着每次更新都要做整包比对，而非增量合并。
供应链可信度被削弱。 Git 的签名 tag 提供可验证的历史链条；而一个网盘链接的哈希、限流、可用性乃至是否需要登录，全部取决于谷歌自家服务——这恰好是「开源」最不该有的属性。
生态的抵触早有先声。据此前媒体报道，三星等厂商对谷歌转向内部开发颇有微词，设备商同样依赖公开代码提前适配新版本；连谷歌内部工程师也被曝有过抱怨。换句话说，这项「提效」几乎得罪了开源生态的各方。
「源码可用」与「开源开发」的距离
AOSP 采用 Apache 2.0 等许可证，义务止于「发布时提供源码」，并不要求开放开发过程。就许可证层面而言，谷歌无可指摘；社区真正不满的，是「开源」一词的语义正在被悄悄改写，从一种协作方式，退化为一种分发格式。
回望历史，Android 选择开源路线，是为了在 iOS 面前迅速聚拢厂商与开发者。如今 Android 已坐稳全球智能手机七成以上份额，谷歌身陷多起反垄断诉讼，「开放」的战略使命基本完成，维护它的边际收益却越来越低。开源社区长期区分 "open source" 与 "source available"，而 AOSP 正肉眼可见地从前者滑向后者。
对国内开发者与厂商而言，这同样不是旁观者的故事。国产 ROM、终端厂商以及无数依赖 AOSP 公开仓库跟踪安全补丁的团队，维护成本都会随「快照化」上升。
简短点评
开源从来不只是许可证文本，更是一种让第三方能够审查、跟随、参与的协作姿态。当「开放」从战略资产变成运营负担，平台的选择往往可以预期，Cricut 的云端锁死与 AOSP 的网盘快照，本质上是同一道选择题：控制权要不要留给用户与生态。
对依赖 AOSP 的团队，务实的应对是尽早建立自己的代码镜像与补丁追踪机制，不要把上游的「善意」当作架构层面的假设。而对更大的行业，这是又一次提醒：把基础设施押在一家公司的开放承诺上，风险永远不会写在 release notes 里。