Test-Suite
Damit ein Test Teil von VTS sein kann, muss er in Android.bp die folgende Einstellung haben:
test_suites: ["vts"],
Wenn Sie den Test außerdem der Suite general-tests hinzufügen, kann er Teil einer Testzuordnungssuite sein, die bei Vorabtests 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, während des Builds automatisch 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 die Testumgebung funktioniert und was die Unterschiede zwischen den einzelnen Testläufern sind. Die automatisch generierte Testkonfigurationsdatei soll diesen Prozess vereinfachen.
Wenn Sie die Test-XML-Datei anpassen müssen, können Sie die automatisch generierte Datei als Ausgangspunkt verwenden.
Führen Sie zuerst den Befehl make aus, um die Konfigurationsdatei zu erstellen, wie unten gezeigt.
$ m VtsHalUsbV1_1TargetTest
Im Ausgabeverzeichnis des Builds 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. Sie können eine beliebige davon verwenden.
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. Andernfalls fügen Sie dem Modul ein test_config-Attribut hinzu, wie im folgenden Beispiel gezeigt.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Jetzt haben Sie 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-Berechtigungen 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 Test-XML-Datei 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 Sie den Test mit beendetem Framework ausführen, 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 Test-XML-Datei Folgendes hinzu.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Zusätzliche Testargumente hinzufügen
Einige gtest-Tests können länger dauern. In solchen Fällen können Sie der XML-Datei Optionen für den Testläufer hinzufügen.
Mit der Einstellung native-test-timeout im folgenden Eintrag kann der Test beispielsweise mit einem Timeout von 3 Minuten anstelle der Standardeinstellung von 1 Minute ausgeführt werden.
<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 bestimmten 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>
API-Level-Attribute
In Android 12 werden die Attribute ro.board.first_api_level und ro.board.api_level definiert, um das API-Level der Anbieterimages auf diesen Geräten anzuzeigen. Wenn Sie diese Attribute mit ro.product.first_api_level kombinieren, wählen Testsuites die richtigen Testfälle 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 Attribute 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
Das ro.board.first_api_level Attribut ist das API-Level, wenn die Anbieterimages
für ein SoC, das für den
Anbieter-Freeze qualifiziert ist, zum ersten Mal
mit diesem Attribut veröffentlicht werden. Dies hängt nicht vom API-Level des Geräts bei der Markteinführung ab, sondern nur vom ersten API-Level des SoC, das diesen Wert definiert. Der Wert ist für die gesamte Lebensdauer des SoC dauerhaft.
Um ro.board.first_api_level festzulegen, können Gerätehersteller BOARD_SHIPPING_API_LEVEL in ihrer Datei device.mk 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
Dadurch wird das Attribut „ro.board.first_api_level“ automatisch auf vendor/build.prop auf dem Gerät festgelegt. Das Attribut wird durch den init-Prozess des Anbieters festgelegt.
ro.board.api_level
Das Attribut ro.board.api_level ist das aktuelle Anbieter-API-Level der Anbieterimages im Format YYYYMM, in dem die Anbieter-API eingefroren wurde. Es wird automatisch vom Build-System festgelegt.
ro.vendor.api_level
Das Attribut ro.vendor.api_level wurde in Android 13 eingeführt, um das API-Level anzugeben, das von den Anbieterimages unterstützt werden muss. Es 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 ein früheres API-Level 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 festgelegt ist, die größer oder gleich 35 ist. Tests für die Anbieterimplementierung, für die ein Upgrade des Anbieterimages erforderlich ist, können von den Anbieteranforderungen für das SoC ausgeschlossen werden, indem auf dieses Attribut verwiesen wird.
Sharding-Prozess mit VTS
Bei Android-Version 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.