AndroidTest.xml Structure

The overall structure of the module configuration follows a similar pattern to the regular Tradefed XML configuration but with some restrictions due to the fact that they run as part of a suite.

List of allowed tags

AndroidTest.xml or more broadly module configuration can contain only the following XML tags: target_preparer, multi_target_preparer, test and metrics_collector.

Although that list looks restrictive, it allows you to precisely define test module setup needs and the test to run.

NOTE: See Tradefed XML configuration if you need a refresher on the different tags.

Objects such as build_provider or result_reporter will raise a ConfigurationException if attempted to be run from inside a module configuration. This is meant to avoid the expectation of these objects actually performing some task from within a module.

Example module configuration

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    <test class="" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />

This configuration describes a test that requires CtsGestureTestCases.apk to be installed and will run an instrumentation against the android.gesture.cts package.

Special case for "metrics_collector" tag

The metrics_collector is allowed but limited to the FilePullerLogCollector class in order to specify a given file or directory to be pulled and logged for the module. This is useful if you are leaving logs in a particular location and would like to automatically recover them.

Example configuration:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="">
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    <test class="" >
        <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" />

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />

What about build infos or downloads?

The definition of the allowed tags might give the incorrect impression that a module will not get any build information. This is not true.

The build information is provided from the suite-level setup and will be shared by all the modules of the suite. This allows a single top-level setup for the suite in order to run all the modules part of the suite.

For example, instead of each Compatibility Test Suite (CTS) module individually querying the device information, types, etc., the CTS suite-level setup (cts.xml) does it once and each module will receive that information if they request it.

In order for the objects in a module to receive the build information, they need to do the same as in regular Tradefed configuration: implement the IBuildReceiver interface to receive the IBuildInfo. See testing with device for more details.