このチュートリアルは、Android オペレーティング システムの開発に初めて挑戦する方に向けたものです。
Android 開発のセットアップ
Android ソースの main
ブランチをダウンロードしてビルドする前に、お使いのハードウェアが要件を満たしており、必要なソフトウェアが適切にインストールされていることを確認してください。以下の用語についても知っておく必要があります。
- Git
- Git は、無料で利用できるオープンソースの分散型バージョン管理システムです。Android では、ブランチ作成、コミット、差分の取得、編集などのローカル操作に Git を使用します。Git について詳しくは、Git のドキュメントをご覧ください。
- Repo
- Repo は、Git の Python ラッパーで、複数の Git リポジトリにまたがる複雑な処理を簡略化するために使用します。ただし、あくまで複雑な Git 処理をより簡単に実現するためのもので、Git のすべてのバージョン管理処理を代替できるわけではありません。Repo はマニフェスト ファイルを使用して、Git プロジェクトを Android スーパープロジェクトに集約します。
- マニフェスト ファイル
- マニフェスト ファイルとは、Android ソースのさまざまな Git プロジェクトを AOSP ソースツリー内のどこに置くかを指定する XML ファイルです。
ハードウェア要件を確認する
開発ワークステーションは、以下のハードウェア要件を満たす必要があります。
64 ビット x86 システム。
コードのチェックアウトとビルド用に 400 GB 以上の空きディスク容量が必要です(チェックアウト用 250 GB + ビルド用 150 GB)。
64 GB 以上の RAM。Google での Android のビルドには、64 GB の RAM を搭載した 72 コアマシンを使用しています。このハードウェア構成で、Android のフルビルドに 40 分ほどかかります。増分ビルドであれば数分で完了します。一方、64 GB の RAM を搭載した 6 コアマシンではフルビルドに 6 時間ほどかかります。
オペレーティング システムの要件を確認する
開発ワークステーションは、GNU C ライブラリ(glibc)2.17 以降を実装する 64 ビットの Linux ディストリビューションを搭載している必要があります。
必要なパッケージをインストールする
Ubuntu 18.04 以降に必要なパッケージをインストールするには、次のコマンドを実行します。
sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig
必要なソフトウェアをインストールする
AOSP を使用するには、その前に OpenJDK、Make、Python 3、および Repo をインストールする必要があります。Android の AOSP main ブランチには、OpenJDK、Make、および Python 3 のビルド済みバージョンが用意されているため、追加のインストールは必要ありません。次のセクションでは、Repo をインストールする手順について説明します。
Repo をインストールする
Repo をインストールする手順は次のとおりです。
次のコマンドを実行して、現在のパッケージ情報をダウンロードします。
sudo apt-get update
次のコマンドを実行して、Repo ランチャーをインストールします。
sudo apt-get install repo
Repo ランチャーには、チェックアウトを初期化してフル Repo ツールをダウンロードするための Python スクリプトが用意されています。
正常に完了したらステップ 4 に進みます。
(省略可)Repo を手動でインストールするには、以下の一連のコマンドを使用します。
export REPO=$(mktemp /tmp/repo.XXXXXXXXX) curl -o ${REPO} https://storage.googleapis.com/git-repo-downloads/repo gpg --recv-keys 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65 curl -s https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ${REPO} && install -m 755 ${REPO} ~/bin/repo
最初の 3 つのコマンドにより一時ファイルがセットアップされ、そのファイルに Repo がダウンロードされます。さらに、指定した鍵が必要な鍵と一致するかどうかが確認されます。これらのコマンドが正常に完了したら、最後のコマンドを実行して Repo ランチャーをインストールします。
次のコマンドを実行して、Repo ランチャーのバージョンを確認します。
repo version
次に、バージョンが 2.4 以降になっていることを示す出力の例を示します。
repo launcher version 2.45
Android ソースのダウンロード
Android ソースは、Google がホストする Git リポジトリのコレクションにあります。各 Git リポジトリには、ソースの変更点や変更日時など、Android ソースの履歴全体が格納されています。次の手順で Android ソースをダウンロードします。
ホームディレクトリに移動します。
cd ~
ローカルの作業用サブディレクトリを作成します。
mkdir aosp
そのディレクトリに移動します。
cd aosp
AOSP リポジトリのソースコードの main ブランチ(デフォルト)を初期化します。
repo init --partial-clone -b main -u https://android.googlesource.com/platform/manifest
Git の認証情報(名前、メールアドレス)を入力するか、受け入れます。
ソースコードを同期します。
repo sync -c -j8
ダウンロード中に問題が発生した場合は、同期の問題のトラブルシューティングと解決を参照してください。
コードをビルドする
コードをビルドするには:
作業ディレクトリ内から、
envsetup.sh
スクリプトをソースとしてビルド環境を設定します。source build/envsetup.sh
lunch
コマンドで、ビルドするターゲット デバイスのタイプを選択します。ターゲットとは、特定のモデルやフォーム ファクタなど、特定のバージョンのデバイスです。このターゲットを指定します。lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
ターゲットとビルド環境の概要が表示されます。
============================================ PLATFORM_VERSION_CODENAME=VanillaIceCream PLATFORM_VERSION=VanillaIceCream PRODUCT_INCLUDE_TAGS=com.android.mainline TARGET_PRODUCT=aosp_arm TARGET_BUILD_VARIANT=eng TARGET_ARCH=arm TARGET_ARCH_VARIANT=armv7-a-neon TARGET_CPU_VARIANT=generic HOST_OS=linux HOST_OS_EXTRA=Linux-6.5.13-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete HOST_CROSS_OS=windows BUILD_ID=AOSP.MAIN OUT_DIR=out ============================================
ターゲットをビルドします。
m
初回のビルドが完了するまでには時間がかかります。その後のビルドでは、所要時間は大幅に短縮されます。ビルドの出力は $OUT_DIR
に保存されます。
Cuttlefish を起動する
Cuttlefish は、ビルドのテストに使用する Android エミュレータです。
次のコマンドを実行して、ホスト 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
のルールが適用されます。Cuttlefish を起動します。
launch_cvd --daemon
ウェブブラウザで
https://localhost:8443
にアクセスして、Cuttlefish デバイスに接続します。仮想 Android 搭載デバイスが表示されます。
変更を加える
このサンプルの変更リストに沿って、ソースコードを更新します。
チェックアウトのルート(
aosp/
ディレクトリ)からframeworks/native
Git プロジェクトに移動します。cd frameworks/native
次のコマンドを実行して、一時的なプロジェクトを開始します。
repo start <some-name> .
エディターを使って、次の場所にある
SurfaceFlinger.cpp
を編集します。aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
次に示す行を探します。
void SurfaceFlinger::updateColorMatrixLocked() {
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});
コードをビルドします。
m
デバイス上のビルドを更新します。
adb root
adb remount -R
adb root
adb sync
adb reboot
選択したデバイスの色が変化したことを確認します(図 1 のように表示されます)。
図 1. 成功した場合の画面上の色の変化
テストを修正する
Codelab のこのパートでは、サンプルのテストを利用します。このテストはソースツリー内にあり、すでに失敗しています。
次の手順に沿ってテストを実行、デバッグ、修正します。
次のコマンドを実行します。
atest DevCodelabTest
テストが失敗します。
失敗したテストのスタック トレースを確認します。
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)
スタック トレースの最終行に失敗したテスト(
testHelloWorld
)が表示されます。このテストはDevCodelabTest.java
というファイルにあります。修正すべきテストの場所を特定するには、スタック トレースの最終行に、
WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/
をテストファイルの名前まで含めて追加します。つまり、android.test.example.devcodelab.DevCodelabTest
はWORKING_DIRECTORY/platform_testing/tests/example/devcodelab/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 でプロジェクトのコードレビューを行うには、ウェブベースのコードレビュー システム Gerrit を使用します。
たとえば、
frameworks/native
プロジェクト内で変更を加えた場合は、次のコマンドを実行して変更をアップロードします。cd frameworks/native
repo start codelab .
git add .
git commit
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 で変更を確認する
Gerrit で変更を確認するには、ターミナルのリンク出力に移動します。リンクは次のようなものです。
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
変更を元に戻す
通常は、テストの後にレビューと承認を受けたら、Gerrit で変更を送信してリポジトリにマージします。この Codelab は学習を目的としたものであるため、その代わりに作業を元に戻します。
Gerrit で [Abandon] をクリックします。
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 プラットフォーム開発向けの Codelab はこれで完了です。
サポートを受ける
この Codelab でエラーが発生した場合は、ページの下部にある Issue Tracker のリンクを使用して報告してください。質問がある場合は、android-building グループに投稿してください。
ps -A | grep crosvm
を入力して、crosvm
がすでに実行されているか確認します。crossvm
が実行されている場合は、プロセス PID で stop_cvd || true
または kill crosvm
プロセスを入力します。