CTS 开发

初始化您的 Repo 客户端

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

构建和运行 CTS

执行以下命令以构建 CTS 并启动交互式 CTS 控制台:

注意:您可以为 TARGET_PRODUCT 提供以下其他值之一,以针对不同的架构进行编译:aosp_x86_64aosp_mips

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

例如,在 cts-tf 控制台中,输入:

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_LIST。该 Makefile 由 build/core/tasks/cts.mk 用来将所有测试组合在一起,以创建最终 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)

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))

修复或移除测试

除了添加新测试外,还可以通过其他方法为 CTS 做出贡献:修复或移除具有“BrokenTest”或“KnownFailure”注释的测试。

提交您的更改

按照提交补丁程序工作流程向 CTS 贡献更改。系统会为您的更改分配审核者,您的更改很快即会得到审核!

版本发布时间表和分支信息

CTS 版本发布遵循以下时间表。

注意:该时间表是暂定的,可能会随着给定 Android 版本 CTS 的正式发布而不时更新。

版本 分支 频率
8.0 oreo-cts-dev 每月
7.1 nougat-mr1-cts-dev 每月
7.0 nougat-cts-dev 每月
6.0 marshmallow-cts-dev 每月
5.1 lollipop-mr1-cts-dev 每月
5.0 lollipop-cts-dev 无版本发布计划
4.4 kitkat-cts-dev 无版本发布计划
4.3 jb-mr2-cts-dev 无版本发布计划
4.2 jb-mr1.1-cts-dev 无版本发布计划

版本发布当月的重要日期

  • 第一周的周末:代码冻结。此时,不再接受与当前分支有关的提交内容,并且提交内容不会包含在下一版本的 CTS 中。我们选择了候选版本后,分支将再次开放并接受新的提交内容。
  • 第二周或第三周:在 Android 开放源代码项目 (AOSP) 中发布 CTS。

自动合并流程

CTS 开发分支已设置,因此提交到每个分支的更改将自动合并,如下所示:
jb-dev-> jb-mr1.1-cts-dev -> jb-mr2-cts-dev -> kitkat-cts-dev -> lollipop-cts-dev -> lollipop-mr1-cts-dev -> marshmallow-cts-dev -> nougat-cts-dev -> nougat-mr1-cts-dev -> oreo-cts-dev -> <private-development-branch for Android O MR1>

如果变更列表 (CL) 未能正确合并,CL 的作者将收到一封电子邮件,其中包含有关如何解决冲突的说明。在大多数情况下,CL 作者可以通过这些说明来跳过存在冲突的 CL 的自动合并流程。