来源：36氪
Google已经决定停止Android开源项目（AOSP）。
封面来源｜Pixabay
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也可能会关闭。
从今往后，只有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，不存在了？
1.因为大部分AOSP代码通过Apache 2.0许可证发行，任何人都可以fork一份。其他代码服务平台上也有各种AOSP的镜像，例如GitHub和国内的Android社区。Google无权要求其它「非官方」AOSP代码库下线。已经开源的，无法被撤销开源。
2.也就是说，只要能从其他非官方渠道下载，人们仍然可以使用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之间的协议关系：
1.AOSP，任何厂商都可以使用AOSP进行开发，不需要获得Google的同意；
2.Android兼容性承诺协议ACC、移动应用分发协议MADA、企业设备补充协议EDLA等，不一而足。通过协议，Google和OEM之间建立商业约束。签订了ACC协议的OEM通过AOSP开发的操作系统，才能够称之为Android操作系统，获得Android商标使用权等权益。
3.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最后更新的版本去修改，然后维护当前版本，到它慢慢过时，直至最后放弃这项事业。
至于应用开发者，他们过去使用Android Studio、VS Code等开发环境，可以从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的存在却「给人做嫁衣」，作为任何一家商业公司恐怕都想要尽快跟这些设备和厂商切割。
0 条