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