中旅發展

初始化你的回購客戶端

按照下載源代碼中的說明獲取和構建 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 驗證程序,使用相關 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/通過以下步驟快速啟動新的測試模塊:

  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 目錄,例如assetsjnilibsres 。要添加 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))

修復或刪除測試

除了添加新測試之外,您還可以修復或刪除使用BrokenTestKnownFailure註釋的測試。

提交您的更改

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

  • 對於適用於多個 API 級別的更改,首先aosp/master中開發一個補丁,然後選擇最上游的測試分支。允許自動合併器在 AOSP 測試分支中合併下游的更改。有關分支列表和自動合併路徑信息,請參閱發布計劃和分支信息。
  • 對於特定於特定 API 級別的更改,請在提交消息中使用DO NOT MERGERESTRICT 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 的自動合併。

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