android 构造xml,AndroidTest.xml 结构

模块配置的整体结构遵循与常规 Tradefed XML 配置类似的模式，但由于它们作为套件的一部分运行而具有一些限制。

允许的标记列表

AndroidTest.xml 或更宽泛的模块配置只能包含以下 XML 标记：target_preparer、multi_target_preparer、test 和 metrics_collector。

虽然该列表看起来有局限性，但您可以通过该列表精确地定义测试模块设置需求以及要运行的测试。

注意：如果您需要复习一下不同的标记，请参阅 Tradefed XML 配置。

如果尝试从模块配置内部运行，则 build_provider 或 result_reporter 等对象会引发 ConfigurationException。这是为了避免期望这些对象实际上从模块内执行某项任务。

模块配置示例

此配置描述的测试要求安装 CtsGestureTestCases.apk 并将针对 android.gesture.cts 软件包运行插桩 (instrumentation)。

“metrics_collector”标记的特殊情况

系统允许 metrics_collector，但仅限于 FilePullerDropbox 类，以指定要为模块提取和记录的给定文件或目录。如果要将日志保留在特定位置，并且希望自动恢复这些日志，则该权限会非常有用。

配置示例

版本信息或下载内容怎么样？

允许的标记的定义可能会给人错误的印象，让人误认为模块不会获取任何版本信息。但事实并非如此。

版本信息由套件级设置提供，并且将由套件的所有模块共享。这允许为套件提供单个顶级设置，以便运行套件中的所有模块。

例如，并非每个兼容性测试套件 (CTS)模块单独查询设备信息、类型等，CTS 套件级设置(cts.xml )发送一次，每个模块都将收到这些信息(如果他们请求)。

为了使模块中的对象接收 build 信息，它们需要执行与常规 Tradefed 配置中相同的操作：实现 IBuildReceiver 接口以接收 IBuildInfo。如需了解详情，请参阅使用设备进行测试。

元数据字段

大量的测试模块包含一些 metadata 规范，每个规范都有唯一的目标。

示例：

组件

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 和测试作为次要用户的测试的变体。