Repo クライアントの初期化
ソースのダウンロードに沿って Android のソースコードを取得しビルドしますが、repo
init
コマンドを実行する際に、-b android-5.0_r2
のように CTS ブランチ名を指定します。これにより、CTS に対して行った変更が次のリリース以降に反映されます。
CTS のビルドと実行
次のコマンドを実行して、CTS をビルドし、対話型の CTS コンソールを起動します。
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
CTS コンソールで次のように入力します。
tf> run cts --plan CTS
CTS テストの作成
CTS テストでは、JUnit と Android のテスト API を使用します。アプリをテストするのチュートリアルを確認しながら、cts/tests
ディレクトリにある既存のテストに目を通します。CTS テストの大半が、他の Android のテストが使用している規則と同じ規則に従っているのがわかります。
CTS は、さまざまな製品版デバイスで実行されるため、テストでは次のルールに従う必要があります。
- さまざまな画面のサイズ、向き、キーボード レイアウトに対応する。
- 公開 API メソッドのみを使用する。つまり、「hide」アノテーションが付いたクラス、メソッド、フィールドは一切使用しません。
- ビュー レイアウトを使用しない、または一部のデバイスにない場合があるアセットのサイズには依存しない。
- root 権限に依存しない。
テストの名前と場所
ほとんどの CTS テストケースは、Android API の特定のクラスを対象にしています。これらのテストでは、Java パッケージ名に接尾辞として cts
が付き、クラス名に接尾辞として Test
が付きます。各テストケースは、複数のテストで構成されます。各テストでは通常、テスト対象のクラスの特定のメソッドが実行されます。テストは、「widgets」や「views」などのカテゴリにグループ化されたディレクトリ構造内に配置されています。
たとえば、Java パッケージ android.widget.TextView
の CTS テストは android.widget.cts.TextViewTest
です(Java パッケージ名が android.widget.cts
、クラス名が TextViewTest
)。
- Java パッケージ名
CTS テストの Java パッケージ名は、テストするクラスのパッケージ名の後ろに.cts
を付けたものです。この例では、パッケージ名はandroid.widget.cts
になります。 - クラス名
CTS テストのクラス名は、テストするクラスの名前の後ろに「Test」を追加したものです。たとえば、テスト対象がTextView
の場合、クラス名はTextViewTest
になります。 - モジュール名(CTS v2 のみ)
CTS v2 ではテストをモジュールごとに整理します。モジュール名は通常、Java パッケージ名の 2 番目の文字列(この例ではwidget
)です。
ディレクトリ構造とサンプルコードは、CTS v1 と CTS v2 のどちらを使用しているかによって異なります。
CTS v1
Android 6.0 以前の場合は、CTS v1 を使用します。CTS v1 の場合、サンプルコードは cts/tests/tests/example
にあります。
CTS v1 テストのディレクトリ構造は次のようになります。
cts/ tests/ tests/ package-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
CTS v2
Android 7.0 以降の場合は、CTS v2 を使用します。詳しくは、AOSP のサンプルテストをご覧ください。
CTS v2 のディレクトリ構造は次のようになります。
cts/ tests/ module-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
新しいサンプル パッケージ
新しいテストを追加する際に、テストを配置するディレクトリがない場合があります。その場合は、ディレクトリを作成して適切なサンプル ファイルをコピーする必要があります。
CTS v1
CTS v1 を使用している場合は、cts/tests/tests/example
以下のサンプルを参照して、新しいディレクトリを作成します。さらに、新しいパッケージのモジュール名をその Android.mk
から cts/CtsTestCaseList.mk
内の CTS_COVERAGE_TEST_CASE_LIST
に追加します。この makefile は build/core/tasks/cts.mk
がすべてのテストをまとめて最終的な CTS パッケージを作成するために使用します。
CTS v2
サンプルテスト /cts/tests/sample/
を使用して、次の手順で新しいテスト モジュールの作成を簡単に始めることができます。
- 次のコマンドを実行して、テスト ディレクトリを作成し、そこにサンプル ファイルをコピーします。
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
cts/tests/module-name
に移動し、「[Ss]ample」にマッチした部分を上記の推奨の命名規則に従ってすべて置換します。SampleDeviceActivity
をテスト対象の機能をテストするように修正します。- アクティビティが成功しなかった場合はエラーをログに記録するように、
SampleDeviceTest
を修正します。
その他のディレクトリ
他の Android ディレクトリ assets
、jni
、libs
、res
を追加することもできます。JNI コードを追加するには、src
の隣のプロジェクトのルートにディレクトリを作成し、そこにネイティブ コードと Android.mk
makefile を入れます。
makefile には通常、次の設定が含まれます。
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := libCtsSample_jni # don't include this package in any target LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := list of source code files LOCAL_C_INCLUDES := $(JNI_H_INCLUDE) # Tag this module as a cts test artifact LOCAL_COMPATIBILITY_SUITE := cts LOCAL_SHARED_LIBRARIES := libnativehelper LOCAL_SDK_VERSION := current include $(BUILD_SHARED_LIBRARY)
Android.mk ファイル
最後に、ネイティブ コードとそのコードに対する依存関係がビルドされるように、プロジェクトのルートにある Android.mk
ファイルを以下のように修正します。
# All tests should include android.test.runner. LOCAL_JAVA_LIBRARIES := android.test.runner # Includes the jni code as a shared library LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni # Include for InstrumentationCtsTestRunner LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner... LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE) #Tells make to look in subdirectories for more make files to include include $(call all-makefiles-under,$(LOCAL_PATH))
テストの修正または削除
新しいテストを追加するだけでなく、「BrokenTest」または「KnownFailure」というアノテーションが付いたテストを修正、あるいは削除することもできます。
変更を提出する
AOSP で CTS パッチまたは VTS パッチを提出する場合は、パッチが適用される API レベルに基づいて開発ブランチを選択します。
-
変更が複数の API レベルに適用される場合は、最初に CL を
aosp/master
で開発してから選別し、最上流のテストブランチに適用する必要があります。AOSP テストブランチの下流の変更について、automerger による統合を許可します。ブランチのリストと自動マージのパスの情報については、リリース スケジュールとブランチ情報をご覧ください。 - 特定の API レベルに固有の変更を行うには、コミット メッセージで DO NOT MERGE または RESTRICT AUTOMERGE を使用して、正しいテストブランチに対する変更を開発または CP します。
パッチの提出ワークフローに沿って CTS への変更を提案します。提案された変更にレビュー担当者が割り当てられ、変更内容はすぐに確認されます。
リリース スケジュールとブランチ情報
CTS のリリース スケジュールは次のとおりです。
バージョン | ブランチ | 頻度 |
---|---|---|
10 | android10-tests-dev | 毎四半期 |
9 | pie-cts-dev | 毎四半期 |
8.1 | oreo-mr1-cts-dev | 毎四半期 |
8.0 | oreo-cts-dev | 毎四半期 |
7.1 | nougat-mr1-cts-dev | 毎四半期 |
7.0 | nougat-cts-dev | 毎四半期 |
6.0、5.1、5.0、4.4、4.3、4.2 のリリースは予定されていません。 |
リリース中の重要な期日
- 第 1 週の終わり: コードフリーズ。ブランチに対してコードフリーズの時点までに提出されたものが、近日リリースする CTS のバージョンの検討対象となります。コードフリーズの後、またはリリース候補になった後に提出されたものは、次回以降のリリースの検討対象となります。
- 第 2 週または第 3 週: CTS は Android オープンソース プロジェクト(AOSP)で公開されます。
自動マージのフロー
CTS の開発ブランチは、各ブランチに提出された変更が自動的に上位のブランチにマージされるように設定されています。
今後の Android バージョンの変更では、自動マージのパスは次のようになります。
aosp/master
> <private-development-branch for Android R>
AOSP ブランチへの直接変更の場合、自動マージのパスは次のようになります。
nougat-cts-dev
> nougat-mr1-cts-dev
> oreo-cts-dev
> oreo-mr1-cts-dev
> pie-cts-dev
> android10-tests-dev
changelist(CL)でマージに失敗すると、CL の作成者に競合の解決手順がメールで送られます。ほとんどの場合、CL の作成者は、この手順を使用して競合している CL の自動マージをスキップできます。
また、古いブランチの変更が必要な場合は、新しいブランチから CL を選別する必要があります。