谷歌计划对开发新版 Android 操作系统的方式进行重大变革。
在许多人眼中，Android 的开源属性正是选择这款系统的关键理由之一——三星等 OEM 厂商通过对 One UI 等皮肤版本的代码进行自主调整；而密切关注 Android 动向的朋友则往往能从谷歌对 Android 开源项目（Android Open Source Project，即 AOSP）的公开变更中，发现关于操作系统即将推出新功能的种种迹象。
过去，正是因为 Android 实时开放源代码，才成就了全球数十亿台设备的庞大生态系统，并催生了移动互联网时代最具活力的创新模式。
然而，谷歌近日正式确认，从下周起，Android 未来的核心功能开发将转入内部闭环，仅会定期向 AOSP 推送阶段性成果，同时 AOSP 的更新频率也将放缓。
虽然谷歌一再强调不会封闭源代码，但这种悄悄地把技术控制在自己手里的做法，正在让本来开放的安卓生态系统越来越向谷歌靠拢，甚至进一步加强谷歌“一家独大”的局面。
谷歌进一步转向内部开发
谷歌已确认，未来所有 Android 的开发工作都将在其内部进行。
AOSP 是一个由谷歌维护的开源操作系统开发项目，任何人都可以自由访问、查看代码，并为项目贡献代码和修复。AOSP 包含了 Android 操作系统的核心组件，但并不包含谷歌及其合作伙伴开发的专有软件，例如谷歌移动服务（GMS）。GMS 包含了 Play Store、谷歌云消息推送框架、Chrome 浏览器、Google 搜索等应用。
Android 的一个显著特点是其版本多样性，这既是其优势所在，也偶尔带来挑战。例如，三星的 One UI 甚至谷歌自家的 Pixel UI，都在核心 Android 体验基础上进行了定制，加入了独特的功能和改进。这一切都得益于 AOSP 提供的通用基础操作系统。
除了对公众开放贡献外，Android 开源项目还允许根据开源许可自由使用和修改。亚马逊和三星
等制造商可以自由地根据自身需求调整 AOSP，并开发出自己的衍生产品，例如完全不搭载谷歌服务的多功能 Amazon Fire OS。
这种开放性也为某些企业在受到贸易制裁后继续开发基于 Android 的 EMUI 和 HarmonyOS 之类的操作系统提供了可能。比如，华为在面临一些国际限制后，无法再获得 GMS 许可，但可以继续使用 AOSP，最终华为用 HMS 取代了 GMS 功能。也有观点认为，这等于华为可以继续使用 Android，但他们得不到谷歌的帮助。
值得注意的是，要让 AOSP 成为一款功能齐全的智能手机操作系统，往往需要进行大量调整——有时甚至是大规模修改。因为如果仅仅按照默认方式构建 AOSP 并将其安装到设备上，其功能远远达不到现代智能手机的标准。许多用户日常依赖的关键功能都将缺失，以至于运行纯 AOSP 几乎没有实际意义。
但如今谷歌决定将核心功能转入内部开发，可能会导致一些依赖 AOSP 进行定制的硬件厂商获取新功能的时间延迟，从而影响产品竞争力。此外，开发者社区可能无法再提前看到代码变更，使其难以及时适配和优化应用。
谷歌过去的做法是频繁更新公共 AOSP 分支，任何人都可以访问 AOSP，但内部分支仅对谷歌和拥有谷歌移动服务 (GMS) 许可证的公司开放，例如三星、摩托罗拉等。
此前，一些组件，如构建系统、更新引擎、蓝牙协议栈、虚拟化框架和 SELinux 配置，是 AOSP-first，即完全在公开环境下开发。
但从下周起，Android 的所有开发工作都将在谷歌的内部分支进行，只有当谷歌发布新的分支时，相关源代码才会对外开放。
这是 Google 使用的基于网络的代码审查系统 AOSP Gerrit 的屏幕截图。
谷歌承诺将继续发布新 Android 版本的源代码，比如在今年晚些时候发布 Android 16 时，外界还能继续获得更新的源代码。
此外，谷歌将继续发布 Android Linux 内核分支的源代码，因为它是根据 GPLv2 授权的，该授权要求发布源代码，并且与 AOSP 是分开的。
AOSP 之前是基于 Apache 2.0 许可证发行，尽管谷歌也表示会继续 release 源代码，且一再强调这并非闭源，但对于谷歌将开发转为 private 的行为，有网友评论说，“如果一个项目依赖于一家公司进行持续开发，那么开源许可证就没有任何意义。”
另外，也有人提到 OpenSolaris 的悲剧性转折，这是由 Sun Microsystems 基于 Solaris 创建的开源操作系统，在 2010 年甲骨文收购了 Sun Microsystems 之后，OpenSolaris 便停止了自主开发。
当时，OpenSolaris 也是宣布“我们将不再实时发布整个 Solaris 操作系统的源代码”。 但从那一刻起，源代码就再也没有公开过。
当年甲骨文的决定彻底冰封了开源生态，而今 Android 似乎也正沿着相似的轨迹滑行，因此也有网友认为，对于 Android 来说，最终的目标很可能是仅满足最低限度的开源要求，只发布那些受 Copyleft 约束、谷歌不拥有版权的代码，直到这些组件被封闭的替代方案取代。
谷歌对 Android 的铁腕统治：封闭是一步步发生的
如今，Android 的开发方式正逐渐转向更加私有化，这并非一蹴而就的变化。回望过去，Android 的发展历程与最初的开放姿态有着显著的不同。
十八年前，也就是 2007 年 11 月，Android 开放源代码项目（AOSP）正式发布。就在几个月前，第一代 iPhone 问世，迅速引起轰动，开启了现代智能手机时代。当时，谷歌预见到苹果可能在移动领域占据主导地位，而谷歌自身在该领域尚无立足之地。为了对抗 iPhone，Android 作为开源项目应运而生。
在 AOSP 成立之初，谷歌大力支持开源应用的开发，这些应用与免费的 AOSP 捆绑在一起。这种策略在当时是合理的，通过为 AOSP 投入开发精力和资源，谷歌在随后的几年里成功地大幅提升了基于 Android/AOSP 设备的市场份额。
Android 拥有了庞大的用户基础，也意味着其拥有海量的应用程序。如果一家公司选择分叉 Android，那么这个操作系统本身就与数百万个应用程序兼容。该公司只需建立自己的应用商店，并将所有应用上传即可。理论上，几乎在一夜之间，你就能拥有一个拥有大量应用程序的非谷歌操作系统。
因此，一个成功的替代 Android 版本，将是对谷歌主导地位的真正威胁。谷歌也一直在采取措施防范这种替代品的出现。
谷歌意识到需要对其公共源代码拥有更多的控制权，毕竟更少的开源代码意味着 Google 的竞争对手需要做更多的工作。
随着时间的推移，谷歌将 Android 功能从 AOSP 转移到闭源软件包中。例如，谷歌用自家的闭源版本取代了 AOSP 版的日历和消息应用，并在此过程中停止了对开源版本的维护。由于谷歌是这些应用的主要开发者，这一变化实际上扼杀或极大地阻碍了这些应用的开源 AOSP 版本的开发。
这些举措同时也让更新核心组件变得更加容易，而无需进行完整的操作系统更新。
Android 的所有重要且实用的部分早已被迁移到闭源组件中。结果就是，Android 变成了一座庞大的“开源”代码库，但缺少了让其真正运行所需的关键部分。AOSP 已经成为它过去形态的“空壳”，并且正逐步被进一步掏空。如今，Android 正在从“集市”模式转向“教堂”模式（指由开放开发变为封闭开发）。至于谷歌何时会发布“新版本”的 AOSP 源代码，谁也说不准。
我希望他们干脆把 Android 变成闭源，并尽可能地为股东赚钱——毕竟，这才是他们的职责。他们为什么还要免费提供这个系统？他们已经通过宣称开源、建立社区成功占领了市场，现在只需要让它变成专有软件，而旧的开源版本会逐渐衰落、变得不稳定。然后，他们就可以像微软那样，对操作系统收费——但这次是在手机上，对数百万、甚至数十亿台设备收费，$。（显然我并不认同这种做法）。
目前，大多数 Android 开发都在内部分支中进行，但少数组件（如蓝牙和内核）是在公开分支中开发的。在新系统下，它们将转移到内部分支。
这一变化无疑将使谷歌团队的开发工作更加轻松，但它可能会限制我们在新版本正式发布之前对 Android 的了解程度。有时，AOSP 中出现的花絮可能会指向即将推出的设备、功能删除或应用程序支持的变化。
我们可能再也无法获得这些见解，因此，在谷歌推出不受欢迎的更改之前，开发者和用户将没有那么多机会挑战谷歌。
根据谷歌的说法，他们做出这一改变是为了简化流程，并借鉴了最近对基于主干的开发所做的改变。
由于谷歌同时长期维护着两个独立 AOSP 分支——一个为公共分支，一个是内部分支。任何人都可以查看公共分支，但只有谷歌自身、Android OEM 厂商乃至其他签订了谷歌移动服务（GMS）许可协议的企业才能访问到内部版本。这两个分支在功能和 API 支持方面并不同步，这迫使谷歌不得不在每次发布时都费力地合并分支。谷歌声称，通过专注于内部分支，它可以简化发布流程，让每个人的工作都更轻松。
AOSP 专家 Mishaal Rahman 指出，AOSP 的大部分开发工作都是由谷歌在内部完成的。就是说哪怕是在此番正式变更之前，更新主体也一直只会出现在内部分支上。第三方可以向公共分支提交代码变更，但谷歌保留在确定 Android 新版本并发布源代码之前，拒绝一切此类变更的最终决定权。
总的来说，无论是在今天的新闻发布之前还是之后，以上事实均保持不变。公共 AOSP Gerrit 仍然可用，第三方提交结果也依旧公开可见。谷歌也将继续发布最终源代码——只是在开发过程中，该公司将大部分 AOSP 变更由原本的闭门开发正式定性为不公开进行。
AOSP Gerrit
根据 Rahman 的解释，这一变化主要是为了帮助谷歌内部团队提升效率。以往，在公共 AOSP 分支与单独的内部兴建和管理开发进度，往往会产生大量不必要的开销。
由于 AOSP 的公共分支往往落后于内部版本，所以在需要将二者的代码进行合并时，谷歌工程师们经常会遇到合并冲突——不同代码版本间的冲突往往需要耗费额外时间和精力方可解决。
通过将所有活跃开发工作转移至内部分支，谷歌认为此举可以消除上述冲突并简化其工作流程。
值得注意的是，这并不意味着公共 AOSP 代码仓库会由此消失——谷歌将继续在公共分支中发布最终源代码，第三方也仍可以通过公共 Gerrit 提交贡献。总而言之，此番调整只是正式确定了谷歌工程师在开发周期中该在哪里进行日常编码。
Android 开源项目仍然非常活跃。
至少从功能角度来看，此举造成的最大问题，就是为 AOSP 贡献代码的第三方开发者可能将难以跟踪 Android 即将迎来的变更。这可能会阻碍开发者们的持续贡献热情，因为谷歌在内部也许正在进行同样的开发与探索。
此前还有报道说，谷歌近期正在转向 Trunk Stable 开发流程（即所有人为同一代码版本做贡献，确保谷歌能够更快、更稳定地构建整个系统），希望借此加快 Android 的发布速度——特别是打算将今年年内的 Android 16 时间表尽量提前。
参考链接:
https://www.androidauthority.com/google-android-development-aosp-3538503/
