Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Testeinrichtung
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 Föderation für die Durchführung eines VTS-Tests, wird automatisch die während des Build-Vorgangs generiert wurden. Sie können jedoch die Testkonfiguration.

Benutzerdefinierte Testkonfigurationsdatei erstellen

Das Erstellen einer neuen Test-XML-Datei von Grund auf kann schwierig 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 die Datei Android.bp nur ein Testmodul enthält, kannst du Benennen Sie die XML-Datei in AndroidTest.xml um. Das Build-System wird automatisch verwendet sie als Konfigurationsdatei des Testmoduls. Andernfalls Fügen Sie dem Modul ein test_config-Attribut hinzu, wie in den Beispiel unten.

test_config: "VtsHalUsbV1_1TargetTest.xml",

Jetzt verfügen Sie über eine Testkonfigurationsdatei, mit der Sie arbeiten und diese implementieren können. für die Anpassung.

Test mit adb root erzwingen

Die meisten VTS-Tests erfordern Root-Berechtigungen, um ausgeführt zu werden. Wenn die Testkonfiguration automatisch generiert wird, können Sie das folgende Attribut zu Android.bp 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 Testkonfiguration automatisch generiert wird, können Sie das folgende Attribut zu Android.bp 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 in der XML-Datei angeben.

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

Einige VTS-Tests können nur auf Geräten mit einem bestimmten Mindest-API-Level ausgeführt werden. Wenn die Testkonfigurationsdatei automatisch generiert, können Sie Folgendes hinzufügen: auf Android.bp.

min_shipping_api_level: 29,

oder

vsr_min_shipping_api_level: 202404,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie den Parameter folgenden Befehl in die Test-XML-Datei um.

   <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 ro.board.first_api_level und ro.board.api_level-Properties, auf denen das API-Level der Anbieterbilder angezeigt werden soll für diese Geräte. 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.

In Android 13 wird ro.vendor.api_level definiert, automatisch festgelegt, indem das erforderliche API-Level des Anbieters mithilfe der ro.product.first_api_level, ro.board.first_api_level und ro.board.api_level Properties.

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. Die bleibt 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 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 Eigenschaft „ro.board.first_api_level“ wird automatisch so definiert, vendor/build.prop auf dem Gerät. Das Attribut wird vom Anbieter init 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. Sie wird automatisch vom Build-System festgelegt.

ro.vendor.api_level

Das Attribut ro.vendor.api_level wurde eingeführt in Android 13 zur Anzeige des API-Levels, das der Anbieter abbildet sind für den Support erforderlich. Dies wird automatisch auf den Wert ro.product.first_api_level oder ro.board.api_level, wenn ro.board.first_api_level ist vorhanden und ro.board.api_level ist festgelegt auf frühere API-Ebene als ro.product.first_api_level. 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 Anbieter-Implementierungen, die ein Upgrade eines Anbieter-Images erfordern, für das SoC durch den Verweis auf diese Eigenschaft.

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> ...

Dieser Befehl teilt den VTS-Plan in Shards auf und führt diese auf mehreren Geräten aus.

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äte.

Testeinrichtung Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.