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 wie unten gezeigt nach der Konfigurationsdatei suchen, die dem Modulnamen entspricht.
$ 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 Beispiel unten gezeigt.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Sie haben jetzt eine Testkonfigurationsdatei, mit der Sie 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 kann die Ausführung länger dauern. In solchen Fällen können Sie Optionen für den Testausführer in die XML-Datei einfügen.
Mit der Einstellung native-test-timeout im folgenden Eintrag kann der Test beispielsweise mit einem Zeitlimit von 3 Minuten statt dem Standardwert 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 vorschreiben
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 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>
Eigenschaften auf API-Ebene
Unter Android 12 werden die Eigenschaften ro.board.first_api_level und ro.board.api_level definiert, um die API-Ebene der Anbieterimages auf diesen Geräten anzuzeigen. Wenn Sie diese Eigenschaften mit ro.product.first_api_level kombinieren, wählen Test-Suites die richtigen Testfälle für die Geräte aus.
Unter Android 13 wird ro.vendor.api_level automatisch festgelegt, 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 ro.board.first_api_level-Eigenschaft 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 vom ersten API-Level des SoC, das diesen Wert definiert. Der Wert bleibt für die gesamte Lebensdauer des SoC unverändert.
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 automatisch auf dem Gerät auf vendor/build.prop festgelegt. Die Property wird vom Anbieter über den init-Prozess 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 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 verwenden. 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.