コードの変更を送信する

このページでは、Android オープンソース プロジェクト（AOSP）にコード変更を送信する完全なプロセスについて説明します。審査をリクエストする方法や変更を追跡する方法も紹介します。

AOSP は、Git を使用するプロジェクトを対象としたウェブベースのコード審査システムである Gerrit を利用しています。

コントリビューター ライセンス契約に署名する

AOSP のコード変更を提供するには、コントリビューター ライセンス契約とライセンス ヘッダーをご覧のうえ、以下の契約のいずれかに署名する必要があります。

• 個人のコントリビューターとして、自分のみが使用するコードを提供する場合は、個人コントリビューター ライセンス契約に署名してください。
• 企業の従業員である場合は、所属する企業が企業コントリビューター ライセンス契約に署名し、企業の代表としてのコードの提供が承認されていることを確認してください。

ブランチを開始する

予定しているコード変更ごとに、以下の手順を行います。

1. 関連する Git リポジトリ内で新しいブランチを開始します。ブランチは、オリジナル ファイルのコピーではありません。ローカル ブランチ作成やブランチ間での切り替えの操作を軽量化するための、特定の commit へのポインタです。ブランチを使用すると、変更同士を識別することができます。ブランチを開始するには、以下のコマンドを実行します。

   repo start BRANCH_NAME
   

   同じリポジトリ内で、独立した複数のブランチを同時に開始できます。ブランチの BRANCH_NAME はワークスペースに対してローカルで、Gerrit または最終的なソースツリーには含まれません。また、ブランチは、変更を加えるプロジェクトに固有のものでもあるため、同じ変更の一環として異なるプロジェクト内のファイルを変更する必要がある場合は、ファイルを変更するプロジェクトごとにブランチが必要となります。

2. （省略可）ブランチが作成されたことを確認します。

   repo status .
   

   新たに作成されたブランチが表示されます。次に例を示します。

   project frameworks/native/                      branch mynewbranch
   

変更を加えてテストする

変更を加えてテストする手順は次のとおりです。

1. 最新のコードベースを扱っていることを確認するには、コードベース全体の同期を行います。

   repo sync
   

   同期の際に競合が発生した場合は、同期の競合を解決するのステップ 2～4 をご覧ください。

2. 変更するコードを探します。コードを探すには、Android ソースコード検索を使用することをおすすめします。Android ソースコード検索は、AOSP のソースコードを実際に使用したときの配置を確認できるツールです。詳しくは、ソースコード検索を使ってみるをご覧ください。Android ソースコード検索内で main ブランチのコードをすべて表示するには、https://cs.android.com/android/platform/superproject/main に移動します。

3. ソースファイルを変更、追加します。変更の種類を問わず、以下に従ってください。

   • ライセンス ヘッダーを含めるに記載されているおすすめの方法に従ってください。

   • Java コードの場合は、コントリビューター向け AOSP Java コードスタイルに従ってください。

   • AOSP の一部は Kotlin（.kt）で記述されています。Kotlin ですでに記述されているプラットフォームの部分では Kotlin を使用できます。Android 内で Kotlin を使用する方法については、Android デベロッパーの Kotlin スタイルガイドと Kotlin-Java 相互運用ガイドをご覧ください。Kotlin の詳細なガイダンスについては、Kotlin 言語のサイトをご覧ください。

   • API を記述する場合は、Android API ガイドラインをご覧ください。このガイドラインでは、Android の API に関する意思決定の背景が説明されています。プラットフォーム API の追加と変更は、Metalava によって検証されています。

4. Android をビルドします。

5. ビルドをテストします。

変更をステージングして commit する

commit は、Git のリビジョン管理の基本単位で、プロジェクト全体のディレクトリ構造とファイルの内容のスナップショットです。変更を commit する手順は次のとおりです。

1. Git は行われた変更をデフォルトで登録しますが、追跡することはありません。変更を追跡するよう Git に指示するには、該当する変更をマークするかステージングして、commit に含める必要があります。変更をステージングするには、以下のコマンドを実行します。

   git add -A
   

   このコマンドで、ファイルに加えた変更を追跡できます。

2. ステージング エリアにファイルを移行するか、ローカル データベースにファイルを commit または保存します。

   git commit -s
   

   デフォルトでは、テキスト エディタが開き、commit メッセージを入力するよう求めるメッセージが表示されます。

3. commit メッセージの入力形式は次のとおりです。

   • 1 行目: 見出し。変更の概要を 1 行で入力します（最大 50 文字）。接頭辞を使用して変更した範囲を示し、その後にこの commit で加えた変更の説明を続けることをおすすめします。たとえば、次の例にはユーザー インターフェースの変更が含まれています。

     ui: Removes deprecated widget
     

   • 行 2: 空白行。見出しの行の後に空白行を入れます。

   • 3 行目: 本文。長い説明を入力します。最大 72 文字でハードラップします。変更によって解決する問題とその方法について説明します。本文は省略可能ですが、後で他のユーザーが変更を参照する必要がある場合に役立ちます。他のコントリビューターが同じ機能に取り組む際、重要になると思われる前提条件や背景情報について簡単なメモを必ず残してください。

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

4. commit を保存します。

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

審査のために変更をアップロードする

個人の Git 履歴に変更を commit した後、Gerrit にアップロードします。

1. すべてのプロジェクト内の commit をすべてアップロードするには、以下のコマンドを実行します。

   repo upload
   

   アップロードには、すべてのプロジェクトにおけるすべての変更が含まれます。

   フック スクリプトの実行を求めるメッセージが表示されます。

2. a キー、Enter キーの順に押します。

   アップロードの承認を求めるメッセージが表示されます。

   Upload project frameworks/native/ to remote branch main:
   branch BRANCH_NAME ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
          ff46b36d android codelab change
   to https://android-review.googlesource.com/ (y/N)?
   

3. y キー、Enter キーの順に押してアップロードを承認します。

remote: SUCCESS のようなメッセージが表示されます。

審査をリクエストする

アップロードが正常に完了すると、Repo から提供された変更のリンクが Gerrit に表示されます。このリンクをクリックすると、審査サーバーでの変更が表示されます。また、コメントを追加したり、変更について特定の審査担当者をリクエストしたりできます。コードの変更はすべて、適切なコード所有者の審査を受ける必要があります。審査をリクエストする手順は次のとおりです。

1. Gerrit で [SUGGEST OWNERS] をクリックします。

   

   図 1. Gerrit で所有者リンクを提案する。

   審査担当者ダイアログが表示されます。このダイアログには、変更を審査できるコード所有者のリストが表示されます。

2. コード所有者をクリックすると、審査に追加されます。

   [SEND] ボタンが有効になります。

3. （省略可）変更を審査してもらいたい人のメールアドレスを入力します。

4. （省略可）[Autosubmit] の横の [+1] をクリックすると、承認後に変更が自動的に送信されます。このボタンをクリックしなかった場合は、Google 社員が変更を送信しなければならなくなります。

5. [SEND] をクリックして変更を審査に送信します。

コード所有者がコードの変更を審査します。問題がある場合はフィードバックが提供されて解決するよう求められ、問題がなければ変更は承認されます。

変更のステータスを判断する

変更に含まれるファイルのステータスを確認するには、該当するファイルの横にある以下のアイコンを確認します。

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

以下の図は、変更に含まれるファイルに適用された上記のステータス アイコンを示します。

図 2. コード所有者による承認を示すアイコンが付いたファイルの例。

フィードバックを解決し、上書きする変更をアップロードする

審査担当者から、アップデートの変更が求められた場合は、Git 内の commit を修正します。修正すると、同じ変更に関する新しいパッチセットが生成されます。

フィードバックを解決して変更を修正する手順は次のとおりです。

1. 変更を加えてテストするのステップ 2～4 を行います。

2. 変更を修正するには、以下のコマンドを実行します。

   git add -A
   git commit --amend
   

3. 変更をアップロードします。

修正した変更をアップロードすると、Gerrit 上とローカル Git 履歴内の両方にある元の変更が上書きされます。

同期の競合を解決する

競合する他の変更がソースツリーに送信された場合は、競合が発生したことを示すメッセージが表示されます。競合を解決する手順は次のとおりです。

1. 最新のコードベースを扱っていることを確認します。

   repo sync .
   

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

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

   repo rebase .
   

3. マージの競合を解決します。マージの競合を解決するためのおすすめの方法がない場合は、git mergetool を使用してファイル間の競合を手動で修正できます。

4. 競合するファイルを修正し終えたら、以下のコマンドを実行して新しい commit を適用します。

   git rebase --continue
   

変更を送信する

送信して審査と検証のプロセスが完了したら、Google の審査担当者にコードを送信してもらう必要があります。他のユーザーは、repo sync を実行して、更新を各ローカル クライアントに反映させることができます。

送信がマージされたら、Android 継続的インテグレーション ダッシュボードで、送信内容がいつツリーに統合されたかを確認できます。