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 コンソールを起動します。

CTS をビルドする（AOSP 14 以前）

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

CTS をビルドする（AOSP 15 以降）

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

以下の表を参照して、target-release 値を選択してください。

ブランチ 対象リリース
android15-tests-dev ap3a

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/ を使用して、次の手順で新しいテスト モジュールの作成を簡単に始めることができます。

  1. テスト ディレクトリを作成してサンプル ファイルをコピーするには、次のコマンドを実行します。 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. cts/tests/module-name に移動し、「[Ss]ample」にマッチした部分を上記の推奨の命名規則に沿ってすべて置換します。
  3. テスト対象の機能をテストするように SampleDeviceActivity を修正します。
  4. アクティビティが成功しなかった場合はエラーをログに記録するように、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 というアノテーションが付いたテストを修正、あるいは削除することもできます。

変更の送信

CTS に変更を投稿する際には、コード変更の送信ワークフローに沿ってください。パッチが適用される API レベルを基に、開発ブランチを選択してください。

  • 複数の API レベルに適用される変更の場合は、最上流のテストブランチにパッチを作成します。AOSP テストブランチの下流の変更について、automerger による統合を許可します。ブランチのリストと自動マージのパスの情報については、リリース スケジュールとブランチ情報をご覧ください。
  • 特定の API レベルに適用される変更を行うには、コミット メッセージで DO NOT MERGE または RESTRICT AUTOMERGE を使用して、正しいテストブランチに対する変更を開発またはチェリーピックします。

審査担当者が割り当てられ、その担当者が変更内容を審査し、その変更を内部の Gerrit に適宜チェリーピックします。

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

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

バージョン API レベル ブランチ 頻度
15 35 android15-tests-dev 四半期ごと
14 34 android14-tests-dev 四半期ごと
13 33 android13-tests-dev 四半期ごと
12L 32 android12L-tests-dev 四半期ごと
12 31 android12-tests-dev 四半期ごと

リリース中の重要な期日

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

自動マージのフロー

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

AOSP テスト開発ブランチへの直接変更の場合、自動マージのパスは次のようになります。
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev

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

古いブランチの変更が必要な場合は、新しいブランチからパッチをチェリーピックする必要があります。

テストでの変更を次の Android バージョンに適用する場合は、提案された変更がアップロードされたあとに、その変更内容を Google が審査します。変更が承認されると、Google が内部の Gerrit にチェリーピックします。