模块配置的整体结构遵循与常规 Tradefed XML 配置类似的模式，但由于它们作为套件的一部分运行，因此存在一些限制。
允许的标签列表
AndroidTest.xml或更广泛的模块配置只能包含以下 XML 标签： target_preparer 、 multi_target_preparer 、 test和metrics_collector 。
尽管该列表看起来很严格，但它允许您精确定义测试模块设置需求和要运行的测试。
注意：如果您需要复习不同标签，请参阅Tradefed XML 配置。
如果尝试从模块配置内部运行，诸如build_provider或result_reporter类的对象将引发ConfigurationException 。这是为了避免期望这些对象实际上在模块内执行某些任务。
示例模块配置
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
此配置描述了一个需要安装CtsGestureTestCases.apk的测试，并将针对android.gesture.cts包运行检测。
“metrics_collector”标签的特殊情况
允许使用metrics_collector但仅限于FilePullerLogCollector类，以便指定要为模块提取和记录的给定文件或目录。如果您将日志留在特定位置并希望自动恢复它们，这将非常有用。
示例配置：
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
构建信息或下载呢？
允许标签的定义可能会给人错误的印象，即模块不会获得任何构建信息。这不是真的。
构建信息由套件级设置提供，并将由套件的所有模块共享。这允许对套件进行单一顶级设置，以便运行套件的所有模块部分。
例如，不是每个兼容性测试套件 (CTS)模块单独查询设备信息、类型等，而是 CTS 套件级设置 ( cts.xml ) 执行一次，并且每个模块都会在请求时接收该信息。
为了让模块中的对象接收构建信息，它们需要执行与常规 Tradefed 配置相同的操作：实现IBuildReceiver接口以接收IBuildInfo 。有关更多详细信息，请参阅使用设备进行测试。
元数据字段
大量的测试模块包括一些metadata规范，每个都有一个独特的目标。
例子：
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
零件
component元数据描述了模块打算测试的一般 Android 组件。它对测试执行没有任何直接影响；它主要用于组织目的。
CtsConfigLoadingTest中提供了 CTS 允许组件的最新列表。如果将不存在的组件添加到 CTS 模块，则此测试在预提交中失败。
您可以使用module-metadata-include-filter和module-metadata-exclude-filter根据组件过滤套件运行。
例子：
--module-metadata-include-filter component framework
此示例仅运行使用framework组件注释的测试模块。
范围
parameter元数据是信息性的，会影响测试执行。它指定测试模块适用于哪个 Android 模式。在这种情况下，模式仅限于高级 Android 模式，例如instant apps 、 secondary users或different abis 。
在套件运行期间，如果该模式适用于测试，则会基于该模式创建测试模块的多个变体。每个变体都运行类似的测试，但在不同的模式下。
-
instant_app：创建将 APK 安装为即时应用程序的测试变体。 -
multi_abi：为设备支持的每个 ABI 创建测试的变体。 -
secondary_user：创建安装 APK 并以次要用户身份运行测试的测试变体。