このページは Cloud Translation API によって翻訳されました。

Switch to English

Android デベロッパー Codelab

地球の歴史の中で最も広くインストールされているオペレーティングシステムの開発を支援できます。はい、あなたは Android プラットフォームエンジニアになるための旅に出るためにここにいます。

道のりは険しいですが、Android チームはリリースごとに旅を簡素化するよう努めています。また、チームは Android オープンソースプロジェクト (AOSP) での直接作業を通じて、毎日改善を行っています。

それでは、座って端末を起動し、歴史を作りましょう。

目標

この Codelab のミッションは 2 つあります。

プラットフォーム (オペレーティングシステム) で作業する Android エンジニアの開発者ワークフローがどのようなものかを少し紹介します。
Android のツール、ドキュメント、デベロッパーワークフローに関するフィードバックをお寄せください。

前提条件

この Codelab の要件のリストは、一般的なプラットフォーム ( AOSP ) 開発の要件から派生しています。この Codelab を受講するには、次のように設定します。

すべての公的要件を満たす物理 Linux ワークステーション。
Android コードベースの編集に必要なリポジトリと Git 構成。

環境

通常、ユーザーはワークステーション上で直接ビルドおよび開発します。さまざまな端末で作業している可能性があり、使用するコマンドの多くは端末固有であるため、各端末セッションでコマンドを再実行する必要があります。具体的には、 source build/envsetup.shおよびlunchコマンドが含まれます。

ワークステーションのセットアップ

ワークステーションに必要なパッケージをインストールします。
まだターミナルにいる間にRepo をインストールし、すべての Git リポジトリへの資格情報を取得します。

コードを初期化して同期する

ホームディレクトリに移動します。
```
cd ~
```
その中にローカル作業サブディレクトリを作成します。
```
mkdir aosp
```
ディレクトリに移動します。
```
cd aosp
```
AOSP リポジトリソースコードのマスターブランチを初期化します (デフォルト)。
```
repo init -u https://android.googlesource.com/platform/manifest
```
Git 資格情報 (名前、メールアドレス) を入力するか、受け入れます。
ソースコードを同期します。
```
repo sync -j8
```

最初の同期には 1 時間以上かかる場合があります。

各リポジトリチェックアウトは、マニフェストファイルによって表されます。別々のディレクトリに存在する限り、一度に複数のリポジトリチェックアウトを行うことができます。ただし、各チェックアウトとビルドは約 300 GB の使用量 (および増加中) になることに注意してください。そのため、リポジトリのチェックアウトを 2 つに制限するか、セカンダリドライブでシステムを増強してください。

ヒント: 空き容量を増やすには、ブランチディレクトリを削除し、次のようにディレクトリの作成からやり直します: rm -rf aosp2.

コードをビルドする

Android をビルドするには、 lunchコマンドでビルドするターゲットデバイスタイプを選択する必要があります。ターゲットは、特定のモデルやフォームファクターなどのデバイス順列です。

以下に含まれるデバイスターゲットaosp_cf_x86_64_phone-userdebug 、物理デバイスなしでテスト用のCuttlefish仮想 Android デバイスを構築できます。

代わりに物理デバイスをビルドして更新するには、別のターゲットを選択し、フラッシュデバイスの手順に従います。

ソースコードチェックアウトのルートから次のコマンドを実行して、Android デバイスを構築するための環境をセットアップします。
```
source build/envsetup.sh
```
次のように、ビルドターゲットを lunch コマンドに渡します。
```
lunch aosp_cf_x86_64_phone-userdebug
```
以下を使用して、チェックアウトのどこからでもコードをビルドします。
```
m
```

最初のビルドには数時間かかることが予想されます。後続のビルドにかかる時間は大幅に短縮されます。

Acloud インスタンスを作成する

Acloudは AOSP のコマンドラインツールで、ユーザーが仮想 Android デバイス (この場合は Cuttlefish) を作成するのを支援します。

コードのビルドに使用したのと同じターミナルセッションにいる場合は、続行します。それ以外の場合は、 envsetup.shスクリプトと、最初に使用したものと同じlunchコマンドを再実行します。それから

以下を使用して Acloud ローカルインスタンスを作成します。
```
acloud create --local-image --local-instance
```
必要なパッケージの更新を受け入れます。
プロンプトが表示されたら、すべての変更を有効にするためにワークステーションを再起動します。
Cuttlefish デバイスを選択します。

Android デバイスを含む VNC セッションが表示されます。

マウスとキーボードを使用して、ワークステーション上の仮想デバイスを操作できます。 Android Debug Bridge (adb) logcatコマンドを使用して、デバイスの使用中にログ内のアクティビティを追跡することもできます。

adb logcat

変える

このサンプルチェンジリストに従ってソースコードを更新します。

チェックアウトのルート ( aosp/ディレクトリ) から、 frameworks/native Git プロジェクトに移動します。
```
cd frameworks/native
```
次のコマンドで一時プロジェクトを開始します。
```
repo start <some-name> .
```
SurfaceFlinger.cppを編集して、次の場所にある変更リストからの更新を含めます。
```
aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
```
次の行を見つけます。
```
postComposition();
```

これらの 2 行を次のように置き換えます。

postComposition();
mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f},
                          vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});
updateColorMatrixLocked();

コードをビルドします。
```
m
```

デバイスのビルドを更新します。

adb root
adb remount
adb sync
adb reboot
acloud reconnect

デバイスの選択を求められた場合は、経過時間が最も短いデバイスを選択します。 (これはおそらく、表示されるリストの最後のものです。) すべての仮想デバイスインスタンスを表示するには、 acloud listおよびacloud list -vコマンドを使用します。

選択したデバイスで、図 1 に示すような色の変化が見られることを確認します。

Example of a successful color change

図 1.色の変更が成功した後の画面の外観

コードをテストする

Codelab のこの部分では、ソースツリーにあり、失敗しているサンプルテストを使用します。これは、テストをローカルで実行し、コードをテストするためにAtestを使用します。

テストを使用するには、次の手順に従います。

走る：
```
atest DevCodelabTest
```
テストは失敗します。これを修正するには、失敗したテストのソースコードを見つけます。
```
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
```

じゃあここ見て

platform_testing/tests/example/devcodelab

編集するファイルを取得するには、 android.test.example.devcodelab.DevCodelabTestでテストの名前を取得し、 . /を使用して、この結果を取得します。
```
src/android/test/example/devcodelab/DevCodelabTest.java
```

次に編集

platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java

交換する

Assert.assertTrue(false)

と

Assert.assertTrue(true)

テストを再度実行して、問題が修正されたことを確認します。
```
atest DevCodelabTest
```

コードをアップロードしてレビューする

Repo は、 git cloneなどのコマンドをバンドルして多数の Git リポジトリ (またはプロジェクト) で一度に動作させることにより、Git の使用を簡素化します。

Git と Repo の概要については、ソース管理ツールを参照してください。また、Android ソースコードの操作に関する完全なドキュメントへのリンクも含まれています。 Git プロジェクトの完全なリストと、各プロジェクトに関連付けられているブランチの個々のプロジェクト (パス) については、 AOSP リポジトリを参照してください。

Git でのプロジェクトのコードレビューには、 Gerrit のWeb ベースのコードレビューシステムを使用します。

frameworks/nativeプロジェクトで変更を行ったと仮定して、次のコマンドを実行してアップロードします。
```
cd frameworks/native
repo start codelab .
git add .
git commit
```
コミットメッセージには、次のように入力します。
```
Android codelab change
Test: manual atest
```
変更をアップロードします。
```
repo upload
```

成功すると、次のようなメッセージが表示されます。

Upload project frameworks/native/ to remote branch master:
  branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
         ff46b36d android codelab change
to https://android-review.googlesource.com/ (y/N)? y
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote:   https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android codelab change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
 * [new branch]          codelab -> refs/for/master

Gerrit で変更を表示する

ターミナルに出力された、次のようなリンクに移動します。

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

これで、Android プラットフォーム開発のスターター Codelab は完了です。次のステップについてはパッチの送信を参照してください。Android の開発に関する詳細については、このサイトの残りの部分を参照してください。

変更を元に戻す

通常、テスト後、レビューと承認後、Gerrit で変更を送信し、リポジトリにマージします。

代わりに、この Codelab の目的のために、Gerrit で[破棄]をクリックして変更リストを元に戻します。

次に、 frameworks/nativeプロジェクトディレクトリ (またはそのサブディレクトリ) 内の関連する一時ブランチを破棄します。

repo abandon codelab .

また、テストファイルに加えた変更を元に戻すことも忘れないでください。変更をrepo start 、 git commit 、およびrepo uploadなかったため、ファイル自体をリセットできます。 aosp/platform_testing directoryにいると仮定して、次のコマンドを使用してファイルをリセットします。

git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .

この時点で、完了です。よくやった！

助けを得ます

この Codelab でエラーが発生した場合は、ページの下部にあるIssue Trackerリンクを使用して報告してください。 android-buildingグループに質問を送ってください。