AOSP并未消亡，但谷歌明显扎紧了对国产Android手机厂商的口袋

今年早些时候，谷歌曾宣布将完全独立开发Android操作系统，以简化其开发流程。谷歌将精力集中在一个内部分支上，旨在精简此前分散的工作。这一消息最初在Android开发社区引起了一些关注，但争议很快就平息了。这是因为谷歌此前已主导开发大部分Android系统核心功能，且始终承诺发布源代码，因此开发者们暂时把提起的心放回了肚子里。

然而，谷歌最近的举动再次引发了人们对其可能停止共享新Android版本源代码的担忧。谷歌已声明这些担忧毫无根据，但其他新变化使得自定义Android ROM的发展变得更加困难。这也引起了开发者群体对谷歌逐渐“扎紧口袋”的担忧，尤其是那些长期依赖“魔改”Android来获取广告和App分发收益的三大中国手机厂商（OVM）。

AOSP会消失吗？谷歌表示(暂时)不会

谷歌今年依然兑现承诺，本周发布了Android 16的源代码，允许独立开发者自行编译新操作系统。与往常一样，该源代码已根据宽松的Apache 2.0许可证上传至Android开源项目 (AOSP)。

然而，多位开发者很快注意到Android 16源代码版本中存在一个明显的缺陷：Pixel设备的设备树缺失。谷歌也未能为每台Pixel设备上传新的驱动程序二进制文件，并且发布的内核源代码的提交历史记录被压缩了。由于谷歌多年来一直分享设备树、驱动程序二进制文件和完整的内核源代码提交历史记录，因此新版本中出现这样的缺失令人担忧。

这些遗漏导致有人猜测谷歌正迈出停止AOSP计划的第一步。对此，谷歌副总裁兼Android平台总经理Seang Chau专门现身辟谣。他在一篇帖子中回应了这一猜测，并表示“AOSP不会消失”。

他还确认，省略Pixel设备树是有意为之，并表示“AOSP需要一个灵活、可配置且价格合理的参考目标——独立于任何特定硬件，包括谷歌的硬件。” 谷歌将不再支持在Pixel设备上构建 AOSP，而是支持虚拟Android 设备“Cuttlefish”作为其参考目标。Cuttlefish在PC上运行，允许谷歌和平台开发者测试新的硬件功能。谷歌还将继续支持GSI目标，这些是通用系统映像，几乎可以在任何Android设备上安装。

这种逻辑听起来似乎完全合理。谷歌希望不再使用Pixel作为AOSP的参考设备，并正在为此做出改变。正如Seang Chau所指出的，“AOSP建立在为设备实现、SoC供应商和指令集架构提供开放平台的基础之上。”从这个角度来看Cuttlefish是一个更合适的参考目标，因为它不像Pixel手机那样是高度定制的消费级硬件。然而，Cuttlefish作为一款虚拟设备，无法完全覆盖真实硬件的兼容性测试场景，这也导致依赖实体设备调试的开发者面临挑战。

这些变化如何影响自定义ROM开发？

然而，更重要的问题是，这一决定将对那些构建自定义ROM（AOSP 爱好者分支）的开发者产生影响。LineageOS项目的长期贡献者和审阅者Nolen Johnson表示，为Pixel手机构建这些ROM的过程将变得“痛苦”。

此前，谷歌曾简化了开发者为Pixel设备构建AOSP的流程，但如今这项支持已不复存在。过去，开发者只需“拉取谷歌创建的配置”，添加自定义配置，然后进行构建即可。然而，现在他们需要使用谷歌为Android 15发布的旧设备树，并“盲目地从预先构建的二进制文件中猜测和逆向工程，以确定每个月需要进行哪些更改”。

这是因为，为设备构建完整的Android版本（而不仅仅是GSI）需要设备树。设备树是一组内核配置文件，用于定义硬件布局、外设参数、驱动加载规则及专有文件路径，是内核适配特定硬件的核心配置文件。虽然谷歌之前已经处理了这项工作，但现在开发者必须自行创建设备树，而无法访问必要的专有源代码。

此外，谷歌压缩内核源代码提交历史的决定也阻碍了定制开发。Pixel的内核源代码通常被用作“其他设备获取功能、错误修复和安全补丁的参考点”，但随着内核源代码的提交历史记录被压缩合并，多个增量更新被整合为单一提交，这种做法已不再可行。

虽然从商业意义上来讲，谷歌没有义务发布设备树、提供驱动程序二进制文件或分享完整的内核提交历史记录（事实上，谷歌是少数几家一直这样做的“有良心”的手机制造商之一），但它多年来一直这样做。谷歌这样做的原因是，Pixel被视为AOSP的参考平台，因此开发者需要一种便捷的方法来为其构建应用。

谷歌决定停止将Pixel作为AOSP参考设备，这令人遗憾，因为这等于剥夺了Lineage OS和Graphene OS等为Pixel设备构建Android系统的开发者的权利。这些开发者仍然可以为Pixel设备构建AOSP，但现在会比以前更加困难和痛苦，因为他们需要从头开始构建自己的设备树。这也使得Pixel 的开发难度增大，因为开发者不得不构建自己的设备树、提取二进制文件，并处理在其他设备上压缩的内核源代码提交历史记录。

值得庆幸的是，Pixel仍然非常容易解锁引导加载程序（老刷机用户都懂得，只需启用开发者选项，然后在开发者选项中启用OEM 解锁和USB调试），但这肯定会增加开发人员为获得稳定的自定义ROM体验所需做的工作。

对中国手机厂商影响深远

谷歌调整AOSP开发模式，虽然表面上仅对Lineage OS等定制ROM开发者造成直接困扰，但对于中国手机厂商定制Android系统的影响更为深远，毕竟市面上的头部Android厂商只剩下三星和OVM。

在技术层面，由于缺乏设备树，厂商要自己想办法解决硬件配置的问题，过去谷歌提供的设备树就像硬件说明书，现在只能依靠逆向工程去拆解二进制文件，比如分析芯片参数或者驱动接口，不仅费时还容易出错。

在驱动适配来看，过去谷歌提供的驱动直接能用，将来可能必须向芯片厂商要或者自己开发，中小厂商如果技术储备不够，驱动适配可能就跟不上系统更新，导致硬件功能出问题，比如摄像头优化不到位或者续航异常。

而且，虚拟设备Cuttlefish虽说是参考目标，但它模拟的硬件环境跟真实手机不一样，像5G信号处理、散热测试这些场景，虚拟环境无法测出真实效果，厂商必须额外用实体机做测试，等于进一步增加开发成本。

从开发模式来看，谷歌把核心开发放在内部闭源分支，厂商只能等正式发布后才能拿到源代码，这就导致定制化的节奏被打乱。过去可以跟随谷歌的开发进度同步调整，现在只能被动等，比如小米的定制UI，得等Android 16源代码放出来才能开始改，新功能上线可能就比谷歌原生系统晚两三个月。而且开源社区的协作也变难了，过去厂商遇到底层问题能在AOSP社区找解决方案，现在第三方开发者贡献变少，代码审查又因为提交历史被压缩变得麻烦，中小厂商可能就不敢做太复杂的定制，因为会担心兼容性问题。

虽然谷歌还支持通用系统映像GSI，但厂商的硬件比如高刷屏、多摄系统这些定制化配置，GSI可能兼容不了，必须额外调试，等于又多了一道工序。

在生态和商业层面，中国手机厂商靠定制Android系统内置广告和应用商店赚取额外收益，比如OPPO应用商店、小米内置广告，随着谷歌限制系统定制深度，广告加载效率可能就受影响，应用分发渠道也可能被压缩。而且签署了GMS协议的厂商必须遵守谷歌的兼容性要求，不得随便改系统底层，如果谷歌协议条款逐渐收紧，厂商合规成本就会增加。

地缘关系也是不得不考虑的因素，万一谷歌将来用代码闭源来卡脖子，依赖Android的厂商可能会面临系统更新断供的风险，这也是逼着他们加快自主系统的布局。

长远来看，头部厂商其实已经在做准备了。现在很多厂商采取双轨制，一边维护现有的Android分支，一边研发自主技术，比如OPPO投资做跨平台编译工具，小米联合展讯开发RISC-V架构，都是为了以后能减少对谷歌的依赖。虽然现在调整期厂商会遇到开发成本增加、适配难度变大的问题，但从长期看，这其实加速了整个产业往自主化方向走，以后的核心竞争力可能就看谁家的底层技术更扎实、生态建得更好了。