Test-Suite
Damit ein Test Teil von VTS ist, muss er die folgende Einstellung in Android.bp haben.
test_suites: ["vts"],
Wenn Sie den Test der Suite general-tests hinzufügen, kann er außerdem Teil einer Test Mapping-Suite sein, die bei Pre-Submit-Prüfungen verwendet wird.
Testkonfiguration
In den meisten Fällen wird die Testkonfiguration, eine XML-Datei, die von Trade Federation zum Ausführen eines VTS-Tests verwendet wird, automatisch während des Builds generiert. Sie können die Testkonfiguration jedoch anpassen.
Benutzerdefinierte Testkonfigurationsdatei erstellen
Das Erstellen einer neuen Test-XML-Datei von Grund auf kann kompliziert sein, da Sie wissen müssen, wie der Testharness funktioniert und was die Unterschiede zwischen den einzelnen Test-Runnern sind. Die automatisch generierte Testkonfigurationsdatei soll diesen Prozess vereinfachen.
Wenn Sie die XML-Datei für den Test anpassen müssen, können Sie die automatisch generierte Datei als Ausgangspunkt verwenden.
Führen Sie zuerst den Befehl make aus, um die Konfiguration zu erstellen, wie unten gezeigt, um die automatisch generierte Testkonfigurationsdatei zu finden.
$ m VtsHalUsbV1_1TargetTest
Im Build-Ausgabeordner können Sie anhand des Modulnamens nach der Konfigurationsdatei suchen, wie unten gezeigt.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Es kann mehrere Kopien der Datei geben, die Sie alle verwenden können.
Kopieren Sie die Datei .config in das Verzeichnis, in dem sich die Datei Android.bp befindet.
Wenn in der Datei Android.bp nur ein Testmodul vorhanden ist, können Sie die XML-Datei in AndroidTest.xml umbenennen. Das Build-System verwendet sie dann automatisch als Konfigurationsdatei des Testmoduls. Fügen Sie andernfalls dem Modul ein test_config-Attribut hinzu, wie im Beispiel unten gezeigt.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Sie haben jetzt eine Testkonfigurationsdatei, mit der Sie arbeiten und die Anpassung implementieren können.
Test mit „adb root“ erzwingen
Für die meisten VTS-Tests sind Root-Rechte erforderlich. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.
require_root: true,
Wenn die Testkonfigurationsdatei angepasst wurde, fügen Sie der XML-Datei für den Test Folgendes hinzu.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Framework während des Tests beenden
Für viele VTS-Tests ist kein Android-Framework erforderlich. Wenn der Test ohne Framework ausgeführt wird, kann er stabil ausgeführt werden, ohne von Gerätefehlern beeinträchtigt zu werden. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.
disable_framework: true,
Wenn die Testkonfigurationsdatei angepasst wurde, fügen Sie der XML-Datei für den Test Folgendes hinzu.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Zusätzliche Testargumente hinzufügen
Für einige gtest-Tests kann mehr Zeit erforderlich sein. In solchen Fällen können Sie Testrunner-Optionen in der XML-Datei hinzufügen.
Die Einstellung native-test-timeout im folgenden Eintrag ermöglicht beispielsweise, dass der Test mit einem Zeitlimit von 3 Minuten anstelle des Standardwerts von 1 Minute ausgeführt wird.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
Mindest-API-Level erforderlich
Einige VTS-Tests können nur auf Geräten mit einem Mindest-API-Level ausgeführt werden. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.
min_shipping_api_level: 29,
oder
vsr_min_shipping_api_level: 202404,
Wenn die Testkonfigurationsdatei angepasst wurde, fügen Sie der Test-XML-Datei den folgenden Befehl hinzu.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
oder
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Attribute für API-Level
In Android 12 werden die Eigenschaften ro.board.first_api_level und ro.board.api_level definiert, um den API-Level der Anbieterimages auf diesen Geräten anzuzeigen. Wenn Sie diese Eigenschaften mit ro.product.first_api_level kombinieren, wählt die Test-Suite die richtigen Testläufe für die Geräte aus.
In Android 13 wird ro.vendor.api_level definiert, das automatisch festgelegt wird, indem das erforderliche Anbieter‑API‑Level anhand der Eigenschaften ro.product.first_api_level, ro.board.first_api_level und ro.board.api_level berechnet wird.
Weitere Informationen finden Sie unter Anbieter‑API‑Level.
ro.board.first_api_level
Die Eigenschaft ro.board.first_api_level ist das API-Level, wenn die Anbieter-Images für ein SoC, das für Vendor Freeze qualifiziert ist, zum ersten Mal mit dieser Eigenschaft veröffentlicht werden. Dies hängt nicht vom API-Level des Geräts beim Launch ab, sondern nur vom ersten API-Level des SoC, das diesen Wert definiert. Der Wert ist für die gesamte Lebensdauer des SoC konstant.
Um ro.board.first_api_level festzulegen, können Gerätehersteller BOARD_SHIPPING_API_LEVEL in ihrer device.mk-Datei definieren, wie im folgenden Beispiel gezeigt:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
Die Property „ro.board.first_api_level“ wird auf dem Gerät automatisch auf vendor/build.prop festgelegt. Die Property wird vom init-Prozess des Anbieters festgelegt.
ro.board.api_level
Das Attribut ro.board.api_level ist das aktuelle Anbieter‑API‑Level der Anbieter-Images im Format YYYYMM, in dem die Anbieter‑API eingefroren wurde. Sie wird automatisch vom Build-System festgelegt.
ro.vendor.api_level
Die Eigenschaft ro.vendor.api_level wurde in Android 13 eingeführt, um das API-Level anzugeben, das von den Anbieter-Images unterstützt werden muss. Dieser Wert wird automatisch auf ro.product.first_api_level oder ro.board.api_level festgelegt, wenn ro.board.first_api_level vorhanden ist und ro.board.api_level auf eine frühere API-Ebene als ro.product.first_api_level festgelegt ist. Die Version wird durch das entsprechende Anbieter-API-Level ersetzt, wenn sie auf die Version von ro.product.first_api_level gesetzt ist, die größer oder gleich 35 ist. Tests für die Anbieterimplementierung, die ein Upgrade des Anbieterimages erfordern, können durch Verweis auf diese Eigenschaft von den Anbieteranforderungen für den SoC ausgeschlossen werden.
Sharding-Prozess mit VTS
Bei Android 10 oder höher können Sie den Sharding-Prozess auf mehreren Geräten durchführen, während Sie sowohl mit VTS- als auch mit CTS‑on‑GSI-Plänen testen. Folgen Sie dazu der Anleitung unten.
run vts --shard-count <number of devices> -s <device serial> ...
Mit diesem Befehl wird der VTS-Plan in Shards aufgeteilt und auf mehreren Geräten ausgeführt.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Mit diesem Befehl wird der CTS-on-GSI-Plan in Shards aufgeteilt und auf mehreren Geräten ausgeführt.