概括而言，若运用了遵循GPL许可的软件代码，则必须将其开源，这彰显了“共进退、共享成果”的理念。
为了实现开源与盈利的双重目标，采取了一种巧妙的策略：底层核心部分严格遵守GPL开源协议，然而在AOSP的多数代码上，却采用了较为宽松的2.0许可证。
厂商可以自主调整，无需全面披露，同时还能融入独特的元素，兼顾了开放性与灵活性。
具体而言，核心组件以及模块必须保持开源性质，然而在用户层面上的应用程序则不受GPL协议的约束，若开发者愿意，完全可以将其封闭。
最终，AOSP在底层遵循GPL开源协议，中层采用较为宽松的开源模式，而上层应用的开发则完全取决于开发者的个人喜好，他们可以随心所欲地开展各种活动。
谷歌的这点小聪明那是相当的成功。
回想将近二十年前，智能手机刚起步那会儿，苹果发布了。
谷歌也想在移动市场分一杯羹，于是决定推出。
这不仅为谷歌赢得了技术开放的赞誉，同时也吸引了一大批厂商和用户，使他们从塞班、诺基亚、以及黑莓等品牌的束缚中解脱出来。
真是神来之笔。
开源战略，无疑是谷歌在移动操作系统领域取得超过七成市场份额的关键因素。
市场是拿到了，代价是AOSP软件的维护是要做的。
问题在于，手机功能日益丰富，相应的维护成本也在不断攀升。
终于，谷歌忍不了了。
代码同步难，谷歌决定「关起门」来开发，但依然开源代码
编写过程序的人都知道，相较于编写程序本身，合并代码往往更让人感到棘手。
在2007年，谷歌公开发布了安卓操作系统的核心源代码，这一举措使得谷歌在移动互联网的浪潮中收获了最丰硕的果实。
但是也导致安卓这个项目有了两个「主分支」。
这个分支被称为公共的AOSP分支，它对所有用户都是开放的。人们常说的“安卓开源”实际上就是指的这个分支。
某些辅助特性，诸如蓝牙技术，依旧在AOSP的分支内持续进行公开性的开发工作，您可以在开源的代码库中寻找到这些功能的源代码。
然而，AOSP的公共分支并未纳入谷歌所拥有的应用程序与服务，诸如Play商店、Maps等均不包含在内。
AOSP虽不具备谷歌自家的服务功能，却依然能够被编译成一套完整的、可供使用的操作系统。
许多设备制造商基于AOSP开发自己的操作系统，包括：
三星：开发了One UI。
小米：开发了MIUI。
OPPO：开发了。
华为：开发了早期的EMUI。
一加：开发了。
该分支实行彻底的封闭式开发，实则可被视为谷歌自家的安卓系统之“亲生之子”。
此业务板块仅对持有谷歌移动服务许可的公司开放，包括类似三星One UI等系统，只要获得谷歌的批准即可使用。
目前观察，诸多组件，涵盖基础操作系统架构，均在其内部分支中秘密进行研发。
这两个分支引发了一个显著的问题，即它们内部开发的进度超过了公开的AOSP，从而导致了两个分支之间出现了较大的分歧。
这种区别迫使谷歌不得不投入大量时间和精力，以在公共AOSP分支和其内部分支之间进行补丁的整合工作。
这便是程序员们普遍欢迎的部分，鉴于分支间的差异显著，合并时频繁遭遇冲突现象。
以该补丁为例，它激活了导航栏和屏幕键盘放大等特性，同时，它还新增了辅助功能的配置选项，并将这一选项置于辅助功能列表的尾部位置。
这将会引发合并时的冲突现象，原因在于AOSP与谷歌内部分支的列表长度存在差异（如图中所示，变量分别设为58和59，由此产生冲突）。
尽管针对这个特定问题的解决方法并不复杂，然而，每当众多AOSP的补丁被整合进谷歌的内部分支后，常常会引发类似的合并冲突问题。
另一个案例表明，为了启用这款新开发的API，负责解锁存储空间的，一位工程师需从内部分支中精选一个补丁，并将其引入AOSP中，以妥善处理合并过程中出现的分歧。
尽管API是在AOSP框架下进行开发的，然而，带有新构建标识的文件却是我们内部独立完成的。
因此，我们必须向内部提交一份修改构建标志文件的补丁，紧接着将其应用于AOSP。
单独审视这些冲突或许并不复杂，然而，面对可能出现的众多此类“合并冲突”的案例，却让人难以应对。
或许正是由于“累觉不爱”，谷歌才决定摒弃现有的并行开发模式，转而将所有研发任务整合至公司内部进行。
这对我们意味着什么？
这一决策整体来说，并不意味着正在变成「闭源」。
谷歌只是想把「开发过程」藏起来，依然会继续发布源代码。
最大的差异在于，当AOSP的公共分支存在之际，对于热衷于技术研究的爱好者以及科技行业的媒体工作者而言，这便是一个得以一窥最新发展趋势的窗口。
谷歌即将关闭这个“窗口”，此举可能会让众多科技爱好者感到失落，原因是这无疑削弱了他们对于开发领域的深入了解。
对于开发者来说，这将使得他们更难以适应平台的新动态，原因在于他们将失去追踪AOSP变动的能力。
例如，一位外籍记者在AOSP平台中发现了一些代码上的变动，随后便预判出了网络摄像头功能的推出，并且借助AOSP的线索，他还推断出了16版本提前发布的具体日期。
对于绝大多数人来说，即便是安卓应用的开发者，这也几乎不会造成任何影响。
实际上，从逻辑推理来看，谷歌很可能认为持续维护代码的代价相当高昂；无论是将AOSP的代码整合至其内部版本，亦或是将内部版本的更新反馈至AOSP的公共分支，这些任务均需工程师们来完成。
这些处理矛盾的任务被视作过于初级，对于谷歌的工程师而言，它们既费时费力，又显得毫无价值。
然而，在某种程度上，AOSP已然成为谷歌在开源领域及程序员心中的一张“投名状”。
秉持“不作恶”宗旨的谷歌，其采取的安卓开源策略，被誉为该公司历史上最出色的战略决策之一。
在极客们的眼中，这一决策仿佛谷歌亲手摧毁了其过去十数年所建立的「精神象征」。
自然，站在谷歌自身的立场来看，将业务集中到内部的一个分支下，并且简化操作系统的开发流程以及源代码的发布，这样的选择是能够得到理解的。
AOSP如今的商业价值，与昔日相比，已截然不同，达到了一个全新的高度。