Test-Suite
Damit ein Test Teil von VTS ist, muss er in Android.bp die folgende Einstellung haben.
test_suites: ["vts"],
Wenn Sie den Test der Suite general-tests hinzufügen, kann er auch Teil einer Test-Mapping-Suite sein, die bei Vorabprü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, 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 die Funktionsweise des Test-Harness und den Unterschied zwischen den einzelnen Testläufern kennen müssen. 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.
Um die automatisch generierte Testkonfigurationsdatei zu finden, führen Sie zuerst den Befehl make aus, um die Konfiguration zu erstellen, wie unten gezeigt.
$ m VtsHalUsbV1_1TargetTest
Im Build-out-Verzeichnis 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 und Sie können eine beliebige davon verwenden.
Kopieren Sie die Datei .config in das Verzeichnis, in dem sich die Datei Android.bp befindet.
Wenn sich in der Datei Android.bp nur ein Testmodul befindet, 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 ist, 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 das Android-Framework nicht erforderlich. Wenn der Test ohne Framework ausgeführt wird, ist er stabiler und nicht von Geräteausfällen betroffen. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.
disable_framework: true,
Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie der Test-XML-Datei Folgendes hinzu.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Zusätzliche Testargumente hinzufügen
Für einige gtest-Tests ist möglicherweise mehr Zeit erforderlich. In solchen Fällen können Sie Optionen für den Testausführer in die XML-Datei einfügen.
Die Einstellung native-test-timeout im folgenden Eintrag ermöglicht beispielsweise die Ausführung des Tests mit einem Zeitlimit von 3 Minuten anstelle des Standardwerts von 1 Minute.
<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 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 ist, 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 Eigenschaften ro.board.first_api_level und ro.board.api_level definiert, um die API-Ebene der Anbieterbilder auf diesen Geräten anzuzeigen. Wenn Sie diese Eigenschaften mit ro.product.first_api_level kombinieren, wählen Test-Suites geeignete Testfälle für die Geräte aus.
Unter Android 13 wird ro.vendor.api_level definiert. Dieser Wert wird automatisch festgelegt, indem das erforderliche API-Level des Anbieters 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 API-Level des Anbieters.
ro.board.first_api_level
Die Property ro.board.first_api_level ist die API-Ebene, wenn die Anbieter-Images für ein SoC, das für den Anbieter-Freeze qualifiziert ist, zum ersten Mal mit dieser Property veröffentlicht werden. Dies hängt nicht vom API-Level des Geräts ab, sondern nur von der ersten API-Ebene des SoC, die diesen Wert definiert. Der Wert bleibt für die gesamte Lebensdauer des SoC unverändert.
Zum Festlegen von ro.board.first_api_level 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 automatisch auf dem Gerät auf vendor/build.prop festgelegt. Das Attribut wird vom Anbieter-init-Prozess festgelegt.
ro.board.api_level
Das Attribut ro.board.api_level ist die aktuelle Anbieter-API-Ebene der Anbieter-Images im Format YYYYMM, in dem die Anbieter-API eingefroren wurde. Er wird automatisch vom Build-System festgelegt.
ro.vendor.api_level
Die Property ro.vendor.api_level wurde in Android 13 eingeführt, um die API-Ebene anzugeben, die die Anbieterbilder unterstützen müssen. 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 die entsprechende Anbieter-API-Ebene 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, die ein Anbieter-Image-Upgrade erfordern, können durch Verweis auf diese Eigenschaft von den Anbieteranforderungen für das SoC ausgeschlossen werden.
Sharding-Prozess mit VTS
Bei Android 10 oder höher können Sie das Sharding auf mehreren Geräten ausführen und dabei sowohl VTS- als auch CTS-on-GSI-Pläne 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 ...
Dieser Befehl teilt den CTS-on-GSI-Plan in Shards auf und führt diese auf mehreren Geräten aus.