本頁面由 Cloud Translation API 翻譯而成。

中旅發展

初始化你的回購客戶端

按照下載源代碼中的說明獲取和構建 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 控制台：

注意：您可以使用aosp_x86_64作為aosp_arm64的替代品。

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 驗證程序，使用相關 CDD ID 註釋AndroidManifest.xml中的每個 Activity。值字段的格式類似於 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 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 包名稱的第二個字符串（在我們的示例中為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的 CTS_COVERAGE_TEST_CASE_LIST 中。 build/core/tasks/cts.mk使用這個 makefile 來組合所有的測試並創建最終的 CTS 包。

CTS v2

使用示例測試/cts/tests/sample/通過以下步驟快速啟動新的測試模塊：

要創建測試目錄並複制示例文件，請運行：

mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

導航到cts/tests/ module-name並用上面推薦的命名約定替換“[Ss]ample”的所有實例。
更新SampleDeviceActivity以練習您正在測試的功能。
更新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/master中開發一個補丁，然後選擇最上游的測試分支。允許自動合併器在 AOSP 測試分支中合併下游的更改。有關分支列表和自動合併路徑信息，請參閱發布計劃和分支信息。
對於特定於特定 API 級別的更改，請在提交消息中使用DO NOT MERGE或RESTRICT AUTOMERGE開發或挑選對正確測試分支的更改。

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

發佈時間表和分支信息

CTS 版本遵循此時間表。

版本	API 級別	分支	頻率
12L	32	android12L-測試-開發	季刊
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 版本中考慮在代碼凍結之前合併到分支中的更改。在代碼凍結之後或在選擇發布候選者之後提交到分支，將被考慮用於後續發布。
第二或第三週： CTS 在AOSP上發布。

自動合併流程

已設置 CTS 開發分支，以便提交到每個分支的更改自動合併到更高的分支。

對於直接對 AOSP 分支的更改，自動合併路徑為：
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

對於即將推出的 Android 版本的更改，自動合併路徑為：
aosp/master > <private-development-branch for Android T (AOSP experimental)> 。

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

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