代码主线、分支和版本

Android 开源项目（AOSP）主张原始设备制造商（OEMs）和其他设备实施者将一个完整的软件堆栈植入并运行在他们自己的硬件上。为了保持 Android 的质量，谷歌贡献出了专职的工程师、产品经理、用户界面设计师、质量保证测试人员和所有其他把现代化设备带向市场的必要相关人员。

因此，我们保留了若干“代码主线”，从不稳定的试验性工作中清晰地区分出 Android 当前稳定的版本。我们将开源的管理和维护迭代进更大的产品开发周期中。

下面的图表描述了在概念层面上 AOSP 是如何管理代码和版本。我们将提及的这些作为“代码主线”而不是“支线”，仅仅是因为在任何特定的时刻，一个特定的“代码主线”里都有可能存在不止一条支线。例如，当一个发布被中断，它会基于当时的需求去决定它能不能成为一条新的分支。

在任何特定的时刻，都有一个 Android 平台的当前最新版本。这通常表现为树的一个分支形式。
设备制造商和参与者使用当前最新版本进行工作，修复漏洞，推出新设备，试验新功能等等。
与此同时，谷歌根据产品的需要和目标，内部实现 Android 平台和框架的下一个正式版本。我们通过在旗舰设备上与设备合作伙伴合作，开发出 Android 的下一个正式版本。这些设备合作伙伴的性能规范被选中，用来推动 Android 朝着我们希望的方向前进。
当“N+1”个版本已经准备就绪，它将被发布到公共源代码树，并成为新的最新版本。

条款及注意事项

一个发布版本对应于一个 Android 平台的正式版本，例如 1.5，2.1 等等。一般来说，一个平台的发布版本对应一个正式版本。这个正式版本在 AndroidManifest.xml 文件的 SdkVersion 域里面且它是在 frameworks/base/api 源代码树下定义的。
一个上游项目是一个开源项目，Android 堆栈就是从这个开源项目上获取代码的。这些包括一些著名的项目，如 Linux 内核和 WebKit。随着时间的推移，我们正在迁移的一些半自主性的 Android 项目(例如 Android 运行环境 “ART”， Android SDK 工具，Bionic 等等) 作为“上游”项目进行开发。通常情况下会在公共树里面完全开发这些项目。对于一些上游项目，开发是通过直接地构建上游项目本身完成的。可以参看上游项目获取更多资讯。在这两种情况下，快照将定期被拉入版本。
在任何时候，对于特定的 Android 平台，代码主线版本（实际上在 git 里面可能包含了不止一个实际的分支）被认为是唯一规范的源代码。原始设备制造商和其他设备制造商应该只从发布版本分支获取源代码。
“实验性”代码线路的建立用以获取社区的变化，这样他们可以在迭代上着眼于稳定性。
证明了稳定的变化将最终被拖入发布分支。注意，这只适用于漏洞修复的、应用程序改进的和其它不影响平台 API 的变化。
当有必要时，变化将被从上游项目（包括 Android “上游”项目）拖入发布分支。
谷歌内部将开发“N+1”个版本（即框架和平台 API 的下一个主要版本）。可以参看关于私有的代码主线获取更多资讯。
当有必要时，从上游、发布版本与实验分支拉出的变化将会放到谷歌的私有分支。
当下一个正式版本的平台 API 已经稳定，并经过全面测试，谷歌将中断下一个平台正式版本的发布版本。（这特别是指一种新 SdkVersion。）这也将对应被制成一个公共发布分支的内部代码行和新的当前平台代码主线。
当一个新的平台版本被中止，一个相应的实验代码行会在同一时间被创建。

关于私有代码线

上述提及的源管理策略包括一个谷歌将继续保密的代码主线。这样做的原因是要把注意力集中在目前 Android 公共版本。

原始设备制造商和其他设备制造商自然希望制造出与 Android 最新版本相关的产品。同样，应用程序开发者如非必要不希望处理更多的平台版本。与此同时，谷歌保留对作为一个平台和一个产品的 Android 战略方向的责任。我们的方法着重于在少量的旗舰设备上运行功能，确保与 Android 相关的知识产权受到保护。

结果是，谷歌经常拥有来自第三方的机密信息。我们必须避免泄露敏感的功能，直到我们确保拥有适当的保护措施。另外，一次存在太多平台版本也会对平台引起真实的风险。基于这些原因，我们已经构建了开源项目 - 包括第三方的贡献 - 以专注于 Android 的目前公开的稳定版本。下一平台版本的深度开发不会公开进行，直到它已经准备好成为一个发布版本。

我们意识到许多贡献者不同意这种方法。我们尊重其他人可能有不同的观点，然而，我们觉得这种方法是最好的，我们也选择这个方法来实现。