安卓突然终止「开源」，开发者遭背叛？社区炸锅了

新智元报道

编辑：定慧 犀牛

【新智元导读】谷歌将改变一直以来对Android开源项目（AOSP）的公开开发模式，转而在私有环境中进行。但这并非意味着Android彻底闭源。对于普通用户而言不会有什么影响，但却让科技爱好者失去了一扇「窥视」安卓内部的窗口。

据Android Authority报道，谷歌已经向其确认，谷歌将很快在私有环境中开发Android开源项目（AOSP，Android Open Source Project），但依然会开源代码。

网站地址：https://www.android.com/

很多小伙伴可能会慌了，我的安卓手机不能用了？

目前来看，谷歌私下开发AOSP项目还不至于到「天塌下来」的地步，普通手机用户更是几乎感觉不到什么变化。

大部分主流手机厂商（比如小米、vivo、三星等）早就跟谷歌签好了各种合作伙伴协议。

只要这些协议还在，厂商们就还能照常拿到最新的Android源代码，通过Google自家的认证，正常预装Google Play、Gmail这些服务和应用。

谷歌对安卓系统的支持也不会断。

一句话，还是老样子。

那么问题来了，谷歌到底做了什么？

这就要从谷歌的安卓开源项目（AOSP）说起了。

什么是Android Open Source Project（AOSP）？

AOSP简单来说，就是谷歌给所有Android设备提供了一个「毛坯房」——操作系统的基本框架和核心部件。

任何开发者都可以免费下载它的代码，随意改动、分发，然后打造自己的定制系统。

比如小米HyperOS、vivo OriginOS都是在AOSP基础上搭建起来的。

网站地址：https://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，安卓对于谷歌已不再那么重要。

参考资料：

https://arstechnica.com/gadgets/2025/03/google-makes-android-development-private-will-continue-open-source-releases/

https://www.androidauthority.com/google-android-development-aosp-3538503/