文章图片
文章图片
文章图片
文章图片
今年早些时候 ， 谷歌曾宣布将完全独立开发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开发？【AOSP并未消亡，但谷歌明显扎紧了国产手机厂商的脖子】然而 ， 更重要的问题是 ， 这一决定将对那些构建自定义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可能兼容不了 ， 必须额外调试 ， 等于又多了一道工序 。
在生态和商业层面 ， 中国手机厂商靠定制系统内置广告和应用商店赚取额外收益 ， 比如OPPO应用商店、小米内置广告 ， 随着谷歌限制系统定制深度 ， 广告加载效率可能就受影响 ， 应用分发渠道也可能被压缩 。 而且签署了GMS协议的厂商必须遵守谷歌的兼容性要求 ， 不得随便改系统底层 ， 如果谷歌协议条款逐渐收紧 ， 厂商合规成本就会增加 。
地缘关系也是不得不考虑的因素 ， 万一谷歌将来用代码闭源来卡脖子 ， 依赖Android的厂商可能会面临系统更新断供的风险 ， 这也是逼着他们加快自主系统的布局 。
长远来看 ， 头部厂商其实已经在做准备了 。 现在很多厂商采取双轨制 ， 一边维护现有的Android分支 ， 一边研发自主技术 ， 比如OPPO投资做跨平台编译工具 ， 小米联合展讯开发RISC-V架构 ， 都是为了以后能减少对谷歌的依赖 。 虽然现在调整期厂商会遇到开发成本增加、适配难度变大的问题 ， 但从长期看 ， 这其实加速了整个产业往自主化方向走 ， 以后的核心竞争力可能就看谁家的底层技术更扎实、生态建得更好了 。
