Android 开源项目 (AOSP) 维护一个完整的软件堆栈,可供 OEM 和其他设备实现者移植并在他们自己的硬件上运行。为了保持 Android 的质量,Google 派遣了全职工程师、产品经理、用户界面设计师、质量保证测试人员以及将现代设备推向市场所需的所有其他角色。
因此,我们维护了许多代码行,以清楚地将当前稳定版本的 Android 与不稳定的实验工作区分开来。我们将 Android 代码线的开源管理和维护纳入更大的产品开发周期。
AOSP 代码管理
下图描述了 AOSP 代码管理和发布背后的概念。

- 在任何特定时刻,都有最新版本的 Android 平台。这通常采用树中分支的形式。
- 设备制造商和贡献者使用当前的最新版本、修复错误、启动新设备、试验新功能等等。
- 与此同时,Google 根据产品的需求和目标,在内部开发下一个版本的 Android 平台和框架。我们通过与旗舰设备上的设备合作伙伴合作开发下一个版本的 Android,该设备的规格被选为将 Android 推向我们认为应该发展的方向。
- 当第 n+1 个版本准备就绪时,它会发布到公共源代码树并成为新的最新版本。
条款和注意事项
- 版本对应于 Android 平台的正式版本,例如 1.5 或 8.1。平台的版本对应于
AndroidManifest.xml
文件的SdkVersion
字段中的版本,并在源代码树的frameworks/base/api
中定义。 - 上游项目是 Android 堆栈从中提取代码的开源项目。除了 Linux 内核和 WebKit 等项目,我们继续迁移一些半自治的 Android 项目,如 ART、Android SDK 工具和 Bionic 以作为上游项目工作。通常,这些项目完全在公共树中开发。对于一些上游项目,开发人员直接为上游项目做出贡献。有关详细信息,请参阅上游项目。在这两种情况下,快照都会定期拉入版本中。
- 在任何时候,发布代码行(可能包含多个 git 分支)都被认为是给定 Android 平台版本的唯一规范源代码。 OEM 和其他构建设备的团体应该只从发布分支中提取。
- 建立实验代码线以捕获来自社区的更改,以便可以在关注稳定性的同时对其进行迭代。
- 证明稳定的更改最终会被拉入发布分支。这仅适用于不影响平台 API 的错误修复、应用程序改进和其他更改。
- 如有必要,更改会从上游项目(包括 Android 上游项目)拉入发布分支。
- 第 n+1 版(框架和平台 API 的下一个主要版本)由 Google 内部开发。有关详细信息,请参阅私有代码行。
- 如有必要,更改会从上游、发布和实验分支中提取到 Google 的私有分支中。
- 当下一个版本的平台 API 稳定并经过全面测试时,Google 会削减下一个平台版本的发布(特别是新的
SdkVersion
)。这对应于将内部代码线设为公开发布分支和新的当前平台代码线。 - 当一个新的平台版本被砍掉时,会同时创建一个相应的实验代码线。
私有代码行
上面的源代码管理策略包括谷歌保密的代码线,以将注意力集中在当前的公共版本的 Android 上。
原始设备制造商和其他设备制造商自然希望提供具有最新版本 Android 的设备。同样,应用程序开发人员不想处理不必要的平台版本。同时,谷歌保留了安卓作为平台和产品的战略方向的责任。我们的方法侧重于少数旗舰设备来驱动功能,同时确保对 Android 相关知识产权的保护。
因此,Google 经常拥有来自第三方的机密信息,并且必须避免泄露敏感功能,直到获得适当的保护。此外,如果同时存在太多平台版本,平台也存在真正的风险。出于这些原因,我们构建了开源项目(包括第三方贡献)以专注于当前公开的稳定版 Android。该平台的下一个版本的深入开发是私下进行的,直到它准备好成为正式版本。
我们认识到许多贡献者不同意这种方法,我们尊重他们的观点。但是,这是我们认为最好的方法,也是我们选择为 Android 实施的方法。