Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

パッチの送信

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

要件

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

サーバーで認証する

Gerrit にアップロードする前に、ユーザーを識別するために、サーバーでパスワードを設定する必要があります。パスワード生成ツールのページの手順に沿って操作します。この操作は 1 回だけ行う必要があります。詳しくは、認証の使用についての説明をご覧ください。

Repo ブランチを開始する

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

repo start NAME .

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

変更を行う

ソースファイルの変更(および検証)が完了したら、ローカル リポジトリに変更を commit します。

git add -A
git commit -s

変更の詳細な説明を commit メッセージに入力します。ここで入力した説明文は、AOSP の公開リポジトリに送信されます。変更リストの説明文に関する以下のガイドラインに従ってください。

  • まず、概要を 1 行(最大 50 文字)で記し、次の 1 行を空けます。この形式は、Git と Gerrit で、さまざまな表示用途に使用されます。

  • 次の 3 行目では、詳細な説明文を入力します。これは 72 文字で強制改行されます。変更によって解決する問題と解決方法について説明します。この 2 つめの説明は、入力することをおすすめしますが、新しい機能を実装する場合は省略可能です。

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

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

Short description on first line

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

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

Gerrit にアップロードする

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

repo upload

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

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

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

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

git add -A
git commit --amend

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

同期の競合を解決する

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

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 から新しいファイルを取得します。

ICU4C

ICU-TC のホームページに掲載されている ICU4C プロジェクト(external/icu4c)の変更をすべて行います。詳しくは、ICU のバグと機能リクエストの送信についての説明をご覧ください。

LLVM/Clang/Compiler-rt

LLVM コンパイラ インフラストラクチャのページに掲載されている LLVM 関連のプロジェクト(external/clangexternal/compiler-rtexternal/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)の変更をすべて行います。