提交补丁
这个页面将描述提交补丁到 AOSP 的全过程，包括校验和 初始化构建环境，创建密码和按照密码生成页面的说明学习。
- 可以在 Project roles 章节查看你可以在开源社区扮演的各种角色信息。
- 如果你打算在 Android 平台贡献代码，应该先阅读 Upstream Projects 中所说的目录。
贡献者
与服务器进行身份验证
在你上传内容到 Gerrit 的时候，你需要Using Authentication 补充说明。
从一个 Repo 分支开始
在你有意向更改的地方，可以在相关联的 git 库中新建一个分支：
$ repo start NAME .你可以在同一个库同一时间新建几个独立的分支。这个分支的名字是在你本地的工作空间，不包含在 gerrit 或者最终的源码分支树中。
更改
一但你更改了源码里面的文件（请验证它们），在本地库中 commit 这个改变：
$ git add -A $ git commit -s在 commit 的消息中，写上你更改信息的详细描述。这个描述信息将会 push 到公共的 AOSP 库，所以请按照我们的指导来写更改列表的描述信息：
-
开始是一行摘要（最多 60 字），接着空一行。这样的格式在 git 和 gerrit 中用于各种显示。
short description on first line more detailed description of your patch, which is likely to take up multiple lines. -
这个描述信息应该着重说明解决了什么问题，怎么解决的。第二部分尽管是值得满意的，但是实现新功能的时候还是比较随意的。
- 写入一些简短的假定或者背景信息，这些内容可能对明年致力于这个功能的奉献者很重要。
在执行 repo init 后得到的独特的 change ID，名称和邮箱将会自动添加到你的 commit 信息中。
上传到 gerrit
一旦 commit 你的更改到个人历史，就可以上传到 gerrit。
$ repo upload如果你在同一个库中选择了多个分支，你将会得到提示，让你选择一个分支上传。
上传成功之后，repo 将会给你提供一个 Gerrit 新页面的 URL。预览这个链接并在评审服务器上查看你的补丁，添加评论，或者给你的补丁请求特定的评审员。
上传一个代替的补丁
假如一个评审员已经看了你的补丁，并且要求你做一些小的更改。你可以通过 git 修改 commit 信息，这样将会在 gerrit 中生成一个新的补丁，但是使用的是原先那个 change ID。
注意，如果你在上传补丁之前添加了其他 commits，你将需要手动移动你的 git HEAD。
$ git add -A $ git commit --amend当你上传了修改的补丁，它将在 gerrit 和本地 git 历史中代替之前的。
解决同步冲突
如果提交到源码中的其他补丁和你的有冲突，你将需要在源码库新 HEAD 的顶部 rebase（重新定义分支版本库状态）你的补丁。一个简单的方法就是运行：
$ repo sync这个命令将会从服务器先 fetches 最新的源码，然后会试图自动 rebase HEAD 到新的远程 HEAD 上面。
如果自动 rebase 没有成功，你必须手动执行 rebase。
$ repo rebase使用 git mergetool 可能帮助你处理 rebase 冲突。一旦你成功地合并冲突文件，
$ git rebase --continue手动或者自动 rebase 完成之后，运行 repo upload 来提交你 rebase 补丁。
提交被批准之后
提交的内容在通过检查和验证过程之后，Gerrit 会自动的 merges 这个更改到公共的库中。其他用户可以运行 repo sync 来 pull 这个更新到自己的本地。
检查员和审核者
检查一个更改
如果你被分配成这个更改内容的批准者，你需要决定接下来的内容：
- 这个更改是不是符合项目一开始的目的？
- 这个更改是不是在现存的构造中有效？
- 这个更改引入的设计缺陷是否会在将来出现问题？
- 这个更改是否遵循这个项目中已建立的最佳实践？
- 这个更改是执行描述方法的好方式？
- 这个更改是否引入任何安全或不稳定的风险？
如果你准许了这个改变，请在 Gerrit 中用 LGTM（Look Good to ME）标记它。
审核更改
如果你被分配成这个更改内容的审核者，你需要做接下来的内容：
- 使用其中一种下载命令将这个更改 Patch 到自己的本地客户端。
- 构建和测试这个更改。
- 在 Gerrit 中，使用发布评论的方式来标记这个 commit，用“Verified”或者“Fails”，并且添加一个消息来解释哪些问题是经过鉴定的。
从 Gerrit 下载更改的内容
已经审核和合并之后的提交将会在下一次 repo sync 的时候被下载。如果你希望下载一个特定的没有经过检验的更改，执行：
$ repo download TARGET CHANGE这个 TARGET 就是你下载的更改将要放到本地目录的位置，CHANGE 就是在 Gerrit 中的更改列表的数字。想要知道更多信息，请查看Project Roles。
Diffs 和评论
在 Gerrit 中点击一个更改的 Id number 或者 Subject 可以打开这个更改的详细信息。想知道现有的代码和更新的代码之间的差异，可以点击文件名下的 Side-by-side diffs。
添加评论
在开源社区的任何一个人都可以使用 Gerrit 来给提交的源码添加内联的评论。一个好的评论将会关联行或者部分在 Gerrit 中的附加代码。这或许是关于如何改进一行代码，简短的或者建设性的意见，或者，这个也许是为什么作者这样写代码就有意义的解释。
想要添加内联评论，双击代码中相关联的行，并且在下一个打开的窗口写上你的评论。你点击保存之后，只有你可以看到你的评论。
想要发布你的评论，让其他 Gerrit 使用者看到评论，点击 Publish Comments 按钮。你的评论内容将会通过 email 发送给这个更改的所有当事人，包括更改的拥有者，补丁更新者（如果和拥有者不是同一个人），还有所有当前的检查者。
Upstream 项目
Android 使用很多其他开源项目，比如，Linux 内核和 WebKit，像在 Branches，icu-project.org/ 里被 upstream。查看 llvm.org/ upstream。
mksh
external/mksh目录下，MirBSD Korn Shell 项目的所有更改要么发送 email 到 mirbsd.org（不需要订阅提交）域名下的 miros-mksh，要么是 openssl.org 中 upstream。V8
external/v8 目录下 V8 项目的所有更改都应该提交到 Contributing to V8 查看详情。
WebKit
external/webkit 目录下 WebKit 项目的所有更改都应该在 Contributing Code to WebKit 获取更多信息。
zlib
external/zlib 目录下 zlib 项目的所有更改狗应该在 <a href="http://zlib.net/" rel="nofollow" "="">zlib.net 中 upstream。
This page describes the full process of submitting a patch to the AOSP, including reviewing and tracking changes with Gerrit (https://androidreview.googlesource.com/).
Prerequisites
Before you follow the instructions on this page, you need to initialize your build environment (https://source.android.com/source/initializing.html), download the source (https://source.android.com/source/downloading.html), create a password (https://android.googlesource.com/newpassword), and follow the instructions on the password generator page. For details about Repo and Git, see the Developing (https://source.android.com/source/developing.html) section. For information about the different roles you can play within the Android Open Source community, see Project roles (https://source.android.com/source/roles.html). If you plan to contribute code to the Android platform, be sure to read the AOSP's licensing information (https://source.android.com/source/licenses.html). Note that changes to some of the upstream projects used by Android should be made directly to that project, as described in Upstream Projects (#upstreamprojects).
For contributors
Authenticate with the server
Before you can upload to Gerrit, you need to establish a password (https://android.googlesource.com/newpassword) that will identify you with the server. Follow the instructions on the password generator page. You need to do this only once. See Using Authentication (https://source.android.com/source/downloading.html#usingauthentication) for additional details.
Start a repo branch
For each change you intend to make, start a new branch within the relevant git repository:
Submitting Patches
2017/5/23 Submitting Patches | Android Open Source Project
https://source.android.com/source/submit-patches 2/7
You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and will not be included on gerrit or the final source tree.
Make your change
Once you have modified the source files (and validated them, please) commit the changes to your local repository:
Provide a detailed description of the change in your commit message. This description will be pushed to the public AOSP repository, so please follow our guidelines for writing changelist descriptions:
Start with a oneline summary (50 characters maximum), followed by a blank line. This format is used by git and gerrit for various displays. Starting on the third line, enter a longer description, which must hardwrap at 72 characters maximum. This description should focus on what issue the change solves, and how it solves it. The second part is somewhat optional when implementing new features, though desirable. Include a brief note of any assumptions or background information that may be important when another contributor works on this feature next year.
Here is an example commit message:
A unique change ID and your name and email as provided during repo init will be automatically added to your commit message.
Upload to gerrit
Once you have committed your change to your personal history, upload it to gerrit with
$ repo start NAME .
$ git add -A $ git commit -s
short description on first line
more detailed description of your patch, which is likely to take up multiple lines.
2017/5/23 Submitting Patches | Android Open Source Project
https://source.android.com/source/submit-patches 3/7
If you have started multiple branches in the same repository, you will be prompted to select which one(s) to upload.
After a successful upload, repo will provide you the URL of a new page on Gerrit (https://androidreview.googlesource.com/). Visit this link to view your patch on the review server, add comments, or request specific reviewers for your patch.
Uploading a replacement patch
Suppose a reviewer has looked at your patch and requested a small modification. You can amend your commit within git, which will result in a new patch on gerrit with the same change ID as the original.
Note that if you have made other commits since uploading this patch, you will need to manually move your git HEAD.
When you upload the amended patch, it will replace the original on gerrit and in your local git history.
Resolving sync conflicts
If other patches are submitted to the source tree that conflict with yours, you will need to rebase your patch on top of the new HEAD of the source repository. The easy way to do this is to run
This command first fetches the updates from the source server, then attempts to automatically rebase your HEAD onto the new remote HEAD.
If the automatic rebase is unsuccessful, you will have to perform a manual rebase.
Using git mergetool may help you deal with the rebase conflict. Once you have successfully merged the conflicting files,
$ repo upload
$ git add -A $ git commit --amend
$ repo sync
$ repo rebase
2017/5/23 Submitting Patches | Android Open Source Project
https://source.android.com/source/submit-patches 4/7
After either automatic or manual rebase is complete, run repo upload to submit your rebased patch.
After a submission is approved
After a submission makes it through the review and verification process, Gerrit automatically merges the change into the public repository. Other users will be able to run repo sync to pull the update into their local client.
For reviewers and verifiers
Reviewing a change
If you are assigned to be the Approver for a change, you need to determine the following:
Does this change fit within this project's stated purpose? Is this change valid within the project's existing architecture? Does this change introduce design flaws that will cause problems in the future? Does this change follow the best practices that have been established for this project? Is this change a good way to perform the described function? Does this change introduce any security or instability risks?
If you approve of the change, mark it with LGTM ("Looks Good to Me") within Gerrit.
Verifying a change
If you are assigned to be the Verifier for a change, you need to do the following:
Patch the change into your local client using one of the Download commands. Build and test the change. Within Gerrit use Publish Comments to mark the commit as "Verified" or "Fails," and add a message explaining what problems were identified.
Downloading changes from Gerrit
$ git rebase --continue
2017/5/23 Submitting Patches | Android Open Source Project
https://source.android.com/source/submit-patches 5/7
A submission that has been verified and merged will be downloaded with the next repo sync. If you wish to download a specific change that has not yet been approved, run
where TARGET is the local directory into which the change should be downloaded and CHANGE is the change number as listed in Gerrit (https://androidreview.googlesource.com/). For more information, see the Repo reference (https://source.android.com/source/usingrepo.html).
How do I become a Verifier or Approver?
In short, contribute highquality code to one or more of the Android projects. For details about the different roles in the Android Open Source community and who plays them, see Project Roles (https://source.android.com/source/roles.html).
Diffs and comments
To open the details of the change within Gerrit, click on the "Id number" or "Subject" of a change. To compare the established code with the updated code, click the file name under "Sidebyside diffs."
Adding comments
Anyone in the community can use Gerrit to add inline comments to code submissions. A good comment will be relevant to the line or section of code to which it is attached in Gerrit. It might be a short and constructive suggestion about how a line of code could be improved, or it might be an explanation from the author about why the code makes sense the way it is.
To add an inline comment, doubleclick the relevant line of the code and write your comment in the text box that opens. When you click Save, only you can see your comment.
To publish your comments so that others using Gerrit will be able to see them, click the Publish Comments button. Your comments will be emailed to all relevant parties for this change, including the change owner, the patch set uploader (if different from the owner), and all current reviewers.
Upstream Projects
$ repo download TARGET CHANGE
2017/5/23 Submitting Patches | Android Open Source Project
https://source.android.com/source/submit-patches 6/7
Android makes use of a number of other open source projects, such as the Linux kernel and WebKit, as described in Codelines, Branches, and Releases (https://source.android.com/source/codelines.html). For most projects under external/, changes should be made upstream and then the Android maintainers informed of the new upstream release containing these changes. It may also be useful to upload patches that move us to track a new upstream release, though these can be difficult changes to make if the project is widely used within Android like most of the larger ones mentioned below, where we tend to upgrade with every release.
One interesting special case is bionic. Much of the code there is from BSD, so unless the change is to code that's new to bionic, we'd much rather see an upstream fix and then pull a whole new file from the appropriate BSD. (Sadly we have quite a mix of different BSDs at the moment, but we hope to address that in future, and get into a position where we track upstream much more closely.)
ICU4C
All changes to the ICU4C project at external/icu4c should be made upstream at icuproject.org/ (http://site.icuproject.org/). See Submitting ICU Bugs and Feature Requests (http://site.icuproject.org/bugs) for more.
LLVM/Clang/Compilerrt
All changes to LLVMrelated projects (external/clang, external/compiler-rt, external/llvm) should be made upstream at llvm.org/ (http://llvm.org/).
mksh
All changes to the MirBSD Korn Shell project at external/mksh should be made upstream either by sending an email to mirosmksh on the mirbsd.org domain (no subscription required to submit there) or (optionally) at Launchpad (https://launchpad.net/mksh).
OpenSSL
All changes to the OpenSSL project at external/openssl should be made upstream at openssl.org (http://www.openssl.org).
V8
2017/5/23 Submitting Patches | Android Open Source Project
https://source.android.com/source/submit-patches 7/7
All changes to the V8 project at external/v8 should be submitted upstream at code.google.com/p/v8 (https://code.google.com/p/v8). See Contributing to V8 (https://code.google.com/p/v8/wiki/Contributing) for details.
WebKit
All changes to the WebKit project at external/webkit should be made upstream at webkit.org (http://www.webkit.org). The process begins by filing a WebKit bug. This bug should use Android for the Platform and OS fields only if the bug is specific to Android. Bugs are far more likely to receive the reviewers' attention once a proposed fix is added and tests are included. See Contributing Code to WebKit (http://webkit.org/coding/contributing.html) for details.
zlib
All changes to the zlib project at external/zlib should be made upstream at zlib.net (http://zlib.net).
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License (http://creativecommons.org/licenses/by/3.0/), and code samples are licensed under the Apache 2.0 License (http://www.apache.org/licenses/LICENSE2.0). For details, see our Site Policies (https://developers.google.com/terms/sitepolicies). Java is a registered trademark of Oracle and/or its affiliates.
上 次 更 新 日 期 ： 三 月 27, 2017 -
264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
