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 測試，請包含指向您在 Google 問題追蹤器中建立的測試提案的鏈接，作為CTS-D 提交流程的一部分。

建立子計劃

例如，您可以在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後綴。每個測試案例由多個測試組成，其中每個測試通常執行被測試類別的特定方法。這些測試按目錄結構排列，其中測試分為不同的類別，例如“小部件”或“視圖”。

例如，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 套件名稱的第二個字串（在我們的範例中為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註解的測試。

提交您的更改

在 AOSP 中提交 CTS 或 VTS 補丁時，請根據補丁適用的 API 等級選擇您的開發分支。

  • 對於適用於多個 API 層級的更改，首先在aosp/main中開發補丁，然後選擇最上游的測試分支。允許自動合併器合併 AOSP 測試分支中下游的變更。有關分支列表和自動合併路徑信息，請參閱發布計劃和分支信息。
  • 對於特定於特定 API 層級的更改，請在提交訊息中使用DO NOT MERGE或RESTRICT AUTOMERGE來開發或挑選對正確測試分支的變更。

按照提交補丁工作流程向 CTS 貢獻變更。將指派一名審閱者來相應地審閱您的更改。

發佈時間表和分支信息

CTS 版本遵循此時間表。

版本API等級分支頻率
14 34 android14-測試-開發季刊
13 33 android13-測試-開發季刊
12公升32 android12L-測試-開發季刊
12 31 android12-測試-開發季刊
11 30 android11-測試-開發季刊
計劃不再發布版本 10.0、9.0、8.1、8.0、7.1、7.0、6.0、5.1、5.0、4.4、4.3 和 4.2。

發布期間的重要日期

  • 第一周結束：代碼凍結。即將發布的 CTS 版本會考慮在程式碼凍結之前合併到分支中的變更。程式碼凍結後或選擇發布候選者後向分支的提交將被考慮用於後續發布。
  • 第二週或第三週： CTS在AOSP發表。

自動合併流程

CTS開發分支已經建立，以便提交到每個分支的變更自動合併到更高的分支。

對於直接變更到 AOSP 測試開發分支，自動合併路徑為：
android11-tests-dev > android12-tests-dev dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

對於僅對下一個 Android 版本的更改，自動合併路徑為：
aosp/main > <Internal git/main> 。

如果變更清單 (CL) 無法正確合併，則會向補丁作者發送電子郵件，其中包含有關如何解決衝突的說明。在大多數情況下，補丁的作者可以使用說明來跳過衝突 CL 的自動合併。

如果較舊的分支需要更改，則需要從較新的分支中挑選補丁。