【新智元导读】谷歌将改变一直以来对 Android 开源项目（AOSP）的公开开发模式，转而在私有环境中进行。但这并非意味着 Android 彻底闭源。对于普通用户而言不会有什么影响，但却让科技爱好者失去了一扇「窥视」安卓内部的窗口。
据 Android Authority 报道，谷歌已经向其确认，谷歌将很快在私有环境中开发 Android 开源项目（AOSP，Android Open Source Project），但依然会开源代码。
网站地址：www.android.com/
很多小伙伴可能会慌了，我的安卓手机不能用了？
目前来看，谷歌私下开发 AOSP 项目还不至于到「天塌下来」的地步，普通手机用户更是几乎感觉不到什么变化。
大部分主流手机厂商（比如小米、vivo、三星等）早就跟谷歌签好了各种合作伙伴协议。
只要这些协议还在，厂商们就还能照常拿到最新的 Android 源代码，通过 Google 自家的认证，正常预装 Google Play、Gmail 这些服务和应用。
谷歌对安卓系统的支持也不会断。
一句话，还是老样子。
那么问题来了，谷歌到底做了什么？
这就要从谷歌的安卓开源项目（AOSP）说起了。
什么是 Android Open Source Project（AOSP）？
AOSP 简单来说，就是谷歌给所有 Android 设备提供了一个「毛坯房」------操作系统的基本框架和核心部件。
任何开发者都可以免费下载它的代码，随意改动、分发，然后打造自己的定制系统。
比如小米 HyperOS、vivo OriginOS 都是在 AOSP 基础上搭建起来的。
网站地址：source.android.com/?hl=zh-cn
而 Android 系统本身是跑在 Linux 内核上，这个内核用的是 GPL 许可证，规则挺严格。
简单说就是，只要使用采用了 GPL 许可证的代码，你就得开源，体现「要玩就一起玩」的精神。
但 Google 为了让 Android 既开源又能赚钱，玩了个聪明设计：底层 Linux 内核老实按 GPL 开源，但中间 AOSP 大部分代码却用宽松的 Apache 2.0 许可证。
这样厂商既能自由改动 Android，不用全盘公开，还能加自己专有的东西，既开放又灵活。
具体来说，Linux 内核和模块还得开源，但到了用户空间的应用就不受 GPL 限制，想闭源就闭源。
结果就是，AOSP 底层 GPL 开源，中层 Apache 宽松开源，上层应用随开发者意愿，想怎么玩就怎么玩。
谷歌的这点小聪明那是相当的成功。
回想将近二十年前，智能手机刚起步那会儿，苹果发布了 iPhone。
谷歌也想在移动市场分一杯羹，于是决定推出 Android。
这不光帮助谷歌赚了个技术开放的好名声，还把一大堆厂商和用户从塞班、诺基亚、Windows Mobile、黑莓手里抢了过来。
真是神来之笔。
Android 开源这步棋，绝对是谷歌今天能占据移动操作系统市场七成以上份额的最大功臣。
市场是拿到了，代价是 AOSP 软件的维护是要做的。
问题是，随着手机的功能越来越多，这种维护工作的代价也越来越大。
终于，谷歌忍不了了。
代码同步难，谷歌决定「关起门」来开发，但依然开源代码
写过代码的都知道相比写代码，「合并代码」反而是最令人头疼的问题。
2007 年，谷歌开放了安卓的核心代码，这步棋让谷歌摘取了移动互联网时代最大的果实。
但是也导致安卓这个项目有了两个「主分支」。
一个分支就是公共的 AOSP 分支，这个分支对任何人都开放，大家所说的「安卓是开源」就是指这个分支。
一些附属功能，比如蓝牙功能，仍然在 AOSP 分支中公开开发，你可以在开源的 Android Code Search 中搜索到相关源代码。
然而，AOSP 公共分支并不包含谷歌专有的应用和服务，比如 Google Play 商店、Gmail、Google Maps 等。
AOSP 虽然没有谷歌自己的服务，但是仍然可以编译为一个完整的可用操作系统。
许多设备制造商基于 AOSP 开发自己的操作系统，包括：
-
三星：开发了 One UI。
-
小米：开发了 MIUI。
-
OPPO：开发了 ColorOS。
-
华为：开发了早期的 EMUI。
-
一加：开发了 OxygenOS。
另一个分支则是完全的闭源开发，可以看做谷歌自己的安卓「亲儿子」。
这个分支仅限于拥有谷歌移动服务（GMS）许可协议的公司使用，以上类似三星 One UI 这种 Android 系统也可以使用，只要谷歌给予授权。
目前来看，大多数组件，包括核心 Android 操作系统框架，都是在 Google 的内部分支中私下开发的。
两个分支导致一个很大问题，就是内部分支的开发进度领先于公开的 AOSP，导致两个分支差异很大。
这种差异逼得谷歌必须花费时间和精力在公共 AOSP 分支与其内部分支之间合并补丁上。
这就到了程序员「喜闻乐见」的环节，由于分支差异很大，合并冲突经常出现。
以这个启用导航栏和键盘屏幕放大功能的补丁为例，该补丁引入了新的辅助功能设置，该设置被放置在辅助功能设置列表的末尾。
这会导致合并冲突，因为 AOSP 与谷歌内部分支之间的列表长度不同（图中变量 accessibility_magnify_nav_and_ime 设置为 58 和 59 冲突）。
虽然针对此特定问题的修复很简单，但当其他许多 AOSP 补丁集成到谷歌的内部分支时，都会触发类似的合并冲突。
另一个例子是，开发 Android 的新仅解锁存储区域 API 需要一位 Google 工程师从内部分支中挑选一个补丁到 AOSP 以解决合并冲突。
这是因为虽然 API 是在 AOSP 中开发的，但包含新 Android 构建标志的文件是在内部开发的。
因此，必须在内部提交一个更新构建标志文件的补丁，然后应用到 AOSP。
也许这些冲突单独看都不难处理，但是架不住可能会有无数这样「合并冲突」的例子。
「累觉不爱」，也许这就是谷歌放弃当前双管齐下的 Android 开发策略，转而将所有开发工作内部化的原因。
这对我们意味着什么？
这一决策整体来说，并不意味着 Android 正在变成「闭源」。
谷歌只是想把「开发过程」藏起来，依然会继续发布源代码。
最大的区别在于，AOSP 公共分支存在时，对于 Android 爱好者和科技行业记者来说，这是一个能够「窥探」Android 最新动向的窗口。
现在这个「窗口」要被谷歌关上了，这可能会让这些科技极客们感到沮丧，因为这减少了他们对 Google 开发工作的洞察力。
对于开发者，这会让他们更难跟上新的 Android 平台变化，因为他们将无法再跟踪 AOSP 中的变化。
比如外国的一个记者在 AOSP 中发现了某些代码变更，然后提前数月就预测了 Pixel 的网络摄像头功能，他还利用 AOSP 中的线索推断出 Android 16 的提前发布日期。
而对于大多数的我们，甚至包括安卓应用开发者，可以说毫无影响。
事实上，从逻辑的角度上，谷歌大概率就是觉得维护代码的成本过高，不论是从 AOSP 合并到内部版本，还是将内部版本的更新带给 AOSP 公共分支，这些工作都需要工程师完成。
可以说这些处理冲突的工作过于「低端」，对于谷歌的工程师来说，耗时耗力而且毫无意义。
但是 AOSP 某种意义上已经可以看做是谷歌在开源生态和程序员心目中的「投名状」。
作为以「不作恶」为公司理念的谷歌，安卓开源这步棋被认为是谷歌最成功的一次战略决策之一。
在极客们看来，这次决策类似于谷歌自己推倒了过去十几年树立起来的「精神丰碑」。
当然，从谷歌自己的角度看来，选择将工作整合在一个内部分支下，同时简化操作系统开发和源代码发布，是可以理解的。
毕竟 AOSP 对 Google 的商业价值，跟当年比起来，已经完全不是一个量级了。
从最近谷歌对 Gemini 以及 Gemma 的疯狂更新来看，AI 才是其工作的重点。
其实所有人都知道，相比于 Gemini，安卓对于谷歌已不再那么重要。
参考资料：