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

Switch to English

Android デベロッパー Codelab

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

その道は困難ではありますが、Android チームは、リリースごとにお客様の取り組みを簡素化するよう努めています。また、チームは Android オープンソースプロジェクト (AOSP) での直接作業を通じて日々改善を行っています。

さあ、座ってターミナルを起動し、歴史を作りましょう。

目標

このコードラボの使命は 2 つあります。

プラットフォーム (オペレーティングシステム) で作業する Android エンジニアにとって、開発者のワークフローがどのようなものかを少し味わってみましょう。
Android のツール、ドキュメント、開発者のワークフローに関するフィードバックを提供することをお勧めします。

前提条件

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

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

環境

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

ワークステーションをセットアップする

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

ホームディレクトリに移動します。
```
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は、ユーザーが仮想 Android デバイス (この場合は Cuttlefish) を作成するのを支援する AOSP のコマンドラインツールです。

コードのビルドに使用したのと同じターミナルセッションにいる場合は、次に進みます。それ以外の場合は、 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.色の変更が成功した後の画面の外観

コードをテストする

コードラボのこの部分では、ソースツリーにあるサンプルテストが利用されていますが、失敗しています。これは、テストをローカルで実行し、コードをテストするために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 リポジトリ (またはプロジェクト) で一度に動作するgit cloneなどのコマンドをバンドルすることで、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 main:
  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/main

Gerrit で変更を確認する

ターミナルに表示されている、次のようなリンクに移動します。

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

これで、Android プラットフォーム開発のスターターコードラボが完了しました。次のステップについては「パッチの送信」を参照してください。Android 開発の詳細については、このサイトの残りの部分を参照してください。

変更を元に戻す

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

代わりに、このコードラボの目的のために、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 .

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

助けを得ます

このコードラボ中にエラーが発生した場合は、ページの下部にある問題トラッカーのリンクを使用して報告してください。質問はandroid-buildingグループに送信してください。