出于新闻报道和纯兴趣讨论目的，爱范儿对知名科技公司的战略做过各式各样的「沙盘推演」，设想了许多场景。 但没想到，最不可能的一种情况，居然正在 Google 身上发生。
Google 已经决定 停止 Android 开源 项目 （ AOSP ） 。
AOSP（Android Open Source Project） 是 Google 主导的开源项目，为所有 Android 设备操作系统提供基础框架和核心组件。它相当于一个「毛坯房」，开发者可自由下载、修改和分发其代码，并基于此构建定制化系统，包括 Xiaomi HyperOS、vivo OriginOS、OPPO 的 ColorOS、甚至 Pixel 手机的 Android 系统，都是基于 AOSP 构建的。
Google 对 Android 的维护分为两条路径：公开的 AOSP 分支面向全球开发者开放，包含纯净的开源代码，不涉及任何 Google 专有服务。任何厂商或个人均可基于此分支开发系统。而内部闭源分支仅供签署了 GMS（Google Mobile Services） 协议的厂商使用。
具体来说，Google 将不再维护目前 AOSP 的公开分支，逐渐关闭相关的的支持性资源，并可能停止更新有法定开源义务（GPL 等协议的代码）外的组件的源代码。
海外媒体 Android Authority 最先报道了这一情况，Google 也确认了此事。
从下周开始，所有的 Android 开发工作将仅在 Google 的内部分支进行。在一段时间后，外部分支可能将不再公开甚至彻底关闭。并且，AOSP 的持续集成/交付 (CI/CD) 工具和环境也可能关闭，甚至 Android Gerrit (https://android-review.googlesource.com/) 也可能会关闭。从今往后，只有 Google 内部的员工能够访问 AOSP 的内部分支，或是提交代码。Android 的开发过程将不再透明。
从高维度来看，Google 将逐步缩减 AOSP 所包含的内容，直至 AOSP 作为开源项目，以及作为一种概念，都不复存在。
以史为鉴，OpenSolaris 项目（也就是 Solaris 操作系统对应的开源项目）在 Oracle 在收购 Sun，宣布对 OpenSolaris「延迟开源」后，直到 Solaris 开发部门解散为止，都没有以 CDDL 许可证开放过半句代码。
谁也不知道，Google 对 Android Authority 承诺的「继续开源，只是推迟」，是不是只是一句空话——毕竟无限期的推迟，也是一种推迟。
根据爱范儿的了解，Android 闭源的总体思路是最终只保留 GPL 强传染许可证要求开源的部分，主要是 Linux 内核态驱动和补丁。其他中层、上层等之前采用 Apache 等宽松开源许可证的部分，最终会闭源；未来的 Android 版本发布后也不再对外公开发布、更新源代码。
此事的决策层级在 Google 高层管理者级别。据信他们做出此决定的时间不晚于 2025 年初。整个策略的执行将会在一个更长的期限内完成，至少持续数年，直到 AOSP 彻底失去意义。
Google 此举的真实动机尚不明确，但根据爱范儿的分析和了解，主要是为了节约开支和增加收入：
AOSP 在不同的维度上（比如版本号、发布进度等）有着多条代码流水线和大量的分支。再考虑到项目的上下游代码、多公司之间的协作，进一步复杂化，维护管理起来非常困难，产生大量的计算资源和工时成本。Google 可能希望节约这些成本。考虑到 2025 年初 Android 部门已经向所有员工提供了「自愿离职」的选项，削减开支的思维逻辑不难理解。除此之外，签署了合作伙伴协议的厂家也有义务捆绑 Google 服务，为 Google 提高广告收入，变相提高了公司的整体收入。
好在目前来看，闭源 AOSP 对业界的直接影响并非灾难性，对终端手机用户直观影响也微乎其微。
绝大多数主流手机厂商早就和 Google 签订了各种授权合作伙伴协议。在现有协议安排下的厂商，仍然可以得到和使用最新 Android 源代码，获得 Google GMS 认证，正常预装 Google Play、Gmail 等服务和应用，得到 Google 的支持。一切生意照旧。
真正的影响更多不会直接展现，而是会在更长的时间里从侧面体现。后文会详细解读。
AOSP，不存在了？
如下几点需要澄清：
- 因为大部分 AOSP 代码通过 Apache 2.0 许可证发行，任何人都可以 fork 一份。其他代码服务平台上也有各种 AOSP 的镜像，例如 GitHub 和国内的 Android 社区。Google 无权要求其它「非官方」 AOSP 代码库下线。已经开源的，无法被撤销开源。
- 也就是说，只要能从其他非官方渠道下载，人们仍然可以使用 Google 最后更新的 AOSP 代码，也可以按照自己的需要对其进行修改。原则上如果你有足够多厉害的开发者，也可以把之前的 AOSP 变成自己的系统，去维护和更新。
Android/AOSP 从来不是一个真正的开源项目，社区里的原教旨主义者也一直对其颇有微词。
前文提到，Android 目前运行于 Linux 内核上，后者是 GPL 许可证开源的。GPL 是一个强传染性的许可证，要求所有衍生工作都必须按照 GPL 许可证同样开源，从而贯彻无限开源、扩大社区的精神。
而当年 Google 为了构建 Android 商业生态，创建了平衡开源与商业需求的许可模型。Google 将 Android 平台分为几个部分：底层的 Linux 内核部分保留 GPL v2 许可证（按照要求），而 AOSP 的大部分代码则采用了更为宽松的 Apache 2.0 许可证。这种许可结构使设备制造商能够修改和定制 Android 而不必开源所有修改，同时允许企业在 Android 平台上构建专有应用和服务。Google 自己的专有服务 GMS (Google Mobile Services) 则与 AOSP 分开，并采用不同的许可条款。这种混合方法创建了一个既保持开放性又为生态系统提供商业灵活性的模型。
具体来说，Linux 内核基于 GPL 许可证，虽然 kernel module 需要依据 GPL 强制开源，然而 userspace 应用并不受 GPL 传染性的影响，因此无需开源。部分 userspace 应用程序也与传统的 Linux 发行版不同，例如使用 bionic libc 替代 glibc，使用 toybox 替代 busybox 等。此外，Google 还使用了「硬件抽象层」(HAL)，允许厂商将不想公开的商业机密资料，比如一些特定的专有功能对应的背后代码和逻辑，存放在这一层上面，即提供了一套 stable ABI（应用二进制界面），使得厂商可以独立于 Android 框架层更新他们的专有代码。
当然 Linux 基金会对 Google 这种违背开源精神的操作方法很不爽，一度将 AOSP 从 Linux 开源项目中除名。
结果就是，AOSP 底层部分按照 GPL 开源的，大量中层按照 Apache 宽松开源（部分闭源），在此基础上的应用就可以自行按照开发者意愿和商业目的选择各自的开闭源属性了。
Google 自己也是这样做的。事实上，自从 2013 年的 Android 4.4 KitKat 之后，所有的 Android 版本都不再完全开源。Google 为 Android 系统开发的一部分驱动、UI，以及应用层的大量大量核心产品和服务，也就是人们熟知的 GMS 套件，都是闭源的。
AOSP 存在着，但它并不是完整的 Android。这也是为什么很多系统开发者都会强调「原生 Android」（指 Google Nexus/Pixel 的操作系统）不等于 AOSP。
尽管 AOSP 是个开源项目，Google 也不常合并第三方提交的合并请求（合并 AOSP 代码需要 Google 员工的批准，而不少 PR 就死在了 Gerrit Review 里）。这也是不少开发者认为 AOSP 和典型开源项目之间的最大区别。让参与者难以在 AOSP 里获得真正的参与感。
在 AOSP 项目的官网上，Google 写了这样一段「治理理念」：
Google 领导 AOSP，负责维护和进一步开发 Android。尽管 Android 由多个子项目组成，但 AOSP 是严格的项目管理。Google 将 Android 视为一个单一、整体的软件产品，而不是一个发行版、规范或可更换部件的集合，并对其进行管理。Google 的意图是让设备制造商将安卓移植到设备上；他们并不实施规范或策划发行版。
这段话已经把 Google 的意图描述的够清楚了。如果 AOSP 是一头干活的驴，那么卸磨杀驴的时候已到。
Android 闭源，将会带来怎样的影响？
主要结论：主流手机品牌和它们的用户不需要担心。
首先让我们重温一下Google 和 Android OEM 之间的协议关系：
- AOSP，任何厂商都可以使用 AOSP 进行开发，不需要获得Google 的同意；
- Android 兼容性承诺协议 ACC、移动应用分发协议 MADA、企业设备补充协议 EDLA 等，不一而足。通过协议，Google 和 OEM 之间建立商业约束。签订了 ACC 协议的 OEM 通过 AOSP 开发的操作系统，才能够称之为 Android 操作系统，获得 Android 商标使用权等权益。
- Google 移动服务 GMS，包括Google 服务核心、账号体系等后台功能，以及前台的 Google Play 商城、YouTube、Gmail、Calendar 等应用。公司签署了上述协议，并且手机型号通过了Google 兼容性测试，才可以预装 GMS。
ACC、MADA/EDLA 等协议的组合，确保了Google 对 Android 操作系统有着大体上的绝对控制。
包括小米、vivo、OPPO、三星等在内的当今绝大多数 Android 手机品牌，和Google 都签订了协议。没有意外的话，Google 应该已经联系它们进行安抚，并且确保未来的合作照常进行了。
在过去有相当一部分设备和芯片厂商，它们利用 AOSP 开发产品，却不从 Google 获得 Android 设备认证，设备不需要预装 GMS 全家桶，也能够避开 Google 的认证要求。
非认证 Android 设备五花八门，数以十亿甚至百亿计。通过这次闭源 AOSP，Google 有可能引诱非认证设备厂商向自己低头，签订前面提到的各种协议。
一种极有可能出现的情况是，基于 AOSP 开发的智慧座舱系统，可能代码也不会再无偿提供给全世界的厂商了。除非车企和 Google 签订协议，它们将无法得到最新的代码。当然，车企也可以继续使用已经开源的旧系统开发。
这不是已经发生的事实，只是一种可能性。Google 这次闭源 Android，不排除有一个小的动机就是试图夺回非认证设备市场，或者至少能够从中分一杯羹。这个大市场，虽然是设备厂商自己打下的，但如果没有 AOSP 确实也不会是今天的样子。
顺着这个角度，非认证 Android 设备消费者可能就会受到影响了，当然同样不会很明显。影响主要来自财务方面：OEM 想继续预装 Android 操作系统，就必须要服从 Google 对设备的管理和要求。这个成本当然会被转嫁给消费者，导致支付更高的价格。除此之外，消费者也只能使用 Google Play 等渠道下载应用，第三方应用市场（例如 F-Droid）等的生存空间也变得更少，Google 也可以向所有的应用内支付收一笔费用。
部分厂商可能不愿意屈从 Google，产品退出市场，消费者的选择权就缩减了；但与此同时，任何 Google 在闭源之前已经发布的 AOSP 代码，理论上仍然可以使用。厂商可以随意 fork 代码，自己开发、更新、维护。估计智能冰箱的消费者不会在意冰箱是否预装最新 Android 操作系统。
不过，这恐怕就又回到了「Android 碎片化」的老生常谈：如果非授权设备厂商继续一意孤行，用老的、不再有官方维护的代码去开发产品，届时碎片化恐怕就不是版本号那么简单了——而是可能出现类似于今天的中国，推送、版本、功能、外观、名称、体验等全方位碎片化，并且向全球范围扩大的一副诡异图景。
开发者权益侵害
AOSP 的闭源，对于 Android 应用第三方 ROM 开发者来说，影响更为明显。
曾经 Android 第三方 ROM 百家争鸣的景象，也将被历史掩埋。ROM 开发者的最好结果，是用 AOSP 最后更新的版本去修改，然后维护当前版本，到它慢慢过时，直至最后放弃这项事业。
至于应用开发者，他们仍然可以从 Google 获取需要的 SDK，在后 AOSP 时代内应该不会有太大的直接影响。
不过在此之前，由于 Android 已经存在相当程度的碎片化情况，开发者为了适配各版本系统、各品牌机型，需要获得不同厂商的系统代码，以及设备作为测试机。这对于中小型，特别是独立开发者来说都是不小的成本。目前尚不清楚这种情况在今后会不会愈演愈烈。
如果中小开发者生存环境被遭到进一步挤压，传导效应就是强者恒强，创新被遏制，进而发生更多的垄断。因此，Google 在做了它该做的事情之后，应该要给出后续方案，确保中小开发者的生存。
最极端，却又最不出意外的做法
此前在中美技术脱钩的大背景下，爱范儿曾经构思过 Android 对中国手机厂商「断供」的几种可能性：禁止在海外销售的手机中显示 Android 商标、禁止预装 GMS、对中国厂商「指向性」闭源 AOSP，甚至中止这些厂商的授权并将其从 OHA 中解约/除名。
在所有可能性中，完全闭源 AOSP 是可能性最低的。爱范儿一度认为这样做实在太不体面了。
在智能移动设备的萌芽阶段，Google 做出开源 Android 的决定，不仅获得了技术开放的名誉，更是在当时将大量厂商和用户从塞班、Windows Mobile，以及诺基亚和黑莓的手中赢了过来。
当然，诺基亚、黑莓和微软各自走了弯路，对Google 获胜起到不小的助攻作用。但 Google 开源 Android，毫无疑问，是今天 Android 在移动操作系统市场抢下超七成份额的道路上，最正确的决定。
Google 内部仍有员工认可开源这项事业的科技普及化意义和长期价值。无论出于业务和上级要求，还是个人身份，他们为 Android 项目编写代码，做维护工作，而 AOSP 也是这些工作的载体。然而 AOSP 对于 Android 和 Google 的商业价值，早已不可同日而语。
尽管这次操作的主要动机是节约成本，但长期来看，也会对 Google 增加收入带来一定帮助。毕竟在过去，Google 很难从那些运行基于 AOSP 操作系统的非认证设备上获得直接收入或数据等间接利益。
在这一事件之前，Google 通过 Android 赚钱的方式，主要是在伙伴协议的框架下对 OEM 进行收费授权认证。 想要在商业合规的框架下使用 Android，厂商需要签署协议。具体协议内容方式等细节可能会有不同，但大的规则是不变的。Google 的主要收入来源是通过预装的Google应用和服务(搜索、Play商店等)获取的广告收入和应用分成。
显然，非认证设备无法给 Google 创造收入，AOSP 的存在却「给人做嫁衣」，作为任何一家商业公司恐怕都想要尽快跟这些设备和厂商切割。
