This section describes the internals of Tradefed and their relationships. See the linked subpages for more details.
1. Test Configuration (XML configs)
Test configurations in Tradefed are described in an XML format. Understanding the structure of the configuration is key to running and customizing tests.
Structure of TF configurations
Global TF configurations
Global Configuration is a special Tradefed XML configuration that is loaded when
Tradefed starts via the
TF_GLOBAL_CONFIG environment variable. It loads
objects related to the Tradefed instance scope that will affect the overall
Keystore allows injection of command line options to Tradefed coming from a keystore in order to avoid referencing the value directly on the command line. This can be used to hide passwords from the command line by retrieve passwords from the keystore directly.
2. Device manager
The Device Manager is responsible for keeping track of the state of devices on a running instance of Tradefed. Aspects such as allocation status and online status are monitored.
3. Test Command Scheduler
The Test Command Scheduler in Tradefed takes commands to run, associates them with devices, and starts a test invocation.
4. Build provider
Build Provider is the first step of any test invocation. It downloads resources
needed to set up and run the tests (build images, test APKs, and more.). It also
references them in a
BuildInfo object that will be passed to the test. Locally
available resources can also be linked in the
5. Target Preparer and Cleaner
Target Preparer offers optional actions that can be taken to configure the target under test into a certain state, for example flashing the device, setting certain properties, and connecting to Wi-Fi.
6. Test Runner
A Test Runner in Tradefed refers to the object responsible for the actual test execution. Different test runners drive test execution in different ways; for example, an instrumentation test runner will be very different from a JUnit test runner.
7. Result Reporter
Result Reporter in Tradefed refers to the object that will send the results to a particular destination. Each implementation is usually specialized for different result back-ends. And the Result Reporter is in charge of converting the Tradefed results format into the destination format.
This flexible design allows any test to report to any of the results destinations and to easily have more tests added in an isolated way.
8. Metrics Collector
Metrics Collector is a special object in Tradefed, orthogonal to the test execution. It allows collection of information at different points of the test lifecycle (for example, test start, test end). Since the collector is decoupled from the test itself, the points can be swapped, added, and removed without having to change the test itself.
9. Host-wide setup
This section describes setups that are applicable to a full Tradefed instance's running. These options affect the behavior of the harness as a whole in order to adapt to different environments, for example being in a restricted network.
10. Additional features
The following sections describe general usage of Tradefed rather than Tradefed objects.
When the test corpus is large or takes a long time to execute, it's possible to split it across several devices. We refer to this split as sharding. This section describes how sharding works and how it is configured.
Tradefed supports the scripting layer for Android, SL4A; this is an automation toolset for calling Android APIs in a platform-independent manner.
Dynamic @Option download
In some cases, the files needed by a test or some particular operation are not available locally. This feature allows Tradefed to get these files from a remote location without going through a Build Provider.