パッチを送信する

このページでは、Android オープンソース プロジェクト（AOSP）にパッチを送信する完全なプロセスについて説明します。Gerrit を使用して審査をリクエストする方法や変更を追跡する方法も紹介します。Gerrit は、Git を使用するプロジェクトを対象としたウェブベースのコード審査システムです。Gerrit を利用することで、すべての認定ユーザーが変更内容を送信できるようになり、Git の使用が一元化されます（変更内容は、コード審査を通過すると自動的にマージされます）。また、Gerrit を利用すると、変更箇所がブラウザ内で並べて表示され、インライン コメントも可能になるため、審査が容易になります。

前提条件

はじめに、以下のことが完了していることを確認します。

リソース

  • Repo と Git の詳細については、ソース管理ツールのページをご覧ください。
  • Android オープンソース コミュニティ内のさまざまな役割については、プロジェクトにおける役割をご覧ください。
  • Android プラットフォームへのコードの提供に関するライセンス情報については、ライセンスのページをご覧ください。

Git を設定する

Gerrit を使用するには、登録されている Google アカウントにメールアドレスが関連付けられている必要があります。次のコマンドを実行して、登録されている Google アカウントに関連付けられた名前とメールアドレスで Git を設定します。

git config --global user.name Your Name
git config --global user.email your_email@gmail.com

サーバーで認証する

IP アドレスを他のユーザーと共有している場合、通常の使用パターンであっても割り当てがトリガーされることがあります。これは、たとえば、短期間のうちに多数のユーザーが同じ IP アドレスから新しいクライアントを同期する場合などに発生することがあります。認証済みアクセスでは、IP アドレスに関係なく、ユーザーごとに個別の割り当てが使用されます。認証済みアクセスを有効にする方法については、認証の使用をご覧ください。

Repo ブランチを開始する

次のコマンドを使用して、1 つの変更ごとに、関連する Git リポジトリ内で新しいブランチを開始します。 

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 either on Gerrit or in the final source tree.

Make your change

Modify the source files, and test your changes.

For any changes made, follow License header best practices.

Commit your change

Commit the changes to your local repository with these commands:

git add -A
git commit -s

変更の説明

  • 1 行目: 見出し

    概要を 1 行で入力します（最大 50 文字）

    この形式は、Git と Gerrit で、さまざまな表示用途に使用されます。commit メッセージの特に重要で内容の濃い部分です。接頭辞を使用して変更した範囲を記述し、その後にこの commit で加えた変更の説明を続けることをおすすめします。たとえば次の例では、接頭辞として ui が付いています。

    ui: Removes deprecated widget

  • 2 行目: 空白

    この行は常に空白のままにします。

  • 3 行目: 本文

    この行から、詳細な説明文を記述します。

    これは 72 文字で強制改行されます。変更によって解決する問題とその方法について説明します。これは新しい機能の実装時には省略可能ですが、後で他のユーザーがこの変更を参照する場合、特にデバッグでは、非常に役に立ちます。

    他のコントリビューターが同じ機能に取り組む際、重要になると思われる前提条件や背景情報について簡単なメモを残してください。

固有の変更 ID、コントリビューターの名前、メールアドレスを repo init の際に入力すると、commit メッセージに自動的に追加されます。

commit メッセージの例を以下に示します。

Line 1, Headline - a short description

Line 3, Body - Add the detailed description of your patch here. Use as many lines
as needed. You can write an overall description, then list specifics.

I6e3c64e7a:Added a new widget.
I60c539a8f:Fixed the spinning image.
To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.

Upload to Gerrit

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

repo upload

If you 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. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.

Request a review

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

To find the appropriate code owners and add them as reviewers for your change, follow these steps.

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

    suggest owners link in Gerrit
    Figure 1. Suggest owners link in Gerrit

  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.

  • (checkmark icon): Approved by code owner
  • (cross icon): Not approved by code owner
  • (clock icon): Pending approval by code owner
Figure 2. Example of files with icons showing code owner approval status

Upload a replacement patch

Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the original. 

git add -A
git commit --amend

修正したパッチをアップロードすると、Gerrit 上とローカル Git 履歴内にある元のパッチの両方が置き換えられます。

同期の競合を解決する

競合する他のパッチがソースツリーに送信された場合は、自分のパッチをソース リポジトリの新しい HEAD 上にリベースします。これを行うには、次のコマンドを実行します。 

repo sync

repo sync コマンドは、ソースサーバーからアップデートを取得した後、HEAD を新しいリモート HEAD に自動的にリベースしようと試みます。

自動のリベースが失敗した場合は、手動のリベースを実行します。

repo rebase

リベースの競合を解決するもう一つのツールは、git mergetool です。競合するファイルを正常に統合したら、次のコマンドを実行します。 

git rebase --continue

自動または手動でリベースを完了したら、repo upload を実行してリベースしたパッチを送信します。

パッチの承認後

送信後、レビューと検証プロセスを経て、Gerrit により変更が自動的に公開リポジトリに反映されます。他のユーザーは、repo sync を実行して、更新を各ローカル クライアントに反映させます。

アップストリーム プロジェクトの場合

Android のソフトウェア管理で説明されているように、Android は Linux カーネルや WebKit をはじめとするさまざまなオープンソース プロジェクトを利用しています。external/ にあるほとんどのプロジェクトの場合、変更をアップストリームで渡した後、変更を含む新しいアップストリーム リリースの存在を Android の管理者に通知する必要があります。

また、新しいアップストリーム リリースが追跡されるようにするパッチをアップロードすることをおすすめします。ただし、プロジェクトが Android 内で広く使われていると、変更が難しくなる場合があります。たとえば、次に述べる比較的大規模なものの多くは、通常はリリースごとにアップグレードされます。

Bionic は、特殊かつ興味深い例です。コードの多くが BSD のもののため、コードの変更が Bionic にとって新しいものでなければ、アップストリームの修正を行ってから、適切な BSD から新しいファイルを取得します。

Android カーネル

すべての変更をアップストリームで行います。一般的なガイダンスについては、Android カーネル貢献ガイドラインと GKI のカーネルコードの開発のページをご覧ください。

ICU

ICU-TC ホームページに掲載されている ICU プロジェクトの external/icu（icu4c/ フォルダと icu4j/ フォルダ）の変更をすべて行います。詳しくは、ICU のバグと機能リクエストの送信についての説明をご覧ください。すべてのアップストリーム Jira リクエストに「android」というラベルを追加します。

CLDR

ICU の言語データのほとんどは、Unicode CLDR プロジェクトから提供されています。CLDR への投稿についての説明に沿ってすべてのリクエストをアップストリームで送信し、「android」というラベルを追加します。

LLVM / Clang / Compiler-rt

LLVM コンパイラ インフラストラクチャのページに掲載されている LLVM 関連のプロジェクト（external/clang、external/compiler-rt、external/llvm）の変更をすべて行います。

mksh

MirBSD Korn シェル プロジェクト（external/mksh）の変更をすべて行います（mirbsd.org ドメインで miros-mksh にメールを送信するか（登録は不要）、Launchpad で変更を行います）。

OpenSSL

OpenSSL のページに掲載されている OpenSSL プロジェクト（external/openssl）の変更をすべて行います。

V8

V8 の問題ページに掲載されている V8 プロジェクト（external/v8）の変更をすべて行います。詳しくは、V8 への投稿についての説明をご覧ください。

Webkit

WebKit のページに掲載されている WebKit プロジェクト（external/webkit）の変更をすべて行います。まず、WebKit のバグを報告します。Android に固有のバグの場合にのみ、[Platform] フィールドと [OS] フィールドで Android を使用します。修正を提案し、テストを含めると、バグがレビュー担当者に注目される可能性が非常に高くなります。詳しくは、WebKit へのコードの投稿についての説明をご覧ください。

zlib

zlib のホームページに掲載されている zlib プロジェクト（external/zlib）の変更をすべて行います。