本文档包含有关 Android 开源平台 (AOSP) 的一般性问题解答。
关于 android-latest-release
为什么我无法提交到 aosp-main？
您无法提交到 aosp-main，因为该分支现在是只读的。
我应该在哪里提议更改 AOSP？
您应该向 android-latest-release（当使用 Repo 时）或 android-latest-release 清单中指定的最新发布分支（当直接使用 Git 时）提议新的更改。其他分支（例如 aosp-main）上现有的提议更改无需移动。
我应该同步到哪个分支？
当使用 Repo 时，使用以下命令同步到
android-latest-releaserepo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifest当直接使用 Git 时，同步到
android-latest-release清单中指定的默认修订分支。
有关同步分支的更多详细信息，请参阅初始化 Repo 客户端。
来自 android-latest-release 的代码会合并到 aosp-main 吗？
不会，代码不会合并到 aosp-main，该分支自 2025 年 3 月 27 日起为只读分支。
下一个版本的代码推送到哪里？
Google 会将下一个版本的代码推送到最新的公共发布分支，并更新 android-latest-release 清单以指向该分支。
我的更改请求会从 android-latest-release 分支 cherrypick 到内部 Gerrit 吗？
在您上传提议的更改后，Google 将审核它，如果被接受，则会将其 cherrypick 到内部 Gerrit 中。
我如何知道我的更改请求是否被接受？
已接受和 cherrypick 的更改会出现在未来推送到 Android 主机上的发布分支中，并且可以使用 android-latest-release 与 repo 同步。对于何时接受或拒绝提议的更改，没有通知机制。
从外部贡献者提议更改到将其合并到最新发布分支，一般工作流程是什么？
外部贡献者向
android-latest-release（当使用 Repo 时）或android-latest-release清单中指定的最新发布分支（当直接使用 Git 时）提议更改。Google 审核更改。如果更改是
被接受，Google 会 cherrypick 该更改并将其合并到内部开发分支中。
未被接受，Google 不会 cherrypick 该更改。
外部贡献者检查他们的更改是否在
android-latest-release中。
如果我不再需要我提议的更改怎么办？
如果您不再需要您提议的更改，不希望合并更改，或者知道 Google 已经审核了更改，请放弃该更改，以便它保留在 Android 主机上的提议的更改历史记录中。
开源问题
Google 为什么开放 Android 源代码？
Google 启动 AOSP 是为了回应我们自己发布移动应用的经验。我们希望确保始终有一个开放平台可供运营商、OEM 和开发者使用，以将他们的创新想法变为现实。我们还希望避免任何中心故障点，以便任何单一行业参与者都无法限制或控制任何其他参与者的创新。我们 AOSP 最重要的目标是确保尽可能广泛和兼容地实施开源 Android 软件，从而使每个人都受益。
Android 属于哪种开源项目？
Google 负责监督核心 AOSP 的开发，并致力于创建强大的开发者和用户社区。在大多数情况下，Android 源代码是在宽松的 Apache License 2.0 而不是 copyleft 许可下获得许可的。我们选择 Apache 2.0 许可，因为我们认为它鼓励 Android 软件的广泛采用。有关详情，请参阅许可。
为什么 Google 负责 Android？
启动软件平台非常复杂。开放性对于平台的长期成功至关重要，因为开放性吸引了来自开发者的投资，并确保了公平的竞争环境。该平台还必须是用户有吸引力的产品。
Google 已投入必要的专业工程资源，以确保 Android 成为一个完全具有竞争力的软件平台。Google 将 Android 项目视为全面的产品开发运营，并达成必要的商业交易，以确保运行 Android 的出色设备能够上市。
通过确保 Android 在用户中取得成功，我们帮助确保 Android 作为平台和开源项目的活力。毕竟，谁想要一个不成功产品的源代码呢？
我们的目标是确保围绕 Android 构建成功的生态系统。我们开放了 Android 源代码，以便任何人都可以修改和分发该软件以满足自己的需求。
Google 针对 Android 产品开发的总体策略是什么？
我们在竞争激烈的市场中发布出色的设备。然后，我们将我们所做的创新和增强功能融入到核心平台中，作为下一个版本。
实际上，这意味着 Android 工程团队专注于少量“旗舰”设备，并开发下一版本的 Android 软件以支持这些产品的发布。这些旗舰设备承担了大部分产品风险，并为广泛的 OEM 社区开辟了道路，后者紧随其后推出了更多利用新功能的设备。通过这种方式，我们确保 Android 平台根据真实设备的需求不断发展。
Android 软件是如何开发的？
每个 Android 平台版本（例如 1.5 或 8.1）在开源树中都有一个对应的分支。最新的分支被认为是当前稳定分支版本，android-latest-release 清单指向该版本。这是制造商移植到其设备的分支。此分支始终保持适合发布的状态。
最后，Google 在开发旗舰设备的同时，也在开发下一版本的 Android 平台。
为什么 Android 的某些部分是私下开发的？
将设备推向市场通常需要一年多的时间。当然，设备制造商希望尽可能发布最新的软件。同时，开发者在编写应用时，不希望不断跟踪平台的新版本。这两组人都面临着发布产品和不想落后的紧张关系。
为了解决这个问题，下一版本 Android 的某些部分（包括核心平台 API）是在私有分支中开发的。这些 API 构成了下一版本的 Android。我们的目标是在我们创建下一版本的平台时，将注意力集中在当前稳定版本的 Android 源代码上。这使开发者和 OEM 可以使用单个版本，而无需跟踪未完成的未来工作以保持同步。
源代码发布何时进行？
当它们准备就绪时。发布源代码是一个相当复杂的过程。Android 的某些部分（例如内核）是在开放环境中开发的，并且该源代码始终可用。其他部分首先在私有树中开发，并且该源代码在下一个平台版本准备就绪时发布。
在某些版本中，核心平台 API 的准备工作提前完成，以便我们可以在设备发布之前先发布源代码以供早期查看。在其他版本中，这是不可能的。在所有情况下，当我们认为版本稳定并且开发过程允许时，我们都会发布平台源代码。
发布新 Android 版本的源代码涉及哪些内容？
发布新版本 Android 平台的源代码是一个重要的过程。首先，该软件被构建到设备的系统映像中，并通过各种形式的认证，包括电话将要部署的地区的政府监管认证。代码还要经过运营商测试。这是该过程的一个重要阶段，因为它有助于检测软件错误。
当发布获得监管机构和运营商的批准后，制造商开始批量生产设备，我们开始发布源代码。
与批量生产同时进行，Google 团队启动了多项工作来准备开源发布。这些工作包括进行最终 API 更改、更新文档（以反映在资格测试期间所做的任何修改）、为新版本准备 SDK 以及发布平台兼容性信息。
我们的法律团队会进行最终签署以将代码发布到开源中。正如开源贡献者需要签署贡献者许可协议以证明他们对其贡献的知识产权所有权一样，Google 必须验证源代码是否已清除以进行贡献。
从批量生产开始到软件发布过程通常需要大约一个月的时间，因此源代码发布通常发生在设备到达用户手中前后。
AOSP 与 Android 兼容性计划有何关系？
AOSP 维护 Android 软件并开发新版本。由于它是开源的，因此该软件可以用于任何目的，包括开发与其他基于相同源代码的设备不兼容的设备。
Android 兼容性计划的功能是定义 Android 的基准实现，该实现与开发者编写的第三方应用兼容。Android 兼容设备有资格参与 Android 生态系统，包括 Google Play；不符合兼容性要求的设备存在于该生态系统之外。
换句话说，Android 兼容性计划是我们区分 Android 兼容设备和仅运行源代码衍生版本的设备的方式。我们欢迎所有对 Android 源代码的使用，但要参与 Android 生态系统，设备必须通过该计划被识别为 Android 兼容。
我如何为 Android 做贡献？
您可以报告错误、为 Android 编写应用，或为 AOSP 贡献源代码。
我们接受的代码贡献类型是有限制的。例如，有人可能想要贡献替代的应用 API，例如完全基于 C++ 的环境。我们将拒绝该贡献，因为 Android 鼓励应用在 ART 运行时中运行。同样，我们也不会接受与我们的许可目标不兼容的 GPL 或 LGPL 库等贡献。
我们鼓励有兴趣贡献源代码的人员在开始任何工作之前，通过Android 社区中列出的渠道与我们联系。有关详情，请参阅贡献。
如何成为 Android 提交者？
AOSP 实际上没有提交者的概念。所有贡献（包括 Google 员工编写的贡献）都通过一个名为 Gerrit 的基于 Web 的系统进行，该系统是 Android 工程流程的一部分。该系统与 Git 源代码管理系统协同工作，以清晰地管理源代码贡献。
指定的批准者需要审核并接受所有提议的更改。批准者通常是 Google 员工，但相同的批准者负责所有提交，无论来源如何。
有关详情，请参阅提交补丁。