Die Gesamtstruktur der Modulkonfiguration folgt einem ähnlichen Muster wie die reguläre Tradefed-XML-Konfiguration, jedoch mit einigen Einschränkungen, da sie als Teil einer Suite ausgeführt werden.
Liste der zulässigen Tags
AndroidTest.xml oder allgemeiner die Modulkonfiguration darf nur die folgenden XML-Tags enthalten: target_preparer, multi_target_preparer, test und metrics_collector.
Diese Liste sieht zwar restriktiv aus, ermöglicht es Ihnen aber, die Anforderungen für die Einrichtung des Testmoduls und den auszuführenden Test genau zu definieren.
HINWEIS: Weitere Informationen zu den verschiedenen Tags finden Sie unter Tradefed-XML-Konfiguration.
Bei Objekten wie build_provider oder result_reporter wird ein ConfigurationException ausgelöst, wenn versucht wird, sie aus einer Modulkonfiguration heraus auszuführen. So soll vermieden werden, dass diese Objekte tatsächlich eine Aufgabe innerhalb eines Moduls ausführen.
Beispiel für die Modulkonfiguration
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Diese Konfiguration beschreibt einen Test, für den CtsGestureTestCases.apk installiert sein muss. Außerdem wird eine Instrumentation für das Paket android.gesture.cts ausgeführt.
Inclusion-Tags <include> und <template-include>
Die Verwendung von <include> und <template-include> in Modulkonfigurationen wird nicht empfohlen. Es wird nicht garantiert, dass sie wie erwartet funktionieren.
Sonderfall für das Tag „metrics_collector“
metrics_collector ist zulässig, aber auf die Klasse FilePullerLogCollector beschränkt, um eine bestimmte Datei oder ein bestimmtes Verzeichnis anzugeben, die bzw. das für das Modul abgerufen und protokolliert werden soll. Das ist nützlich, wenn Sie Protokolle an einem bestimmten Ort ablegen und sie automatisch wiederherstellen möchten.
Konfigurationsbeispiel:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<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" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
Was ist mit Build-Informationen oder Downloads?
Die Definition der zulässigen Tags könnte den falschen Eindruck erwecken, dass ein Modul keine Build-Informationen erhält. Das stimmt nicht.
Die Build-Informationen werden aus der Einrichtung auf Suite-Ebene bereitgestellt und von allen Modulen der Suite gemeinsam genutzt. So ist eine einzelne Einrichtung auf oberster Ebene für die Suite möglich, um alle Module der Suite auszuführen.
Anstatt dass beispielsweise jedes Compatibility Test Suite (CTS)-Modul die Geräteinformationen, Typen usw. einzeln abfragt, erfolgt dies einmalig bei der Einrichtung auf CTS-Suite-Ebene (cts.xml). Jedes Modul erhält diese Informationen dann, wenn es sie anfordert.
Damit die Objekte in einem Modul die Build-Informationen erhalten, müssen sie wie in einer regulären Tradefed-Konfiguration das IBuildReceiver-Interface implementieren, um die IBuildInfo zu erhalten. Weitere Informationen finden Sie unter Mit Gerät testen.
Metadaten-Felder
Viele Testmodule enthalten metadata-Spezifikationen, die jeweils ein bestimmtes Ziel haben.
Beispiel:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Komponente
Die component-Metadaten beschreiben die allgemeine Android-Komponente, die mit dem Modul getestet werden soll. Sie hat keine direkten Auswirkungen auf die Testausführung, sondern dient in erster Linie organisatorischen Zwecken.
Die aktuelle Liste der zulässigen Komponenten für CTS ist in CtsConfigLoadingTest verfügbar. Dieser Test schlägt bei der Vorabübermittlung fehl, wenn einem CTS-Modul eine nicht vorhandene Komponente hinzugefügt wird.
Sie können einen Suite-Lauf anhand der Komponenten mit module-metadata-include-filter und module-metadata-exclude-filter filtern.
Beispiel:
--module-metadata-include-filter component framework
In diesem Beispiel wird nur das Testmodul ausgeführt, das mit der Komponente framework annotiert ist.
Parameter
Die parameter-Metadaten dienen der Information und wirken sich auf die Ausführung des Tests aus. Gibt an, für welchen Android-Modus das Testmodul gilt.
In diesem Fall sind Modi auf Android-Modi auf hoher Ebene beschränkt, z. B. instant apps, secondary users oder different abis.
Während der Ausführung der Suite werden, sofern der Modus auf den Test angewendet wird, basierend auf dem Modus mehrere Varianten des Testmoduls erstellt. Bei jeder Variante werden ähnliche Tests, aber in unterschiedlichen Modi ausgeführt.
instant_app: Erstellen Sie eine Variante der Tests, bei denen APKs als Instant Apps installiert werden.multi_abi: Erstellen Sie für jede vom Gerät unterstützte ABI eine Variante der Tests.secondary_user: Erstellen Sie eine Variante der Tests, bei der APKs als sekundärer Nutzer installiert und Tests ausgeführt werden.
Messwerte erfassen und nachbearbeiten für Leistungsprüfungsmodule
Für Leistungsprüfungsmodule sind metrics_collector und metric_post_processor auf Modulebene zulässig, da sie für Leistungsprüfungen unerlässlich sind.
Die Messwerterfassung und die Nachbearbeitung auf Modulebene können modulspezifisch sein.
Es wird nicht empfohlen, Postprozessoren sowohl auf der obersten Ebene als auch auf Modulebene anzugeben.
Eine Konfiguration für ein Leistungsmodul muss die Metadaten test-type mit dem Wert performance enthalten, z. B.:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Andernfalls schlägt der Test beim Pre-Submit fehl, wenn eine Testkonfiguration metric_collector außer FilePullerLogCollector oder metric_post_processor enthält.
Beispielkonfiguration für ein Leistungsmodul:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>