CTS の開発

Repo クライアントの初期化

ソースのダウンロードの手順に沿って、Android のソースコードを入手してビルドします。repo init コマンドを実行する際に、-b を使用して特定の CTS ブランチを指定します。これにより、CTS に対して行った変更が次回以降の CTS リリースに反映されます。

次のサンプルコードは、repo init の使用方法を示しています。

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

CTS のビルドと実行

次のコマンドを実行して、CTS をビルドし、対話型の CTS コンソールを起動します。

注: aosp_arm64 の代わりに aosp_x86_64 を指定することもできます。

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 権限に依存しない。

Java アノテーションの追加

テストで API の動作を検証する場合は、テストコードに @ApiTest アノテーションを付け、apis フィールドに関連するすべての API をリストします。次の例の中から適切な形式を使用してください。

API のタイプ	アノテーションの形式	備考
メソッド	`android.example.ClassA#methodA`	最も一般的なユースケース。
キー値を含むメソッド	`android.example.ClassB#methodB(KeyA)`	この例のように、テストで API メソッドを使用してフィールドを検証する場合にのみ使用。
フィールド	android.example.ClassC#FieldA	この例のように、テストで API フィールドを直接検証する場合にのみ使用。

テストで CDD 要件を確認する場合は、以下の例に示すように、CTS テストコードで要件 ID（CDD セクション ID と要件 ID を含む）に @CddTest アノテーションを付けます。コミットメッセージに、CDD の要件 ID を追加してテスト対象の CDD 要件を指定します。CDD 要件 ID は、7.3.1/C-1-1 のようにスラッシュ（/）で接続されたセクション ID と要件 ID の組み合わせです。


/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
    @CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
    public void testAddPasspointConfigWithUserCredential() throws Exception {
        if (!WifiFeature.isWifiSupported(getContext())) {
            // skip the test if WiFi is not supported
            return;
        }      testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
    }

CTS 検証ツールの場合は、AndroidManifest.xml 内の各アクティビティに、関連する CDD ID のアノテーションを付けます。値フィールドの形式は、CTS の Java アノテーションの形式とほぼ同じです。コミットメッセージに、CDD の要件 ID を追加して適用する CDD 要件を指定します。


  <activity>
    ......
    <!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
    <meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />

    <!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
    <meta-data android:name="api_test"
               android:value="com.example.MyClass#myMethod" />

    <!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
    <meta-data android:name="non_compliance_test"
               android:value="detailed reasons" />
  </activity>

コミットメッセージ

テストを追加する必要がある理由を明確に指定し、サポートの関連リンクを追加します。CTS-D テストの場合は、CTS-D 提出手続きの一環として Google Issue Tracker で作成したテストプランへのリンクを含めます。

サブプランの作成

たとえば、次のように android-cts/subplans に SubPlan.xml ファイルを追加できます。

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<SubPlan version="2.0">
<Entry include="CtsSystemIntentTestCases" />
<Entry include="CtsSystemUiHostTestCases" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" />
</SubPlan>

サブプランを実行するには:

run cts --subplan aSubPlan

サブプランエントリの形式は次のとおりです。

Include a module name as follows:
<Entry include="MODULE_NAME" />

Include a package:
<Entry include="MODULE_NAME PACKAGE_NAME" />

Include a class:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" />

Include an individual test:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />

テストの名前と場所

ほとんどの 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 を使用します。詳しくは、Android オープンソースプロジェクト（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 に追加します。build/core/tasks/cts.mk はこの makefile を使用してすべてのテストを統合し、最終的な 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 レベルに適用される変更の場合は、まず aosp/master にパッチを作成し、最上流のテストブランチに cherry-pick します。AOSP テストブランチの下流の変更について、automerger による統合を許可します。ブランチのリストと自動マージのパスの情報については、リリーススケジュールとブランチ情報をご覧ください。
特定の API レベルに固有の変更を行うには、コミットメッセージで DO NOT MERGE または RESTRICT AUTOMERGE を使用して、正しいテストブランチに対する変更を開発または選別します。

パッチの提出ワークフローに沿って CTS への変更を提案します。変更内容を確認するレビュー担当者が割り当てられます。

リリーススケジュールとブランチ情報

CTS のリリーススケジュールは次のとおりです。

バージョン	ブランチ	頻度
12L	android12L-tests-dev	毎四半期
12	android12-tests-dev	毎四半期
11	android11-tests-dev	毎四半期
10	android10-tests-dev	毎四半期
9	pie-cts-dev	毎四半期
バージョン 8.1、8.0、7.1、7.0、6.0、5.1、5.0、4.4、4.3、4.2 については、今後のリリースは予定されていません。

リリース中の重要な期日

第 1 週の終わり: コードフリーズ。コードフリーズまでにブランチに統合された変更内容が、次バージョンの CTS での検討対象となります。コードフリーズの後、またはリリース候補になった後に提出されたものは、次回以降のリリースの検討対象となります。
第 2 週または第 3 週: CTS が AOSP で公開されます。

自動マージのフロー

CTS の開発ブランチは、各ブランチに提出された変更が自動的に上位のブランチにマージされるように設定されています。

AOSP ブランチへの直接変更の場合、自動マージのパスは次のようになります。
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

今後の Android バージョンの変更では、自動マージのパスは次のようになります。
aosp/master > <private-development-branch for Android T (AOSP experimental)>

changelist（CL）でマージに失敗すると、パッチの作成者に競合の解決手順がメールで送られます。ほとんどの場合、パッチの作成者は、この手順を使用して競合している CL の自動マージをスキップできます。

古いブランチの変更が必要な場合は、新しいブランチからパッチを cherry-pick する必要があります。

CTS の開発

Repo クライアントの初期化

CTS のビルドと実行

CTS テストの作成

Java アノテーションの追加

コミット メッセージ

サブプランの作成

テストの名前と場所

CTS v1

CTS v2

新しいサンプル パッケージ

CTS v1

CTS v2

その他のディレクトリ

Android.mk ファイル

テストの修正または削除

変更を提出する

リリース スケジュールとブランチ情報

リリース中の重要な期日

自動マージのフロー

コミットメッセージ

新しいサンプルパッケージ

リリーススケジュールとブランチ情報