地球の歴史の中で最も広くインストールされているオペレーティング システムの開発に貢献できます。はい、あなたは 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 つに制限するか、セカンダリ ドライブでシステムを増強する必要があることに注意してください。
コードをビルドする
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 に示すような色の変化が見られることを確認します。
図 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グループに送信してください。