Отправка патчей

This page describes the full process of submitting a patch to the Android Open Source Project (AOSP), including reviewing and tracking changes with Gerrit.

Prerequisites

• Before you follow the instructions on this page, you need to initialize your build environment, download the source, create a password, and follow the instructions on the password generator page.

• For details about Repo and Git, see Developing.

• For information about the different roles you can play within the Android Open Source community, see Project roles.

• If you plan to contribute code to the Android platform, read the AOSP licensing information.

• Note that changes to some of the upstream projects used by Android should be made directly to that project, as described in Upstream projects.

For contributors

Authenticating with the server

Before you can upload to Gerrit, you need to establish a password that identifies you with the server. Follow the instructions on the password generator page. You need to do this only once. See Using authentication for additional details.

Starting a Repo branch

For each change that you intend to make, start a new branch within the relevant Git repository:

repo start NAME .

You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and isn't included on Gerrit or in the final source tree.

Making your change

After you've modified the source files (and validated them, please) commit the changes to your local repository:

git add -A
git commit -s

Provide a detailed description of the change in your commit message. This description is pushed to the public AOSP repository, so follow these guidelines for writing changelist descriptions:

• Start with a one-line 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 hard-wrap at 72 characters maximum. Describe 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.

Here's an example commit message:

Short description on first line

More detailed description of your patch,
which is likely to take up multiple lines.

A unique change ID and your name and email as provided during repo init are automatically added to your commit message.

Uploading to Gerrit

After you commit your change to your personal history, upload it to Gerrit with

repo upload

If you've started multiple branches in the same repository, you're prompted to select which ones to upload.

After a successful upload, Repo provides you with the URL of a new page on Gerrit. Visit this link to view your patch on the review server, add comments, or request specific reviewers for your patch.

Requesting a review

After you've uploaded your changes to Gerrit, the patch must be reviewed and approved by the appropriate code owners. Code owners are found in OWNERS files.

To find the appropriate code owners and add them as reviewers for your change:

1. Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

   

2. Add code owners from the list as reviewers for your patch.

To determine the status of the files in your patch, check for the following icons next to the files in the patch.

• done (checkmark icon): Approved by code owner
• clear (cross icon): Not approved by code owner
• access_time (clock icon): Pending approval by code owner

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 results in a new patch on Gerrit with the same change ID as the original.

git add -A
git commit --amend

When you upload the amended patch, it replaces 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 need to rebase your patch on top of the new HEAD of the source repository. The easy way to do this is to run

repo sync

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, perform a manual rebase.

repo rebase

Using git mergetool may help you deal with the rebase conflict. When you've successfully merged the conflicting files, run:

git rebase --continue

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 can run repo sync to pull the update into their local client.

Upstream projects

Android makes use of a number of other open source projects, such as the Linux kernel and WebKit, as described in Android Software Management. For most projects under external/, make the changes upstream and then inform the Android maintainers 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 prefer an upstream fix and then a pull of a whole new file from the appropriate BSD.

Android Kernel

Prefer making all changes upstream. For general guidance, follow the Android Kernel Contribution Guidelines.

ICU4C

Make all changes to the ICU4C project at external/icu4c on the ICU-TC Home Page. See Submitting ICU Bugs and Feature Requests for more.

LLVM/Clang/Compiler-rt

Make all changes to LLVM-related projects (external/clang, external/compiler-rt, external/llvm) on the LLVM Compiler Infrastructure page.

mksh

Make all changes to the MirBSD Korn Shell project at external/mksh either by sending an email to miros-mksh on the mirbsd.org domain (no subscription required to submit there) or at Launchpad.

OpenSSL

Make all changes to the OpenSSL project at external/openssl on the OpenSSL page.

V8

Submit all changes to the V8 project at external/v8 on the V8 issue page. See Contributing to V8 for details.

WebKit

Make all changes to the WebKit project at external/webkit on the WebKit page. Start the process by filing a WebKit bug. In the bug, 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 after a proposed fix is added and tests are included. See Contributing Code to WebKit for details.

zlib

Make all changes to the zlib project at external/zlib on the zlib home page.