Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
High-level structure of Tradefed XML configuration
Stay organized with collections
Save and categorize content based on your preferences.
Tradefed's configurations follow an XML structure to describe the test to be run
and the preparation/setup steps to be done.
In theory, everything can be defined in the XML for a single command. But in
practice, it is more practical to have base template XML files and customize
them with extra command line parameters.
Structure
<configuration description="<description of the configuration>">
<!-- A build provider that takes local device information -->
<build_provider class="com.android.tradefed.build.BootstrapBuildProvider" />
<!-- Some target preparation, disabled by default -->
<target_preparer class="com.android.tradefed.targetprep.PreloadedClassesPreparer">
<option name="disable" value="true" />
</target_preparer>
<!-- One test running some unit tests -->
<test class="com.android.tradefed.testtype.HostTest">
<option name="class" value="com.android.tradefed.build.BuildInfoTest" />
</test>
<!-- [OPTIONAL] -->
<logger class="com.android.tradefed.log.FileLogger">
<option name="log-level" value="VERBOSE" />
<option name="log-level-display" value="VERBOSE" />
</logger>
<!-- [OPTIONAL] -->
<log_saver class="com.android.tradefed.result.FileSystemLogSaver" />
<!-- As many reporters as we want -->
<result_reporter class="com.android.tradefed.result.ConsoleResultReporter" />
<result_reporter class="com.android.tradefed.result.suite.SuiteResultReporter" />
<result_reporter class="com.android.tradefed.result.MetricsXMLResultReporter"/>
</configuration>
The overall Tradefed XML is delimited by <configuration> tags. Tradefed
objects are defined in their own tags, for example: build_provider,
target_preparer, test, etc. Their individual purposes are described in more
detail in the Architecture
section.
Each object has the Java class associated with the object defined in class=
that is resolved at runtime; so as long as the JAR file containing the class is
on the Tradefed Java classpath when running, it will be found and resolved.
Orders of Tradefed objects
The order of the different tags does not matter. For example, it makes no
difference if build_provider is specified after target_preparer. The flow of
the test invocation is enforced by the harness itself, so it will always call
them in the right order.
The order of objects with the same tag does matter. For example, two
target_preparer objects defined will be called in their order of definition in
the XML. It is important to understand this as it can change the end state of
the device setup. For example, flashing then installing an apk would not be the
same as installing an apk and flashing since flashing would wipe the device.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-12 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-12 UTC."],[],[],null,["# High-level structure of Tradefed XML configuration\n\nTradefed's configurations follow an XML structure to describe the test to be run\nand the preparation/setup steps to be done.\n\nIn theory, everything can be defined in the XML for a single command. But in\npractice, it is more practical to have base template XML files and customize\nthem with extra command line parameters.\n\nStructure\n---------\n\n \u003cconfiguration description=\"\u003cdescription of the configuration\u003e\"\u003e\n \u003c!-- A build provider that takes local device information --\u003e\n \u003cbuild_provider class=\"com.android.tradefed.build.BootstrapBuildProvider\" /\u003e\n\n \u003c!-- Some target preparation, disabled by default --\u003e\n \u003ctarget_preparer class=\"com.android.tradefed.targetprep.PreloadedClassesPreparer\"\u003e\n \u003coption name=\"disable\" value=\"true\" /\u003e\n \u003c/target_preparer\u003e\n\n \u003c!-- One test running some unit tests --\u003e\n \u003ctest class=\"com.android.tradefed.testtype.HostTest\"\u003e\n \u003coption name=\"class\" value=\"com.android.tradefed.build.BuildInfoTest\" /\u003e\n \u003c/test\u003e\n\n \u003c!-- [OPTIONAL] --\u003e\n \u003clogger class=\"com.android.tradefed.log.FileLogger\"\u003e\n \u003coption name=\"log-level\" value=\"VERBOSE\" /\u003e\n \u003coption name=\"log-level-display\" value=\"VERBOSE\" /\u003e\n \u003c/logger\u003e\n\n \u003c!-- [OPTIONAL] --\u003e\n \u003clog_saver class=\"com.android.tradefed.result.FileSystemLogSaver\" /\u003e\n\n \u003c!-- As many reporters as we want --\u003e\n \u003cresult_reporter class=\"com.android.tradefed.result.ConsoleResultReporter\" /\u003e\n \u003cresult_reporter class=\"com.android.tradefed.result.suite.SuiteResultReporter\" /\u003e\n \u003cresult_reporter class=\"com.android.tradefed.result.MetricsXMLResultReporter\"/\u003e\n \u003c/configuration\u003e\n\nThe overall Tradefed XML is delimited by `\u003cconfiguration\u003e` tags. `Tradefed\nobjects` are defined in their own tags, for example: `build_provider`,\n`target_preparer`, `test`, etc. Their individual purposes are described in more\ndetail in the [Architecture](/docs/core/tests/tradefed/architecture)\nsection.\n\nEach object has the Java class associated with the object defined in `class=`\nthat is resolved at runtime; so as long as the JAR file containing the class is\non the Tradefed Java classpath when running, it will be found and resolved.\n\nOrders of Tradefed objects\n--------------------------\n\nThe order of the different tags does not matter. For example, it makes no\ndifference if `build_provider` is specified after `target_preparer`. The flow of\nthe test invocation is enforced by the harness itself, so it will always call\nthem in the right order.\n\nThe order of objects with the **same tag does matter** . For example, two\n`target_preparer` objects defined will be called in their order of definition in\nthe XML. It is important to understand this as it can change the end state of\nthe device setup. For example, *flashing then installing an apk* would not be the\nsame as *installing an apk and flashing* since flashing would wipe the device."]]
