Android デベロッパー Codelab

世界で最も広くインストールされているオペレーティング システムの開発を、デベロッパーの皆様の手でサポートできます。ここから、Android プラットフォームのエンジニアになるための第一歩を踏み出すことができます。

その道のりは平坦ではありませんが、Android チームはリリースごとに道を整備して学習が容易になるように努めています。また、Android オープンソース プロジェクト(AOSP)での直接的な取り組みを通じて、日々改善を行っています。

それでは席に着いてターミナルを起動し、学習の旅に出発しましょう。

目標

この Codelab の目的は次の 2 つです。

  1. プラットフォーム(オペレーティング システム)の開発に取り組む Android エンジニアのデベロッパー ワークフローとはどのようなものかを簡単に紹介する。
  2. Android のツール、ドキュメント、デベロッパー ワークフローに関するフィードバックを集める。

要件

この Codelab の要件は、一般的なプラットフォーム(AOSP)開発向けの要件から派生したもので、この Codelab には以下の設定が必要です。

環境

通常、ユーザーはワークステーション上で直接ビルドと開発を行います。ターミナルにはいろいろな種類があり、使用するコマンドの多くはターミナルに固有であることから、新しいターミナル セッションごとに、source build/envsetup.sh コマンドや lunch コマンドをはじめとするコマンドを再実行する必要があります。

ワークステーションの設定

  1. ワークステーションに必要なパッケージをインストールします。
  2. 同じターミナルで Repo をインストールし、すべての Git リポジトリにアクセスするための認証情報を取得します。

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

  1. ホームディレクトリに移動します。

    cd ~
  2. ローカルの作業用サブディレクトリを作成します。

    mkdir aosp
  3. そのディレクトリに移動します。

    cd aosp
  4. AOSP リポジトリのソースコードの main ブランチ(デフォルト)を初期化します。

    repo init -u https://android.googlesource.com/platform/manifest
  5. Git の認証情報(名前、メールアドレス)を入力するか、受け入れます。

  6. ソースコードを同期します。

    repo sync -j8

初回の同期には 1 時間以上かかることがあります。

チェックアウトする各リポジトリは、マニフェスト ファイルで定義します。一度に複数のレポジトリをチェックアウトできるのは、それらが個別のディレクトリに配置される場合に限られます。ただし、すべてのチェックアウトとビルドを合わせると 300 GB 近く(またはそれ以上)の容量を占めるため、リポジトリのチェックアウトは 2 つまでに制限するか、セカンダリ ドライブを増設してださい。

コードをビルドする

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

デバイス ターゲット aosp_cf_x86_64_phone-userdebug の場合、実機なしでテストを行うための Cuttlefish 仮想 Android デバイスをビルドできます。

実機のビルドや更新を行う場合は、それに対応した別のターゲットを選択します。手順については、デバイスをフラッシュするをご覧ください。

  1. Android デバイスのビルド環境をセットアップするには、ソースコード チェックアウトのルートから、以下のコマンドを実行します。

    source build/envsetup.sh
  2. ビルド ターゲットを次のように lunch コマンドに指定します。

    lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
  3. チェックアウト内の任意の場所から、以下のコマンドを使用してコードをビルドします。

    m

初回のビルドが完了するまでには時間がかかります。その後のビルドでは、所要時間は大幅に短縮されます。

Cuttlefish を起動する

Cuttlefish は、ビルドのテストに使用する Android エミュレータです。

  1. Cuttlefish をインストールしたことがない場合は、Cuttlefish の必要な依存関係をインストールする必要があります。ターミナル ウィンドウで以下のコマンドを実行して、Debian パッケージのダウンロード、ビルド、インストールを行います。

    sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
    git clone https://github.com/google/android-cuttlefish
    cd android-cuttlefish
    for dir in base frontend; do
    pushd $dir
    # Install build dependencies
    sudo mk-build-deps -i
    dpkg-buildpackage -uc -us
    popd
    done
    sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
    sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
    sudo usermod -aG kvm,cvdnetwork,render $USER
    sudo reboot

    再起動すると、その他のカーネル モジュールのインストールがトリガーされ、udev のルールが適用されます。

  2. Cuttlefish を起動します。

    launch_cvd --daemon
    
  3. ウェブブラウザで https://localhost:8443 にアクセスして、Cuttlefish デバイスに接続します。構築した Android 搭載デバイスの動画ストリームが表示されます。

変更を加える

このサンプルの変更リストに沿って、ソースコードを更新します。

  1. チェックアウトのルート(aosp/ ディレクトリ)から frameworks/native Git プロジェクトに移動します。

    cd frameworks/native
  2. 次のコマンドを実行して、一時的なプロジェクトを開始します。

    repo start <some-name> .
  3. 次の場所にある SurfaceFlinger.cpp を編集して、変更リストにある更新を含めます。

    aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
    
  4. 次に示す行を探します。

    void SurfaceFlinger::updateColorMatrixLocked() {
    
  5. 次の 2 行を updateColorMatrixLocked() の先頭に追加します。

    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});
    
  6. コードをビルドします。

    m
  7. デバイス上のビルドを更新します。

    adb root
    adb remount
    adb sync
    adb reboot

選択したデバイスの色が変化したことを確認します(図 1 のように表示されます)。

成功した場合の色の変化の例

図 1. 成功した場合の画面上の色の変化

コードをテストする

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

次の手順に沿ってテストを使用します。

  1. 次のコマンドを実行します。

    atest DevCodelabTest
  2. テストは失敗します。失敗したテストのスタック トレースを確認します。

    STACKTRACE:
    java.lang.AssertionError
     at org.junit.Assert.fail(Assert.java:87)
     at org.junit.Assert.assertTrue(Assert.java:42)
     at org.junit.Assert.assertTrue(Assert.java:53)
     at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)
  3. 返された情報から次のディレクトリを確認します。

    platform_testing/tests/example/devcodelab
    
  4. 編集するファイルを取得するには、android.test.example.devcodelab.DevCodelabTest のテスト名にある ./ に置き換えます。結果は次のようになります。

    src/android/test/example/devcodelab/DevCodelabTest.java
    
  5. 次に、このファイルを開いて

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

    次の行を

    Assert.assertTrue(false)
    

    で置き換えます。

    Assert.assertTrue(true)
    
  6. テストをもう一度実行して、問題が修正されたことを確認します。

    atest DevCodelabTest

レビューを受けるためにコードをアップロードする

Repo は、git clone などのコマンドをバンドルして一度に数多くの Git リポジトリ(またはプロジェクト)にわたって処理を実行することにより、Git の使用を簡素化します。

Git と Repo の概要と、Android ソースコードの作業に関する詳細なドキュメントへのリンクについては、ソース管理ツールをご覧ください。Git プロジェクト、個別プロジェクト(パス)、各プロジェクトの関連ブランチについては、AOSP リポジトリをご覧ください。

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

  1. たとえば、frameworks/native プロジェクト内で変更を加えた場合は、次のコマンドを実行して変更をアップロードします。

    cd frameworks/native
    repo start codelab .
    git add .
    git commit
  2. Commit メッセージでは、次のように入力します。

    Android codelab change
    Test: manual atest
    
  3. 変更をアップロードします。

    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 プラットフォーム開発向けの最初の Codelab はこれで完了です。次のステップについては、パッチの送信をご覧ください。Android 開発の詳細については、このサイトの他の部分をご覧ください。

変更を元に戻す

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

この Codelab は学習を目的としたものであるため、その代わりに Gerrit で [Abandon] をクリックして自分の変更リストを元に戻します。

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

repo abandon codelab .

テストファイルに対する変更も、忘れずに元に戻します。変更について repo startgit commitrepo 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 グループに投稿してください。