谷歌欲对开发新版 Android 操作系统的方式进行重要的变更。
许多人认为，Android 的开源属性是选择这款系统的重要理由之一。三星等 OEM 厂商会对 One UI 等皮肤版本的代码进行自主调整。而那些密切关注 Android 动向的朋友，往往能够从谷歌对 Android 开源项目（Android Open Source Project，即 AOSP）的公开变更中，察觉到操作系统即将推出新功能的各种迹象。
过去，Android 实时开放源代码。这使得全球拥有了数十亿台设备的庞大生态系统。同时，也催生了移动互联网时代最具活力的创新模式。
然而，谷歌在近日明确予以确认。从下周开始，Android 未来的核心功能开发将会转入内部闭环状态。并且，只会定时向 AOSP 推送阶段性的成果。与此同时，AOSP 的更新频率也会逐渐放慢。
谷歌虽一再强调不会封闭源代码，然而这种悄然将技术掌控在自身手中的行为，正使得原本开放的安卓生态系统逐渐向谷歌靠近，甚至进一步强化了谷歌“一家独大”的态势。
谷歌进一步转向内部开发
谷歌确认了，未来所有关于 Android 的开发工作都将在其内部展开。谷歌明确表示，未来的 Android 开发工作会在其内部进行。谷歌已确定，未来所有 Android 的开发事宜都将在其内部开展。
AOSP 是一个开源操作系统开发项目，由谷歌进行维护。任何人都能够自由地对其进行访问和查看代码。并且可以为该项目贡献代码以及进行修复工作。AOSP 当中包含了 Android 操作系统的核心组件，然而却不包含谷歌及其合作伙伴所开发的专有软件，比如谷歌移动服务（GMS）。GMS包含了 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）许可证的公司开放，像三星、摩托罗拉等这类公司就在此列。
此前，有一些组件，比如构建系统，它是 AOSP-first 的，是在公开环境下完全开发的；还有更新引擎，它也是 AOSP-first 的，在公开环境下被完全开发；蓝牙协议栈同样是 AOSP-first 的，在公开环境下得以完全开发；虚拟化框架也是如此，在公开环境下被完全开发；SELinux 配置也是 AOSP-first 的，在公开环境下进行完全开发。
从下周开始，Android 的所有开发工作会在谷歌的内部分支开展。只有在谷歌发布新的分支之后，相关的源代码才会向外界开放。
这是一张屏幕截图。它是 Google 使用的基于网络的代码审查系统 AOSP Gerrit 的截图。
谷歌承诺会持续发布新 Android 版本的源代码。例如，在今年的晚些时候发布 Android 16 时，外界依然能够获取到更新后的源代码。
谷歌会持续发布 Android Linux 内核分支的源代码。因为此内核分支是依据 GPLv2 获得授权的，而 GPLv2 授权规定需要发布源代码，并且它与 AOSP 是相互独立的。
AOSP 之前是以 Apache 2.0 许可证的形式进行发行的。谷歌表示会持续发布源代码，并且多次强调这并非闭源。然而，对于谷歌将开发转为私人性质的行为，有网友发表评论称，倘若一个项目需要依赖一家公司来持续进行开发，那么开源许可证就失去了其应有的意义。
另外，有人提及了 OpenSolaris 的悲剧性转折。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 时间表尽量提前。
参考链接:
