Tradefed-Konfigurationen folgen einer XML-Struktur, um den auszuführenden Test zu beschreiben und die erforderlichen Vorbereitungs-/Einrichtungsschritte.
Theoretisch kann in der XML alles für einen einzigen Befehl definiert werden. Aber in ist es praktischer, XML-Dateien mit Basisvorlagen zu haben und mit zusätzlichen Befehlszeilenparametern.
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>
Die gesamte Tradefed-XML-Datei ist durch <configuration>-Tags getrennt. Tradefed
objects werden in eigenen Tags definiert, z. B. build_provider,
target_preparer, test usw. Ihre jeweiligen Zwecke werden in den
in der Architektur
.
Bei jedem Objekt ist die Java-Klasse mit dem in class= definierten Objekt verknüpft.
das zur Laufzeit aufgelöst wird. solange die JAR-Datei, die die Klasse enthält,
im Tradefed-Java-Klassenpfad während der Ausführung, wird er gefunden und aufgelöst.
Bestellungen von Tradefed-Objekten
Die Reihenfolge der Tags spielt dabei keine Rolle. Zum Beispiel ist keine
Differenz, wenn build_provider nach target_preparer angegeben wird. Der Fluss von
wird der Testaufruf vom Harness selbst erzwungen, daher ruft er immer
in die richtige Reihenfolge bringen.
Die Reihenfolge von Objekten mit demselben Tag ist wichtig. Zwei Beispiele
target_preparer definierte Objekte werden in der Reihenfolge der Definition in
der XML-Datei. Es ist wichtig, dies zu verstehen, da sich dadurch der Endzustand eines
die Geräteeinrichtung. Beispielsweise ist Blinken und anschließendes Installieren einer APK-Datei nicht der Fall,
wie bei der Installation einer APK-Datei und des Flashens, da durch das Flashen das Gerät gelöscht wird.