コードの変更を送信する

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

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

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

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

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

ブランチを開始する

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

関連する Git リポジトリ内で新しいブランチを開始します。ブランチは、オリジナルファイルのコピーではありません。ローカルブランチ作成やブランチ間での切り替えの操作を軽量化するための、特定の commit へのポインタです。ブランチを使用すると、変更同士を識別することができます。ブランチを開始するには、以下のコマンドを実行します。
```
repo start BRANCH_NAME
```
同じリポジトリ内で、独立した複数のブランチを同時に開始できます。ブランチの BRANCH_NAME はワークスペースに対してローカルで、Gerrit または最終的なソースツリーには含まれません。また、ブランチは、変更を加えるプロジェクトに固有のものでもあるため、同じ変更の一環として異なるプロジェクト内のファイルを変更する必要がある場合は、ファイルを変更するプロジェクトごとにブランチが必要となります。
（省略可）ブランチが作成されたことを確認します。
```
repo status .
```
新たに作成されたブランチが表示されます。次に例を示します。
```
project frameworks/native/                      branch mynewbranch
```
注: repo branches を使用してすべてのブランチのリストを表示することもできます。この場合、現在のブランチ（ある場合）の前にアスタリスク（*）が付きます。

変更を加えてテストする

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

最新のコードベースを扱っていることを確認するには、コードベース全体の同期を行います。
```
repo sync
```
注: 現在のプロジェクトのみを同期するには、repo sync コマンドにピリオド（.）を追加します（repo sync .）。リポジトリ全体の同期よりも現在のプロジェクトのみの同期の方が速く完了します。

同期の際に競合が発生した場合は、同期の競合を解決するのステップ 2～4 をご覧ください。
変更するコードを探します。コードを探すには、Android ソースコード検索を使用することをおすすめします。Android ソースコード検索は、AOSP のソースコードを実際に使用したときの配置を確認できるツールです。詳しくは、ソースコード検索を使ってみるをご覧ください。Android ソースコード検索内で main ブランチのコードをすべて表示するには、https://cs.android.com/android/platform/superproject/main に移動します。
ソースファイルを変更、追加します。変更の種類を問わず、以下に従ってください。
- 機能リリースフラグを使う必要があるか検討し、必要があれば新しいコードに実装してください。
- ライセンスヘッダーを含めるに記載されているおすすめの方法に従ってください。
- Java コードの場合は、コントリビューター向け AOSP Java コードスタイルに従ってください。
- AOSP の一部は Kotlin（.kt）で記述されています。Kotlin ですでに記述されているプラットフォームの部分では Kotlin を使用できます。Android 内で Kotlin を使用する方法については、Android デベロッパーの Kotlin スタイルガイドと Kotlin-Java 相互運用ガイドをご覧ください。Kotlin の詳細なガイダンスについては、Kotlin 言語のサイトをご覧ください。
- API を記述する場合は、Android API ガイドラインをご覧ください。このガイドラインでは、Android の API に関する意思決定の背景が説明されています。プラットフォーム API の追加と変更は、Metalava によって検証されています。
Android をビルドします。
ビルドをテストします。

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

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

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

注: 特定のファイルのみの変更を追跡するには、git add filename を使用します。
注: ファイルの変更を追跡するほか、git add では、ファイルの変更や削除のステージングなど、その他の操作も行えます。
ステージングエリアにファイルを移行するか、ローカルデータベースにファイルを commit または保存します。
```
git commit -s
```
デフォルトでは、テキストエディタが開き、commit メッセージを入力するよう求めるメッセージが表示されます。
commit メッセージの入力形式は次のとおりです。
- 1 行目: 見出し。変更の概要を 1 行で入力します（最大 50 文字）。接頭辞を使用して変更した範囲を示し、その後にこの commit で加えた変更の説明を続けることをおすすめします。たとえば、次の例にはユーザーインターフェースの変更が含まれています。
```
ui: Removes deprecated widget
```
- 行 2: 空白行。見出しの行の後に空白行を入れます。
- 3 行目: 本文。長い説明を入力します。最大 72 文字でハードラップします。変更によって解決する問題とその方法について説明します。本文は省略可能ですが、後で他のユーザーが変更を参照する必要がある場合に役立ちます。他のコントリビューターが同じ機能に取り組む際、重要になると思われる前提条件や背景情報について簡単なメモを必ず残してください。
commit の適切な説明（および例）に関するブログについては、How to Write a Git Commit Message をご覧ください。
commit を保存します。

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

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

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

すべてのプロジェクト内の commit をすべてアップロードするには、以下のコマンドを実行します。
```
repo upload
```
アップロードには、すべてのプロジェクトにおけるすべての変更が含まれます。

注: 現在のプロジェクトの変更のみをアップロードするには、repo upload コマンドにピリオド（.）を追加します（repo upload .）。
注: 複数のプロジェクト内のファイルを変更する必要がある変更に取り組んでいる場合は、repo upload、repo upload . を問わず、Gerrit でトピックを使用して変更をまとめます。Gerrit のトピックによって、presubmit テストおよび automerger の適用のために変更をまとめることができます。詳しくは、トピックの使用をご覧ください。

フックスクリプトの実行を求めるメッセージが表示されます。
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)?
```
注: 同じリポジトリ内で複数のブランチを開始した場合は、テキストエディタでこれらのブランチのコメント化を解除してアップロードするブランチを選択するよう求めるメッセージが表示されます。
y キー、Enter キーの順に押してアップロードを承認します。

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

審査をリクエストする

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

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

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

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

注: どのように所有者を判断するかについては、find-owners バックエンドを参照してください。

[SEND] ボタンが有効になります。
（省略可）変更を審査してもらいたい人のメールアドレスを入力します。
（省略可）[Autosubmit] の横の [+1] をクリックすると、承認後に変更が自動的に送信されます。このボタンをクリックしなかった場合は、Google 社員が変更を送信しなければならなくなります。
[SEND] をクリックして変更を審査に送信します。

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

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

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

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

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

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

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

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

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

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

変更を加えてテストするのステップ 2～4 を行います。
変更を修正するには、以下のコマンドを実行します。
```
git add -A
git commit --amend
```
変更をアップロードします。

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

同期の競合を解決する

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

最新のコードベースを扱っていることを確認します。
```
repo sync .
```
repo sync コマンドは、ソースサーバーからアップデートを取得した後、HEAD を新しいリモート HEAD に自動的にリベースしようと試みます。
自動リベースに失敗した場合は、手動で実行します。
```
repo rebase .
```
マージの競合を解決します。マージの競合を解決するためのおすすめの方法がない場合は、git mergetool を使用してファイル間の競合を手動で修正できます。
競合するファイルを修正し終えたら、以下のコマンドを実行して新しい commit を適用します。
```
git rebase --continue
```

変更を送信する

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

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