CTS Verifier-Hostseitentests ausführen

Auf dieser Seite finden Sie eine Anleitung zum Einrichten und Ausführen von Host-seitigen Android 16 QPR2- und Android 17-Tests für CTS Verifier (CTS-V). Es gibt zwei Arten von Host-seitigen Tests: Tests für mehrere Geräte (vor Android 17 eingeführt) und interaktive Tests (neu in Android 17):

  • Tests auf mehreren Geräten sind vollständig automatisierte Tests.
  • Interaktive Tests sind halbautomatische Tests, bei denen Sie einige manuelle Schritte auf dem zu testenden Gerät ausführen müssen.

Zusätzlich zu den neuen interaktiven Tests sind die Tests zur manuellen Bereichsgenauigkeit und die Telekommunikationstests jetzt Host-seitige Tests für mehrere Geräte. Außerdem sind WLAN-Verbindungstests erforderlich.

Hostseitige Tests einrichten

So richten Sie Host-seitige Tests ein (für Tests auf mehreren Geräten ist eine zusätzliche Einrichtung erforderlich):

  1. Prüfen Sie, ob Ihr Desktopcomputer die Systemanforderungen für CTS erfüllt.

  2. Folgen Sie Schritt 2 und Schritt 5 der Anleitung unter Desktopsoftware installieren, um zu prüfen, ob adb, AAPT2 und Python auf Ihrem Computer richtig installiert sind.

    • Die Desktop-Python-Version sollte 3.11 oder höher sein. Führen Sie python3 --version aus, um die Python-Version zu ermitteln. Wenn die Version niedriger als 3.11 ist, installieren Sie die neueste offizielle Python-Version. Weitere Informationen finden Sie im Abschnitt „Downloads“ von python.org.

    • Für einige Tests muss auf dem Host das Python-Modul venv installiert sein. Auf Debian- und Ubuntu-Systemen ist dieses Modul möglicherweise nicht standardmäßig installiert. Führen Sie python3 -m venv venv aus, um festzustellen, ob die Desktop-Python-Version das Modul venv enthält. Wenn dieser Befehl fehlschlägt, wird eine Fehlermeldung angezeigt. Folgen Sie der Anleitung, um das python3.x-venv-Paket zu installieren.

Wenn Sie nur die interaktiven Tests auf der Hostseite ausführen, fahren Sie mit Tests auf der Hostseite ausführen fort. Wenn Sie jedoch Tests auf mehreren Geräten ausführen möchten, fahren Sie mit Hostseitige Tests auf mehreren Geräten einrichten fort.

Hostseitige Tests auf mehreren Geräten einrichten

So richten Sie geräteübergreifende Tests auf Hostseite ein:

  1. Prüfen Sie, ob Ihr Desktopcomputer die Systemanforderungen für CTS erfüllt.

  2. Folgen Sie Schritt 2 und Schritt 5 der Anleitung unter Desktopsoftware installieren, um zu prüfen, ob adb, AAPT2 und Python auf Ihrem Computer richtig installiert sind.

    • Die Desktop-Python-Version sollte 3.11 oder höher sein. Führen Sie python3 --version aus, um die Python-Version zu ermitteln. Wenn die Version niedriger als 3.11 ist, installieren Sie die neueste offizielle Python-Version. Weitere Informationen finden Sie im Abschnitt „Downloads“ von python.org.

      • Für einige Tests muss auf dem Host das Python-Modul venv installiert sein. Auf Debian- und Ubuntu-Systemen ist dieses Modul möglicherweise nicht standardmäßig installiert. Führen Sie python3 -m venv venv aus, um festzustellen, ob die Desktop-Python-Version das Modul venv enthält. Wenn dieser Befehl fehlschlägt, wird eine Fehlermeldung angezeigt. Folgen Sie der Anleitung, um das python3.x-venv-Paket zu installieren.

  3. Bereiten Sie zwei passende Testgeräte vor, auf denen jeweils CTS-V eingerichtet ist.

    • Weitere Informationen zum Einrichten eines DUT finden Sie unter DUT einrichten.
    • Weitere Informationen zum Einrichten von CTS-V finden Sie unter Einrichtung.

  4. Rufen Sie den Einrichtungsabschnitt für Ihren Testtyp auf:

Wenn Ihr Test nicht in dieser Liste enthalten ist, fahren Sie mit Standardtests mit zwei Geräten einrichten fort.

NFC-Tests einrichten

Für NFC-Tests wird ein zu testendes Gerät und ein PN532-NFC-Chip verwendet.

So richten Sie NFC-Tests ein:

  1. Kaufen Sie einen PN532-NFC-Chip. Wir empfehlen das All-In-One PN532.
  2. Öffnen Sie auf dem zu testenden Gerät die Einstellungen.
  3. Aktivieren Sie NFC.

  4. NFC-Chip positionieren:

    • Bei Smartphones muss das NFC-Lesegerät des Prüflings wie in Abbildung 1 positioniert werden:

      Positionierung des NFC-Chips

      Abbildung 1. Positionierung des NFC-Chips

    • Bei anderen Gerätetypen halten Sie den Chip an die NFC-Antenne des Geräts.

  5. Verbinden Sie den PN532-NFC-Chip über ein USB-Kabel mit Ihrer Test-Workstation.

WLAN-AP-Verbindungstests einrichten

Mit den Verbindungstests für WLAN-Zugangspunkte (CtsWifiConnectionTests) wird die Verbindung zwischen einem DUT und einem Zugangspunkt getestet. Sie haben zwei Möglichkeiten, diese Tests einzurichten:

  • Option 1: Verwenden Sie ein vorhandenes WLAN, das Sie für CTS-V eingerichtet haben.
  • Option 2: Programmierbaren Zugangspunkt (AP) einrichten

Für Android 17 empfehlen wir dringend Option 2, sie ist jedoch nicht erforderlich. In den folgenden beiden Abschnitten werden die einzelnen Optionen erläutert.

Option 1: Vorhandenes WLAN verwenden, das Sie für CTS-V eingerichtet haben

Für Option 1 ist ein Android-DUT innerhalb der WLAN-Abdeckung erforderlich. Wenn sich das DUT in einer abgeschirmten Box befindet und keine Verbindung zum WLAN herstellen kann, nehmen Sie es aus der Box heraus.

Option 2: Programmierbaren AP einrichten

So richten Sie einen programmierbaren AP für die WLAN-Verbindungstests ein:

  1. Kaufen Sie den Banana Pi R3 AP und richten Sie ihn ein. Informationen zum Kauf und zur Einrichtung des Banana Pi R3 AP finden Sie unter Banana Pi BPI-R3 AP einrichten.

  2. Optional: Wenn Sie keine Abschirmbox haben, empfehlen wir die JTP-SR101. Kaufen Sie diese Box mit den folgenden Informationen:

    Dong Guan Zheng Sheng Electronics Technology Co., LTD

    Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, China

    Kontakt: Forest Pan

    E-Mail: forest.pan@jtpmak.cn

    Telefon (China): +86 18676993556

  3. Verbinden Sie das DUT und den AP mit dem Host und legen Sie sie in eine HF-Abschirmbox. Das Prüfgerät und der AP sollten mindestens 10 cm voneinander entfernt sein. Abbildung 2 zeigt diese Konfiguration:

    DUT und AP in der abgeschirmten Box

    Abbildung 2: DUT und AP in der Abschirmbox.

  4. Prüfen Sie mit SSH, ob der AP vom Host aus erreichbar ist.

Tests zur Genauigkeit der Entfernungsmessung einrichten

So richten Sie Tests zur Reichweiten-Genauigkeit ein:

  1. Stellen Sie zwei passende Android-Testgeräte im Abstand von 1 Meter auf gleicher Höhe auf. Die Geräte müssen sich in Sichtlinie befinden und die Rückseite der Geräte muss zueinander zeigen. Abbildung 3 zeigt diese Ausrichtung:

    Ausrichtung des Geräts

    Abbildung 3: Geräteausrichtung.

  2. Verbinden Sie beide Geräte über USB-Kabel mit dem Computer.

Standardtests mit zwei Geräten einrichten

Für die Standardkonfiguration mit zwei Geräten:

  1. Stellen Sie zwei passende Android-DUTs etwa 20 cm voneinander entfernt auf.

  2. Sehr empfehlenswert: Legen Sie beide Geräte in eine Abschirmbox. Die Abschirmbox verbessert die Teststabilität und erleichtert die Fehlersuche bei Testfehlern.

  3. Für Telekommunikationstests muss jedes zu prüfende Gerät eine SIM-Karte und ein Mobilfunksignal haben. Wenn sich die zu testenden Geräte in einem abgeschirmten Gehäuse befinden, muss das Mobilfunksignal in das Gehäuse eingekoppelt werden. Andernfalls müssen Sie die Geräte aus der Abschirmbox entfernen.

  4. Optional: OTA-Sniffer für WLAN-Debugging einrichten

CDM-Tests einrichten

Der Testlauf test_permissions_sync verhält sich je nach Build-Typ der Geräte, auf denen der Test ausgeführt wird, unterschiedlich. Es ist wichtig, dass sowohl debugfähige (userdebug oder eng) als auch nicht debugfähige (user) Builds von OEMs getestet werden und die Tests für beide bestehen.

Befreiung

Die CDD-Klausel für die Implementierung der Berechtigungssynchronisierungs-API erfordert nur, dass Daten über einen sicheren Kanal zwischen Geräten übertragen werden können. Da die Implementierung des sicheren Kanals keine Anforderung für die CDD-Konformität ist, kann dieser Test bei nicht debugfähigen (Nutzer-)Builds übersprungen werden. Dies ist jedoch nur möglich, wenn Sie die Funktion zur Synchronisierung von CDM-Berechtigungen nicht unterstützen möchten.

Die Tests müssen bei debugfähigen Builds ausnahmslos bestanden werden.

Voraussetzungen für Tests mit nicht debugfähigen Builds

Wenn Sie nicht ausgenommen sind, prüfen Sie, ob Sie die folgenden Voraussetzungen erfüllen.

Der sichere Channel verwendet AVF (AttestationVerificationFramework), um die Vertrauenswürdigkeit der Hardware zu überprüfen. Die von beiden Parteien generierten Atteste enthalten mehrere Informationen über sie, um zu bestätigen, dass in ihrem System keine unbefugten Änderungen vorgenommen wurden. Im Rahmen der AVF-Überprüfung werden die folgenden Status geprüft:

  • Das Gerät hat Zugriff auf das Internet.

  • Das Gerät verwendet Verified Boot und der Build ist mit einem Release-Schlüssel (nicht mit einem Entwicklerschlüssel) signiert.

  • Der Bootloader des Geräts ist gesperrt. Weitere Informationen finden Sie unter Bootloader sperren.

  • Die Patch-Ebenen für Betriebssystem, Schlüssel-Boot und Schlüsselanbieter sind nicht älter als 12 Monate. Verwenden Sie keinen Build, der älter als ein Jahr ist.

  • Die Geräteattestierung wird durch eines der vom Anbieter genehmigten Stammzertifikate unterstützt. Geben Sie Ihre vertrauenswürdigen Root-Zertifikate im vendor_required_attestation_certificates.xml-Ressourcen-Overlay an.

Hostseitige Tests ausführen

Für einige Tests auf mehreren Geräten, z. B. NFC-Tests, ist eine zusätzliche Einrichtung erforderlich. Bei Tests, für die eine zusätzliche Einrichtung erforderlich ist, wird jeder Test separat ausgeführt. Tests, für die keine zusätzliche Einrichtung erforderlich ist, können Sie in einer Gruppe ausführen.

  1. Starten Sie auf Ihrer Test-Workstation die cts-v-host-Konsole aus dem Verzeichnis, in dem das CTS-V-ZIP-Paket entpackt wurde:

    ./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed

  2. Klicken Sie in der CTS-V-App auf dem DUT auf Host-side Tests (Hostseitige Tests). Abbildung 4 zeigt die Host-seitigen Tests in der CTS-V-App:

    Hostseitige Tests in der CTS-V-App

    Abbildung 4: Hostseitige Tests in der CTS-V-App.

    Eine Liste der hostseitigen Multidevice-Testmodule wird angezeigt.

  3. Verwenden Sie in der CTS-V-Hostkonsole den folgenden Befehl, um Tests für mehrere Geräte auszuführen, bei denen eine Standardkonfiguration mit zwei Geräten verwendet wird:

    run cts-v-host-multidevice-default

    Die Ergebnisse werden unter jedem Testmodul in der CTS-V-App auf dem DUT angezeigt. Grün markierte Tests wurden bestanden, rot markierte Tests sind fehlgeschlagen.

    Abbildung 5 zeigt Beispielergebnisse für die CtsCompanionDeviceManager-Tests:

    Hostseitige Multidevice-Testergebnisse in der CTS-V-App

    Abbildung 5: Hostseitige Ergebnisse von Tests auf mehreren Geräten in der CTS-V-App.

  4. Führen Sie in der CTS-V-Hostkonsole die interaktiven Tests mit dem folgenden Befehl aus:

    run cts-v-host-interactive

    Die Ergebnisse werden unter jedem Testmodul in der CTS-V-App auf dem DUT angezeigt. Grün markierte Tests wurden bestanden, rot markierte Tests sind fehlgeschlagen.

  5. Führen Sie jeden Test, für den eine zusätzliche Einrichtung erforderlich war, separat mit dem folgenden Befehl aus:

    run cts-v-host -m test_module_name

    Verwenden Sie beispielsweise diesen Befehl, um die NFC-Tests auszuführen:

    run cts-v-host -m CtsNfcHceMultiDeviceTestCases

    Die Ergebnisse werden unter jedem Testmodul in der CTS-V-App auf dem DUT angezeigt. Grün markierte Tests wurden bestanden, rot markierte Tests sind fehlgeschlagen.

Tests für die WLAN-AP-Verbindung ausführen

Sie können die Tests für die WLAN-AP-Verbindung auf zwei Arten ausführen:

  • Option 1: Verwenden Sie ein vorhandenes WLAN, das Sie für CTS-V eingerichtet haben.
  • Option 2: Programmierbaren AP einrichten

Option 1: Vorhandenes WLAN verwenden, das Sie für CTS-V eingerichtet haben

So führen Sie die Tests für die WLAN-AP-Verbindung in einem vorhandenen WLAN aus:

  1. Bearbeiten Sie die Testumgebungskonfigurationsdatei (WifiConnectionTestbed.yaml). Diese Datei befindet sich in dem Verzeichnis, in dem CTS‑Verifier entpackt wurde. Beispiel:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Ändern Sie den Wert der Felder wifi_ssid und wifi_password in die SSID und das Passwort des WLANs. Das folgende Beispiel zeigt, wo sich diese Einstellungen befinden:

    TestBeds:
-   Name: WifiConnectionTestbed
Controllers:
  AndroidDevice: '*'
TestParams:
  use_programmable_ap: False
  wifi_ssid: WIFI-SSID
  wifi_password: WIFI-PASSWORD

  3. Führen Sie in der CTS-V-Hostkonsole den folgenden Befehl aus:

    run cts-v-host -m CtsWifiConnectionTests

Option 2: Mit einem programmierbaren AP ausführen

So führen Sie die Tests für die WLAN-AP-Verbindung auf einem programmierbaren AP aus:

  1. Bearbeiten Sie die Testumgebungskonfigurationsdatei (WifiConnectionTestbed.yaml). Diese Datei befindet sich in dem Verzeichnis, in dem CTS‑Verifier entpackt wurde. Beispiel:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Ändern Sie den Wert von hostname in die IP-Adresse des AP, basierend auf Ihren lokalen SSH-Einstellungen. Informationen zum Ermitteln der IP-Adresse finden Sie unter IP-Adresse des Access Points ermitteln. Das folgende Beispiel zeigt, wo sich die Einstellung hostname befindet:

    TestBeds:
-   Name: WifiConnectionTestbed
  Controllers:
    AndroidDevice: '*'
    # Specify settings for the AP.
    OpenWrtDevice:
    -   hostname: AP-IP
      skip_init_reboot: True
  TestParams:
    use_programmable_ap: True

  3. Führen Sie in der CTS-V-Hostkonsole den folgenden Befehl aus:

    run cts-v-host -m CtsWifiConnectionTests

USB-hostseitige Tests ausführen

Android 17 umfasst USB-CTS-V-Hostseitentests, für die adb über WLAN erforderlich ist.

Für einige USB-Tests ist der Zugriff auf SystemAPIs über den CTS-V-Host erforderlich, da die Berechtigungen der normalen CTS-V-App nicht ausreichen. Diese Tests sind nicht an ein Kabel gebunden und erfordern die Verwendung von adb über WLAN.

Die folgenden Typ‑C-Zubehörteile sind erforderlich, wenn das zu prüfende Gerät das Melden des BC 1.2-Typs des Portpartners oder von USB-Stromprofilen in UsbPort.java unterstützt:

  • Ein USB Typ‑C-Ladegerät mit Power Delivery (PD)
  • Ein Downstream-Port (SDP) gemäß dem Standard „USB Battery Charging 1.2“ (BC 1.2). Diese Ports sind auf 500 mA oder 900 mA für das Prüfling begrenzt und befinden sich in der Regel an den USB-Ports externer Hubs.
  • Ein USB BC 1.2-Ladeanschluss (Charging Downstream Port, CDP). Über diese Ports können dem Prüfling 1,5 A Strom und Daten bereitgestellt werden. Ein Typ‑C-Anschluss an einem Laptop oder Computer ist wahrscheinlich ein CDP.
  • Ein USB BC 1.2-Ladeanschluss (Dedicated Charging Port, DCP). Über diese Ports können 1,5 A Strom an das Prüfling geliefert werden, ohne dass Daten übertragen werden. Das USB‑Typ‑C-PD-Ladegerät in dieser Liste ist wahrscheinlich ein DCP.

  1. Verbinden Sie das zu testende Gerät über WLAN mit adb. Weitere Informationen zur Einrichtung finden Sie unter Über WLAN eine Verbindung zu einem Gerät herstellen.

  2. Trennen Sie das Gerät von allen USB-Verbindungen. Der Test schlägt fehl, wenn das Gerät an einen USB-Host oder ein Zubehör angeschlossen ist, wenn der Testbefehl ausgeführt wird.

  3. Führen Sie den folgenden Testbefehl aus:

    run cts-v-host -m CtsUsbTypecTestCases

Nach den Tests werden die Ergebnisse in der CTS-V-App unter Host-seitige Tests angezeigt, wie in den folgenden Abbildungen dargestellt:

Hostseitige USB-Tests in der CTS-V-App

Abbildung 6. Hostseitige USB-Tests in der CTS-V-App.

CtsUsbTypecTestCases-Suite in der hostseitigen USB CTS-V-App

Abbildung 7. CtsUsbTypecTestCases-Suite in der hostseitigen USB CTS-V-App.

Fehlerbehebung bei Tests auf mehreren Geräten

In diesem Abschnitt finden Sie Informationen zur Fehlerbehebung bei häufigen Problemen.

Fehler beim Abrufen der Telefonnummer während des CtsTelecomTest

Wenn Sie die Fehlermeldung Failed to get phone number for <serial> erhalten, gehen Sie so vor:

  1. Prüfe, ob in jedem DUT eine SIM-Karte eingelegt ist.

  2. Wenn der Fehler weiterhin auftritt, unterstützen die SIM-Karten möglicherweise nicht das automatische Abrufen von Nummern. In diesem Fall müssen Sie die Telefonnummern explizit im Befehl angeben.

    Für DUT 1 (Seriennummer 17011FDEE0002N, Telefonnummer 555-0000) und DUT 2 (Seriennummer R3CN90YNAR, Telefonnummer 555-1111) hängen Sie die folgenden Argumente an den run cts-v-host-Befehl an:

    --module-arg CtsTelecomTest:dut_serial:17011FDEE0002N \
--module-arg CtsTelecomTest:dut_phone_number:555-0000 \
--module-arg CtsTelecomTest:ref_phone_number:555-1111

Keine Antwort vom Server während CtsMultiDeviceGenericRangingAccuracyTests

Wenn Sie die folgende Fehlermeldung erhalten, kann die Test-App auf bestimmten Geräten durch die OEM-spezifische Verwaltung von Hintergrundprozessen eingefroren oder beendet werden:

mobly.snippet.errors.ProtocolError: <AndroidDevice|Initiator> No response from server. Check the device logcat for crashes.

So beheben Sie das Problem: Deaktivieren Sie die Hintergrundbeschränkungen oder fügen Sie die folgenden Pakete auf die Zulassungsliste:

Paket Anzeigename
com.google.snippet.uwb CtsUwbSnippetApp
com.google.snippet.ranging CtsRangingSnippetApp
com.google.snippet.bluetooth CtsBluetoothMultiDeviceSnippetApp
com.google.android.mobly.snippet.bundled androidx.multidex.MultDexApplication

Problem behoben: Keine Antwort für „GetFirmwareVersion“ bei NFC-Tests

Wenn Sie beim Ausführen der Tests für mehrere Geräte die Meldung verify_firmware_version RuntimeError: No response for GetFirmwareVersion erhalten, können die Tests nicht auf das PN532-NFC-Board zugreifen.

Um dieses Problem zu beheben, müssen Sie den seriellen Pfad des PN532-NFC-Boards auf Ihrem Host ermitteln, z. B. dev/ttyUSB1, und ihn dann manuell mit dem Argument --module-arg in der Konsole angeben:

run cts-v-host -m CtsNfcHceMultiDeviceTestCases --module-arg CtsNfcHceMultiDeviceTestCases:pn532_serial_path:/dev/ttyUSB1

Fehlermeldung „Transaktion fehlgeschlagen“ bei NFC-Tests beheben

Wenn Sie für alle NFC-Testläufe die Meldung Transaction failed, check device logs for more information. erhalten, liegt das wahrscheinlich daran, dass der NFC-Chip des zu testenden Geräts den PN532 nicht erkennen kann.

Wenn mehrere Geräte mit dem Host verbunden sind und einige davon keinen PN532 obenauf haben, wurde möglicherweise das falsche DUT ausgewählt. Weitere Informationen finden Sie unter NFC-Tests einrichten.

Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:

  • Legen Sie die Seriennummer des richtigen DUT im hostseitigen Testbefehl mit dem Flag -s fest.

  • Trennen Sie alle Geräte, die nicht zum Prüfling gehören, vom Host.

CDM-Testlauf test_permissions_sync wird ignoriert

Wenn der Test auf Geräten ausgeführt wird, die nicht debugfähig sind, prüfen Sie, ob Sie ausgenommen sind. Prüfen Sie andernfalls, ob beide Geräte die Voraussetzungen erfüllen.