每个新的测试模块都必须具有配置文件，以使用模块元数据、编译时依赖项和打包指令来指引编译系统。现在，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-uiautomator、mockito-target、easymock 等等。
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