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

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 テスト コードで@CddTestを使用して要件 ID (CDD セクション ID と要件 ID を含む) に注釈を付けます。コミット メッセージで、CDD 要件 ID を参照して、テストによってどの CDD 要件がテストされているかを示します。 CDD 要件 ID は、セクション ID と要件 ID の組み合わせであり、7.3.1/C-1-1 のようにスラッシュ (/) で接続されています。


/**
* 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 Verifier の場合、関連する CDD ID を使用して、 AndroidManifest.xml内の各アクティビティに注釈を付けます。値フィールドのフォーマットは、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 の特定のクラスを対象としています。これらのテストには、接尾辞ctsが付いた Java パッケージ名と接尾辞Testが付いたクラス名があります。各テスト ケースは複数のテストで構成され、各テストは通常​​、テスト対象のクラスの特定のメソッドを実行します。これらのテストは、テストが「ウィジェット」や「ビュー」などのさまざまなカテゴリにグループ化されたディレクトリ構造に配置されます。

たとえば、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.mkCTS_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を更新して、アクティビティが成功するか、エラーがログに記録されるようにします。

追加のディレクトリ

assetsjnilibsresなどの他の Android ディレクトリも追加できます。 JNI コードを追加するには、プロジェクトのルートのsrcの隣に、ネイティブ コードとAndroid.mk 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でパッチを開発してから、最も上流のテスト ブランチにチェリー ピックします。自動マージャーが AOSP テスト ブランチの下流の変更をマージできるようにします。ブランチのリストと自動マージ パス情報については、リリース スケジュールとブランチ情報を参照してください。
  • 特定の API レベルに固有の変更については、コミット メッセージでDO NOT MERGEまたはRESTRICT AUTOMERGEを使用して、正しいテスト ブランチへの変更を開発またはチェリー ピックします。

パッチの送信ワークフローに従って、CTS に変更を提供します。それに応じて変更をレビューするレビュー担当者が割り当てられます。

発売予定と出店情報

CTS のリリースは、このスケジュールに従います。

バージョンAPI レベルブランチ周波数
13 33 android13-tests-dev四半期ごと
12L 32 android12L-tests-dev四半期ごと
12 31 android12-tests-dev四半期ごと
11 30 android11-tests-dev四半期ごと
10 29 android10-tests-dev四半期ごと
バージョン 9.0、8.1、8.0、7.1、7.0、6.0、5.1、5.0、4.4、4.3、および 4.2 の今後のリリースは予定されていません。

リリース中の重要な日付

  • 最初の週の終わり:コードのフリーズ。コードがフリーズするまでブランチにマージされた変更は、CTS の今後のバージョンで考慮されます。コード凍結後、またはリリース候補が選択された後のブランチへの提出は、その後のリリースと見なされます。
  • 2 週目または 3 週目: CTS はAOSPで公開されます。

自動マージ フロー

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

AOSP テスト開発ブランチに直接変更する場合、自動マージ パスは次のとおりです。
pie-cts-dev android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > aosp/master

次の Android バージョンへの変更のみの場合、自動マージ パスは次のとおりです。
aosp/master > <private-development-branch for Android 14 (AOSP experimental)> .

変更リスト (CL) が正しくマージされない場合、パッチの作成者には、競合を解決する方法が記載された電子メールが送信されます。ほとんどの場合、パッチの作成者は手順を使用して、競合する CL の自動マージをスキップできます。

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