CTS 開發

初始化存放區用戶端

按照下載原始碼中的操作說明， 並建立 Android 原始碼發出 repo init 指令時，請指定 使用 -b 的特定 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 註解一起檢視。
• 避免使用檢視畫面版面配置，或採用可能不支援某些元素的素材資源尺寸 裝置。
• 請勿仰賴根權限。

新增 Java 註解

如果測試驗證了 API 行為，請為測試程式碼加上 @ApiTest 和清單 與 apis 欄位相關的所有 API請使用 範例：

API 類型	註解格式	附註
方法	android.example.ClassA#methodA	最常見的用途。
包含鍵/值的方法	android.example.ClassB#methodB(KeyA)	僅適用於測試使用 API 方法驗證欄位的情況，例如 這個例子
欄位	android.example.ClassC#FieldA	只在測試直接驗證 API 欄位時才使用，例如 這個例子

如果測試驗證通過 CDD 規定，請加上註解要求 ID (包括 CDD 區段) ID 和需求 ID) 在 CTS 測試程式碼中以 @CddTest 結尾，如 範例。在修訂訊息中，提及您的 進行測試。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，請在 AndroidManifest.xml 中為每個活動加上註解，並使用 相關的 CDD ID。值欄位的格式與 CTS：在修訂訊息中，參考 CDD 來註明強制執行的 CDD 要求 要求 ID

  <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 用 測試，並附上您在 Google Issue Tracker 中建立的測試提案連結。 CTS-D 提交程序。

建立子計劃

舉例來說，您可以在以下位置新增 SubPlan.xml 檔案： android-cts/subplans，如下所示：

<?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 套件的 CTS 測試 android.widget.TextView 是 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 套件名稱的第二個字串 (在 例如：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_COVERAGE_TEST_CASE_LIST 英寸 cts/CtsTestCaseList.mk。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，並替換 「[S]安培」使用 建議採用的命名慣例。
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 註解的測試。

提交變更

在 Android 開放原始碼計畫中提交 CTS 或 VTS 修補程式時，請選擇開發分支版本 確定修補程式的適用 API 級別

• 如要套用至多個 API 級別的變更，請首先 在 aosp/main 中開發修補程式，然後從 Cherry 挑選 上游測試分支版本。允許自動合併功能在下游合併變更 AOSP 測試分支版本。詳情請見 發布時間表和分支版本資訊，取得 和自動合併路徑資訊
• 如果是特定 API 級別的變更，請開發或挑選特定 API 級別的變更 正確的測試分支版本的變更，請勿合併或 修訂訊息中的 RESTRICT AUTOMERGE。

按照提交修補程式工作流程進行操作 對 CTS 做出變更並且將指派審查者審查您的變更。

發布時間表和分支版本資訊

CTS 版本會依此時程發布。

版本	API 級別	Branch	頻率
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	每季

發布期間的重要日期

• 第一週結束：程式碼凍結。合併至分支版本中的變更 。 在程式碼凍結後或的候選人後提交至分行 獲選的發布版本一律視為後續版本。
• 第二或第三週：CTS 發布於 Android 開放原始碼計畫。

自動合併流程

設定 CTS 開發分支，以便將變更提交至每個 分支會自動合併至更高的分支版本

如果是直接對 Android 開放原始碼計畫測試開發分支版本進行變更，自動合併路徑為：
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

如果僅適用於下一個 Android 版本，自動合併路徑為：
aosp-main > <Internal git_main>。

如果變更清單 (CL) 無法正確合併，系統會傳送修補程式的作者 電子郵件，說明如何解決衝突。大部分的 ，修補程式的作者可以按照指示略過自動合併 相衝突的 CL

如果較舊的分支版本需要變更，則修補程式狀態需要 從較新的分支版本中挑選出的 Cherry。