パッチの送信

このページでは、Android オープンソース プロジェクト（AOSP）にパッチを送信する全プロセスについて説明します。これには、Gerrit を使用してレビューをリクエストする方法や変更を追跡する方法も含みます。

前提条件

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

• ビルド環境の初期化
• ソースのダウンロード
• パスワード生成ツールでのパスワードの作成

リソース

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

コントリビューターの手順

サーバーで認証する

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

Repo ブランチを開始する

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

repo start NAME .

同じリポジトリ内で、独立した複数のブランチを同時に開始できます。ブランチの NAME はワークスペースに対してローカルで、Gerrit または最終的なソースツリーには含まれません。

変更を行う

ソースファイルを変更し、変更を検証します。

以下のコマンドを使用して、ローカル リポジトリに変更を commit します。

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.

commit の適切な説明（および例）に関するブログについては、Chris Beams による How to Write a Git Commit Message をご覧ください。

Gerrit にアップロードする

個人履歴に変更を commit したら、次のコマンドを使用して Gerrit にアップロードします。

repo upload

同じリポジトリ内で複数のブランチを開始した場合は、アップロード先のブランチを選択するよう求められます。

アップロードが正常に完了すると、新しいページの URL が Gerrit に表示されます。Repo から提供されたこのリンクをクリックすると、レビュー サーバーでのパッチの表示、コメントの追加、特定のレビュー担当者へのパッチのリクエストなどを行えます。

レビューをリクエストする

変更を Gerrit にアップロードしたら、適切なコード所有者によるパッチのレビューと承認が必要になります。OWNERS ファイルでコード所有者を見つけます。

適切なコード所有者を見つけ、変更のレビュー担当者として追加する手順は次のとおりです。

1. Gerrit UI で [SUGGEST OWNERS] リンクを選択すると、パッチ内のファイルのコード所有者のリストが表示されます。

   

2. パッチのレビュー担当者として、リストからコード所有者を追加します。

パッチ内のファイルのステータスを確認するには、パッチ内のファイルの横にある次のアイコンを確認します。

• done（チェックマーク アイコン）: コード所有者によって承認されています
• clear（クロスアイコン）: コード所有者によって承認されていません
• access_time（時計アイコン）: コード所有者による承認待ちです

置換パッチをアップロードする

レビュー担当者によるパッチの審査の結果、小規模な変更を要求されたとします。その場合、Git 内で commit を修正できます。これにより、オリジナルと同じ変更 ID の新しいパッチが Gerrit に作成されます。

git add -A
git commit --amend

修正したパッチをアップロードすると、Gerrit 上とローカルの Git 履歴内両方のオリジナルのパッチが上書きされます。

同期の競合を解決する

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

repo sync

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

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

repo rebase

リベースの競合を解決するもう 1 つのツールは、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）の変更をすべて行います。