Die Konfigurationen von Tradefed folgen einer XML-Struktur, um den auszuführenden Test und die vorzubereitenden/einzurichtenden Schritte zu beschreiben.
Theoretisch kann alles in der XML für einen einzelnen Befehl definiert werden. In der Praxis ist es jedoch praktischer, XML-Dateien für die Basisvorlage zu verwenden und sie mit zusätzlichen Befehlszeilenparametern anzupassen.
Struktur
<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>
Das gesamte Tradefed-XML wird durch <configuration>-Tags begrenzt. Tradefed
objects werden in eigenen Tags definiert, z. B. build_provider, target_preparer, test usw. Ihre jeweiligen Zwecke werden im Abschnitt Architektur genauer beschrieben.
Für jedes Objekt ist die Java-Klasse, die dem Objekt zugeordnet ist, in class= definiert und wird zur Laufzeit aufgelöst. Solange sich die JAR-Datei mit der Klasse also im Tradefed-Java-Klassenpfad befindet, wenn sie ausgeführt wird, wird sie gefunden und aufgelöst.
Reihenfolge von Tradefed-Objekten
Die Reihenfolge der verschiedenen Tags spielt keine Rolle. Es macht beispielsweise keinen Unterschied, ob build_provider nach target_preparer angegeben wird. Der Ablauf des Testaufrufs wird vom Harness selbst erzwungen, sodass die Methoden immer in der richtigen Reihenfolge aufgerufen werden.
Die Reihenfolge von Objekten mit demselben Tag ist wichtig. Wenn beispielsweise zwei target_preparer-Objekte definiert sind, werden sie in der Reihenfolge ihrer Definition im XML aufgerufen. Das ist wichtig, da sich dadurch der Endstatus der Geräteeinrichtung ändern kann. Ein APK flashen und dann installieren ist beispielsweise nicht dasselbe wie ein APK installieren und dann flashen, da beim Flashen die Daten auf dem Gerät gelöscht werden.