Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

CTS の開発

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

  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」というアノテーションが付いたテストを修正、あるいは削除することもできます。

変更を提出する

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 を選別する必要があります。