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 注解

如果您的测试验证了 AP​​I 行为,请使用@ApiTest注释您的测试代码,并列出apis字段中涉及的所有 API。使用以下示例中的适当格式:

接口类型注释格式笔记
方法android.example.ClassA#methodA最常见的用例。
具有键值的方法android.example.ClassB#methodB(KeyA)仅当您的测试使用 API 方法来验证字段时使用,如本例所示。
场地android.example.ClassC#FieldA仅当您的测试直接验证 API 字段时使用,如本例所示。

如果您的测试验证了 CDD 需求,请在 CTS 测试代码中使用@CddTest注释需求 ID(包括 CDD Section ID 和 Requirement 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中的每个活动。值字段的格式类似于 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 Issue Tracker 中作为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 中的特定类。这些测试的 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 目录,例如assetsjnilibsres 。要添加 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)

安卓.mk文件

最后,修改项目根目录下的Android.mk文件,构建native代码并依赖,如下图:

# 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中开发补丁,然后 cherry-pick 到最上游的测试分支。允许自动合并器合并下游 AOSP 测试分支中的更改。有关分支列表和自动合并路径信息,请参阅发布计划和分支信息。
  • 对于特定于特定 API 级别的更改,在提交消息中使用DO NOT MERGERESTRICT AUTOMERGE开发或挑选更改到正确的测试分支。

按照提交补丁程序工作流为 CTS 贡献更改。将指派一名审阅者相应地审阅您的更改。

发布时间表和分支信息

CTS 版本遵循此时间表。

版本API级别分支频率
13 33 android13-测试-开发季刊
12L 32 android12L-测试-开发季刊
12 31 android12-测试-开发季刊
11 30 android11-测试-开发季刊
10 29 android10-测试-开发季刊
没有计划为版本 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 测试开发分支,automerge 路径是:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > aosp/master

对于仅对下一个 Android 版本的更改,automerge 路径为:
aosp/master > <private-development-branch for Android 14 (AOSP experimental)> .

如果更改列表 (CL) 未能正确合并,补丁的作者将收到一封电子邮件,其中包含有关如何解决冲突的说明。在大多数情况下,补丁作者可以使用指令跳过冲突 CL 的自动合并。

如果较旧的分支需要更改,则需要从较新的分支中挑选补丁。