CTS 开发

初始化您的 Repo 客户端

按照下载源代码中的说明进行操作,以获取并编译 Android 源代码,但在发出 repo init 命令时,请指定具体的 CTS 分支名称,例如 -b android-5.0_r2。这样可以确保在下一个及后续 CTS 版本中包含您的 CTS 更改。

构建和运行 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 方法。也就是说,避免使用任何以“隐藏”注释进行注释的类、方法和字段。
  • 避免使用视图布局或者依赖可能不适合某些设备的资源尺寸。
  • 请勿依赖根权限。

测试命名和位置

大多数 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。有关详情,请参阅 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_LISTbuild/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 以确保该 Activity 成功或记录其错误。

其他目录

此外,您还可以添加其他 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))
    

修复或移除测试

除添加新测试之外,您还可以修复或移除带有“BrokenTest”或“KnownFailure”注释的测试。

提交您的更改

在 AOSP 中提交 CTS 或 VTS 补丁程序时,请根据补丁程序适用的 API 级别选择您的开发分支。

  • 对于适用于多个 API 级别的更改,应该首先aosp/master 中开发变更列表 (CL),然后为最上游的测试分支挑选 CL。允许自动合并器合并 AOSP 测试分支中的下游更改。有关分支列表和自动合并路径的信息,请参阅发布时间表和分支信息
  • 对于具体到某一特定 API 级别的更改,请面向正确的测试分支开发或挑选更改,并在提交消息中添加 DO NOT MERGERESTRICT AUTOMERGE

按照提交补丁程序工作流程向 CTS 提交更改。我们会为您的更改指定审核人员,并会尽快完成审核。

发布时间表和分支信息

CTS 的发布遵循以下时间表。

版本 分支 发布频率
10 android10-tests-dev 每季度
9 pie-cts-dev 每季度
8.1 oreo-mr1-cts-dev 每季度
8.0 oreo-cts-dev 每季度
7.1 nougat-mr1-cts-dev 每季度
7.0 nougat-cts-dev 每季度
对于 6.0、5.1、5.0、4.4、4.3 和 4.2,尚无对应的发布计划。

发布过程中的重要日期

  • 第一周结束:代码冻结。在代码冻结之前提交到分支的更改会应用到即将发布的 CTS 版本中。相关更改如果在代码冻结或确定了候选发布版本之后才提交到分支,则会应用到后续版本中。
  • 第二周或第三周:在 Android 开源项目 (AOSP) 中发布 CTS。

自动合并流程

我们对 CTS 开发分支做了相应的设置,使提交到每个分支的更改自动合并到更高的分支中。

对于提交到即将发布的 Android 版本的更改,自动合并路径为:
aosp/master > <private-development-branch for Android R>

对于直接提交到 AOSP 分支的更改,自动合并路径为:
nougat-cts-dev > nougat-mr1-cts-dev > oreo-cts-dev > oreo-mr1-cts-dev > pie-cts-dev > android10-tests-dev

如果变更列表 (CL) 未能正确合并,CL 的作者会收到一封说明如何解决冲突的电子邮件。在大多数情况下,CL 作者可以按照这些说明跳过冲突的 CL 的自动合并。

此外,如果较旧的分支需要相关的更改,就需要从较新的分支中挑选 CL。