简单的编译配置

每个新的测试模块都必须具有配置文件,以使用模块元数据、编译时依赖项和打包指令来指引编译系统。现在,Android 使用 Soong 编译系统来实现更简单的测试配置。

Soong 使用与 JSON 类似的 Blueprint 文件(即 .bp 文件)来对要编译的模块进行简单的声明性描述。此格式取代了以前的版本中使用的基于 Make 的系统。如需了解完整详情,请参阅持续集成信息中心上的 Soong 参考文件

要适应自定义测试或使用 Android 兼容性测试套件 (CTS),请改为按照复杂的测试配置操作。

示例

以下条目均来自这一示例 Blueprint 配置文件:/platform_testing/tests/example/instrumentation/Android.bp

为方便起见,下面附上快照:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

请注意,开头的 android_test 声明表示这是一个测试。相反,如果开头为 android_app,则表示这是一个编译软件包。

设置

下面对各项设置进行了解释:

    name: "HelloWorldTests",

如果指定了 android_test 模块类型(在代码块的开头),则需要 name 设置。此设置会为模块命名,生成的 APK 将与模块名称相同,不过带有 .apk 后缀。例如,在本例中,生成的测试 apk 将命名为 HelloWorldTests.apk。此外,此设置还可以为模块定义 make 目标名称,以便您可以使用 make [options] <HelloWorldTests> 编译测试模块及其所有依赖项。

    static_libs: ["android-support-test"],

static_libs 设置指示编译系统将已命名模块的内容合并到当前模块生成的 apk 中。这意味着,每个已命名模块都会生成 .jar 文件,其内容将用于在编译期间解析类路径引用,以及合并到生成的 apk 中。

在本例中,可能对测试普遍有用的内容如下:

android-support-test 是 Android 测试支持库的预编译项,包括新的测试运行器 AndroidJUnitRunner:它替代了现已弃用的内置 InstrumentationTestRunner,并且支持 JUnit4 测试框架。如需了解详情,请参阅在 Android 平台上测试应用

如果要编译一个新的插桩模块,则开始时应始终将 android-support-test 库作为测试运行器。平台源代码树还包括其他有用的测试框架,如 ub-uiautomatormockito-targeteasymock 等等。

    certificate: "platform",

certificate 设置指示编译系统使用与核心平台相同的证书对 apk 进行签名。如果您的测试使用受签名保护的权限或 API,则需要此设置。请注意,此设置适合平台连续测试,但不应该用于 CTS 测试模块。另请注意,本例使用此证书设置只是为了进行说明:示例中的测试代码实际上不需要使用特殊平台证书对测试 apk 进行签名。

如果您要为系统服务器之外的组件(也就是说,它的打包方式多少有些类似于常规应用 apk,只不过它内置到系统映像中并且可能是特权应用)编写插桩,那么插桩可能会以组件的应用软件包(请参阅下面关于清单的部分)为目标。在这种情况下,应用 makefile 可能具有自己的 certificate 设置,并且插桩模块应保留相同的设置。这是因为,要以受测应用上的插桩为目标,必须使用同一证书对测试 apk 和应用 apk 进行签名。

在其他情况下,根本不需要此设置:编译系统将直接使用默认的内置证书(基于编译变体)对其进行签名,并且它通常称为 dev-keys

    test_suites: ["device-tests"],

test_suites 设置使 Trade Federation 自动化测试框架很容易发现测试。可在此处添加其他套件(如 CTS),以便共享此测试。

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk