CTS einrichten

Bereiten Sie zur Ausführung von CTS zuerst Ihre physische Umgebung, Ihren Desktop-Computer und das Sie zum Testen verwenden.

Physische Umgebung

Bluetooth LE-Beacons

Wenn das zu testende Gerät Bluetooth LE unterstützt, platzieren Sie mindestens drei Bluetooth LE-Beacons im Umkreis von 5 m um die DUT für den Bluetooth LE-Scantest. Diese Beacons müssen nicht konfiguriert werden und geben keine spezifischen Daten aus. einschließlich iBeacon, Eddystone und sogar Geräte, die BLE-Beacons simulieren,

Ultrabreitband

Wenn der DUT Ultrabreitband (UWB) unterstützt, wird ein anderes Gerät UWB muss nah genug positioniert und ausgerichtet sein, damit an eine Antenne und an eine Funkzone. Für die Tests zur Entfernungsgenauigkeit Positionierung und Ausrichtung. Details zur Einrichtung findest du unter UWB-Anforderungen Der UWB-Test muss manuell ausgeführt werden. Geben Sie dabei in der Befehlszeile an, welche beiden einen Meter voneinander entfernt. Weitere Informationen zur für diesen Test erforderlichen Fragmentierung finden Sie unter Lokale Fragmentierung:

Kameras

Verwenden Sie beim Ausführen des CTS der Kamera normale Lichtverhältnisse mit einem Testmuster. Diagramm (z. B. ein Schachbrettmuster). Platzieren Sie das Testmusterdiagramm gemäß auf die minimale Brennweite des DUTs an, um sicherzustellen, dass sie sich nicht zu nahe am verwenden.

Richten Sie die Kamerasensoren auf eine ausreichende Beleuchtung. Sensoren, die getestet werden, um die maximal konfigurierte Zielframes zu erreichen und auf dieser beizubehalten pro Sekunde (fps) gemäß CONTROL_AE_TARGET_FPS_RANGE Dies gilt für alle Kamerasensoren, die von getCameraIdList Der Test wird für die aufgeführten Geräte durchgeführt und die Leistung wird gemessen individuell anpassen.

Wenn der DUT externe Kameras unterstützt, z. B. USB-Webcams, schließen Sie ein externes wenn Sie CTS ausführen. Andernfalls schlagen die CTS-Tests fehl.

GPS/GNSS

Wenn das DUT das globale Positionierungssystem bzw. den globalen Navigationssatelliten unterstützt (GPS/GNSS-System), ein GPS-/GNSS-Signal an die DUT an einem für den Empfang und die Berechnung des GPS-Standorts. Der GPS-Teil muss kompatibel mit ICD-GPS-200C. Andernfalls kann das GPS/GNSS-Signal beliebig sein, einschließlich eines Satellitensimulators oder eines GPS/GNSS-Repeaters für Außensignale können Sie den DUT nah genug an einem Fenster platzieren, GPS-/GNSS-Signal ist ausreichend.

WLAN und IPv6

Für CTS-Tests ist ein WLAN erforderlich, das IPv4 und IPv6 unterstützt, über eine Internetverbindung verfügt. mit funktionierendem DNS für IPv4 und IPv6, unterstützt IP-Multicast und kann die DUT wie einen isolierten Client behandeln. Ein isolierter Client ist eine Konfiguration, bei der der DUT keine Sichtbarkeit der Broadcast-/Multinetwork-Nachrichten in diesem Subnetzwerk. Dieses erfolgt bei der Konfiguration eines Wi-Fi-Zugangspunkts oder durch Ausführen des DUT auf einem Subnetzwerk isoliert, ohne dass andere Geräte verbunden sind.

Wenn Sie keinen Zugriff auf ein natives IPv6-Netzwerk, ein IPv6-Mobilfunknetz oder ein VPN, um einige IPv6-Tests zu bestehen, können Sie einen WLAN-Zugangspunkt und einen IPv6-Tunnel.

Zum Übergeben von CTS müssen für den DUT die Flags UP, BROADCAST und MULTICAST festgelegt sein über die WLAN-Benutzeroberfläche. Der WLAN-Schnittstelle müssen IPv4- und IPv6-Adressen zugewiesen werden. Prüfe mit adb shell ifconfig die Eigenschaften der WLAN-Schnittstelle.

Für Geräte, die den Parallele WLAN-Unterstützung für STA/STA Es sind mehrere WLANs (mindestens 2) erforderlich. Um CTS zu übergeben, muss das WLAN Netzwerke auf verschiedenen Bändern mit unterschiedlichen SSIDs oder auf dem dieselbe SSID mit unterschiedlichen BSSIDs.

WLAN-RTT

Android umfasst die Wi-Fi RTT API für eine Wi-Fi Round Trip Time (RTT) (WLAN-Umlaufzeit) So können Geräte die Entfernung zu Zugangspunkten mit eine Genauigkeit von 1 bis 2 Metern, was die Standortgenauigkeit in Innenräumen deutlich erhöht. Zwei empfohlene Geräte, die WLAN-RTT unterstützen, sind: Google Wifi und Fitlet2-Zugangspunkt von Compulab (Bandbreite von 40 MHz bei 5 GHz festgelegt)

Die Zugangspunkte sollten eingeschaltet sein, benötigen aber keine Netzwerkverbindung. Zugangspunkte müssen sich nicht neben dem Testgerät befinden, werden aber empfohlen, nicht mehr als 16 m von der DUT entfernt sein. In der Regel ist ein Zugangspunkt ausreichend.

Einrichtung von Desktopcomputern

Achtung: CTS unterstützt 64-Bit-Linux-Maschinen. CTS wird unter Windows nicht unterstützt. oder macOS.

FFMPEG

Installieren Sie das ffmpeg-Paket ab Version 5.1.3 auf dem Hostcomputer.

Upgrade der Hostmaschine

Es wird dringend empfohlen, den RAM des CTS-Hostcomputers auf 128 GB und die HDD-Version auf 256 GB zu aktualisieren. Sie ist erforderlich, um der gestiegenen Anzahl von CTS-Testfällen und einer erhöhten Reservierung von Java-Heap-Speicherplatz im Tradefed gerecht zu werden.

ADB und AAPT2

Stellen Sie vor dem Ausführen der CTS sicher, dass Sie die aktuellen Versionen der beides Android Debug Bridge (ADB) und Android Asset Packaging Tool (AAPT2) und den Speicherort dieser Tools zum Systempfad Ihres Computers hinzugefügt.

Um ADB und AAPT2 zu installieren, laden Sie die neueste Android SDK-Plattformtools und Android SDK-Build-Tools aus dem SDK-Manager oder aus der sdkManager Befehlszeilentool.

Achten Sie darauf, dass sich adb und aapt2 in Ihrem Systempfad befinden. Mit dem folgenden Befehl dass Sie die Paketarchive in ein Unterverzeichnis android-sdk in Ihrem Basisverzeichnis:

export PATH=$PATH:$HOME/android-sdk/platform-tools:$HOME/android-sdk/build-tools/<tools version number>

Java Development Kit für Ubuntu

Installieren Sie die richtige Version von Java Development Kit (JDK)

• Installieren Sie für Android 11 OpenJDK11.
• Für Android 9 und Android 10 installieren Sie OpenJDK9.
• Installieren Sie für Android 7.0, 7.1, 8.0 und 8.1 OpenJDK8.

Weitere Informationen finden Sie in den JDK-Anforderungen.

Einrichtung für den Python-Support

Installieren Sie virtualenv für Ihre Plattform, indem Sie der Installation Anleitung.

Durch Aufrufen von virtualenv -h können Sie prüfen, ob die Installation erfolgreich war.

CTS-Dateien

Laden Sie die CTS-Pakete von Kompatibilitätstest-Suite-Downloads deinen Geräten entsprechen Android-Version und alle binären Schnittstellen der Anwendungen die von Ihren Geräten unterstützt werden.

Laden Sie die aktuelle Version der CTS-Mediendateien

Mainline-bezogene CTS-Dateien herunterladen (optional)

Wenn Sie eine CTS-Version zum ersten Mal ausführen, lädt CTS dynamisch einige Mainline-bezogene CTS-Dateien, durch die die Laufzeit um mindestens 10 Minuten verlängert wird, je nach Netzwerkgeschwindigkeit.

Wenn Sie diese zusätzliche CTS-Laufzeit vermeiden möchten, können Sie die Mainline-bezogene CTS-Laufzeit herunterladen bevor Sie die CTS-Version ausführen. Gehen Sie dazu folgendermaßen vor:

1. Rufen Sie das Android-API-Level auf dem Gerät ab, indem Sie folgenden Befehl ausführen:

   adb shell getprop ro.build.version.sdk
   

2. Folgen Sie der Anleitung im Skript download_mcts.sh. um die Mainline-CTS-Dateien herunterzuladen.

   Der Download dauert je nach Netzwerkgeschwindigkeit mindestens 10 Minuten.

Geräteerkennung

Folgen Sie dem Schritt, um Richten Sie Ihr System so ein, dass es Ihr Gerät erkennt.

Arbeitsspeicherlimit

Sie können den maximalen Arbeitsspeicher erhöhen, der während des Testlaufs im cts-tradefed . Siehe Beispiel-CL .

Einrichtung von Android-Geräten

Nutzer-Builds

Ein kompatibles Gerät ist ein Gerät mit einem vom Nutzer oder Releaseschlüssel signierten Build. Auf deinem Gerät sollte ein System-Image ausgeführt werden, das auf dem als kompatiblen bekannten System basiert. Nutzer-Build (Android 4.0 oder höher) aus Codenamen, Tags und Build-Nummern

Build-Attribut der ersten API-Ebene

Bestimmte CTS-Anforderungen hängen vom Build des Geräts ab Versand mit. z. B. Geräte, die ursprünglich mit älteren Versionen ausgeliefert wurden ist möglicherweise von den Systemanforderungen ausgeschlossen, die für Geräte gelten, die mit späteren Builds.

Um diese Informationen für CTS verfügbar zu machen, das Build-Zeit-Attribut ro.product.first_api_level definiert. Der Wert dieser Funktion ist die erste API-Ebene, mit der das Gerät kommerziell gestartet wurde.

Die Gerätehersteller können die gemeinsame zugrunde liegende Implementierung wiederverwenden, Ein neues Produkt als Upgrade eines vorhandenen Produkts auf demselben Gerät einzuführen Gruppe. Die Gerätehersteller können optional die API-Ebene der vorhandenen Produkt auf ro.product.first_api_level umstellen, sodass die Upgradeanforderungen für CTS und Höhen/VTS beantragt.

Die Gerätehersteller können PRODUCT_SHIPPING_API_LEVEL in ihren device.mk, um diese Eigenschaft festzulegen, wie im folgenden Beispiel gezeigt:

# PRODUCT_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
PRODUCT_SHIPPING_API_LEVEL := 21

Erstes API-Level für Android 9 oder höher

Bei Geräten mit Android 9 oder höher: ro.product.first_api_level-Property in einen gültigen Wert aus Codenamen, Tags und Build-Nummern.

Erstes API-Level für Android 8.x oder niedriger

Für Geräte, die mit Android 8.x oder niedriger auf den Markt gebracht wurden, deaktivieren (entfernen) Sie die Einstellung ro.product.first_api_level für den ersten Build des Produkts. Für Für alle nachfolgenden Builds musst du für ro.product.first_api_level das richtige API-Level festlegen Wert. So kann die Property ein neues Produkt korrekt identifizieren und enthält Informationen zur ersten API-Ebene des Produkts. Wenn die Kennzeichnung nicht festgelegt ist, weist Android „ro.product.first_api_level“ Build.VERSION.SDK_INT zu.

CTS-Shim-Pakete

Android 10 oder höher enthält ein Paketformat namens APEX: CTS-Tests für die APEX-Verwaltung ausführen APIs (wie das Aktualisieren auf eine neue Version oder das Melden aktiver APEXes) müssen Sie ein CtsShimApex-Paket auf einer Partition /system vorinstallieren.

Mit dem APEX-Shim-Validierungstest wird die Implementierung von CtsShimApex überprüft.

Anforderungen für ro.apex.updatable

• Wenn das Attribut ro.apex.updatable auf true gesetzt ist, gilt für CtsShimApex für alle Geräte erforderlich, die die APEX-Paketverwaltung unterstützen.

• Wenn das Attribut ro.apex.updatable fehlt oder nicht festgelegt wurde: CtsShimApex muss nicht auf einem Gerät vorinstalliert sein.

Mit dem APEX-Shim-Validierungstest wird die Implementierung von CtsShimApex überprüft.

CtsShim-Vorinstallationen und -Vorabladevorgänge

Ab Android 11 enthält CtsShimApex zwei vordefinierte Apps (basierend auf Build-Quelle) die keinen Code außer dem Manifest enthalten. CTS nutzt diese Apps, um Berechtigungen und Berechtigungen zu testen.

Wenn das Gerät die APEX-Paketverwaltung nicht unterstützt (d. h. Property „ro.apex.updatable“ fehlt oder nicht festgelegt ist) oder wenn das Gerät Version 10 oder niedriger ausgeführt wird, müssen die beiden separat im System vorinstalliert werden.

Wenn APEX unterstützt wird, müssen die Vorinstallationen für den entsprechenden Release als /system/apex/com.android.apex.cts.shim.apex platziert werden.

Wenn normale vordefinierte Apps verwendet werden, CtsShim und CtsShimPriv für die muss der entsprechende Release als /system/app/CtsShimPrebuilt.apk und /system/priv-app/CtsShimPrivPrebuilt.apk.

In der folgenden Tabelle sind die für jedes Gerät verfügbaren Vorinstallationen und Vorabladevorgänge aufgeführt. Geräteversion und Architektur.

Geräteversion	vorinstallieren (falls APEX unterstützt wird)		Vorab laden
	SCHARF SCHALTEN	x86	SCHARF SCHALTEN	x86
Android 14	<ph type="x-smartling-placeholder"></ph> Android14-Arm-Release	<ph type="x-smartling-placeholder"></ph> Android 14-x86-Release	<ph type="x-smartling-placeholder"></ph> android14-arm-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android14-arm-CtsShimPriv.apk	<ph type="x-smartling-placeholder"></ph> android14-x86-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android14-x86-CtsShimPriv.apk
Android 13	<ph type="x-smartling-placeholder"></ph> Android13-Arm-Release	<ph type="x-smartling-placeholder"></ph> Android 13-x86-Release	<ph type="x-smartling-placeholder"></ph> android13-arm-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android13-arm-CtsShimPriv.apk	<ph type="x-smartling-placeholder"></ph> android13-x86-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android13-x86-CtsShimPriv.apk
Android 12	<ph type="x-smartling-placeholder"></ph> Android12-Arm-Release	<ph type="x-smartling-placeholder"></ph> Android 12-x86-Release	<ph type="x-smartling-placeholder"></ph> android12-arm-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android12-arm-CtsShimPriv.apk	<ph type="x-smartling-placeholder"></ph> android12-x86-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android12-x86-CtsShimPriv.apk
Android 11	<ph type="x-smartling-placeholder"></ph> Android11-Arm-Release	<ph type="x-smartling-placeholder"></ph> Android11-x86-Release	<ph type="x-smartling-placeholder"></ph> android11-arm-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android11-arm-CtsShimPriv.apk	<ph type="x-smartling-placeholder"></ph> android11-x86-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android11-x86-CtsShimPriv.apk
Android 10	<ph type="x-smartling-placeholder"></ph> Android 10-Release		<ph type="x-smartling-placeholder"></ph> android10-arm-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android10-arm-CtsShimPriv.apk	<ph type="x-smartling-placeholder"></ph> android10-x86-CtsShim.apk <ph type="x-smartling-placeholder"></ph> android10-x86-CtsShimPriv.apk
Android 9, O und O-MR1	–	–	<ph type="x-smartling-placeholder"></ph> arm-CtsShim.apk <ph type="x-smartling-placeholder"></ph> arm-CtsShimPriv.apk	<ph type="x-smartling-placeholder"></ph> x86-CtsShim.apk <ph type="x-smartling-placeholder"></ph> x86-CtsShimPriv.apk

Um die Tests zu bestehen, laden Sie die Apps vorab in die entsprechenden Verzeichnisse auf dem ohne die Apps neu zu signieren.

Beispiel-Applet

Mit Android 9 wurden Open Mobile APIs eingeführt. Für Geräte, die mehrere Berichte Secure Element hinzufügen, fügt CTS Testfälle hinzu, um das Verhalten der APIs Diese Testläufe erfordern die einmalige Installation eines Beispiel-Applets in das eingebettete Secure Element (eSE) des DUT oder in die vom DUT. Die eSE-Beispiel-Applet und die SIM-Beispiel-Applet finden Sie in AOSP.

Siehe CTS-Test für Secure Element für Ausführlichere Informationen zu Open Mobile API-Testfällen und Zugriffssteuerungstest Cases.

Speicheranforderungen

Für CTS-Medien-Stresstests müssen sich Videoclips auf einem externen Speicher befinden (/sdcard) Die meisten Clips stammen Big Buck Bunny, das dem Urheberrecht unterliegt von der Blender Foundation Creative-Commons-Lizenz „Namensnennung 3.0“.

Der erforderliche Speicherplatz hängt von der maximalen Auflösung ab, die bei der Videowiedergabe unterstützt wird auf dem Gerät. Siehe Abschnitt 5 im Dokument zur Definition der Android-Kompatibilität für das Plattformversion der erforderlichen Lösungen.

Dies sind die Speicheranforderungen je nach maximaler Auflösung für die Videowiedergabe:

• 480 x 360: 98 MB
• 720 x 480: 193 MB
• 1280 x 720: 606 MB
• 1.920 x 1.080: 1.863 MB

Display und Speicher

• Geräte ohne eingebetteten Bildschirm müssen mit einem Bildschirm.

• Wenn das Gerät über einen Steckplatz für Speicherkarten verfügt, stecken Sie eine leere SD-Karte ein. SD-Karte verwenden die einen UHS-Bus (Ultra High Speed) mit SDHC- oder SDXC-Kapazität unterstützt, oder mit einer Geschwindigkeitsklasse von 10 oder höher, CTS.

• Wenn das Gerät über SIM-Kartensteckplätze verfügt, stecken Sie eine aktivierte SIM-Karte in jeden dieser Steckplätze. Wenn das Gerät SMS unterstützt, muss jede SIM-Karte ein eigenes Nummernfeld haben ausgefüllt. Für Geräte mit Android 12 oder höher ist, müssen alle SIM-Karten die Speicherung von abgekürzten Nummern unterstützen. (ADN) verwendet. GSM- und USIM-Karten mit der speziellen Telekommunikationsdatei (DF_{Telekommunikation}) erfüllen diese Anforderung.

Entwickler-UICC

Um CTS-API-Tests für den Mobilfunkanbieter auszuführen, muss das Gerät eine SIM-Karte mit einem CTS-Mobilfunkanbieter verwenden Berechtigungen, die den in den UICC vorbereiten

Android-Gerätekonfiguration

1. Gerät auf die Werkseinstellungen zurücksetzen: Einstellungen > Sicherung und Zurücksetzen > Werkszustand Zurücksetzen.

2. Stellen Sie die Sprache Ihres Geräts auf Englisch (USA) ein: Einstellungen > Sprache und Eingabe > Sprache:

3. Wenn das Gerät die Anpassung von Standardschriftarten unterstützt, legen Sie die Standardschriftart fest. Schriftfamilie sans-serif zu Roboto (Standardschriftfamilie sans-serif) verwendet in AOSP-Builds).

4. Standorteinstellung aktivieren, wenn eine GPS- oder WLAN-Verbindung bzw. ein Mobilfunknetz vorhanden ist auf dem Gerät: Einstellungen > Standort > An:

5. Stellen Sie eine Verbindung zu einem WLAN her, das IPv6 unterstützt. DUT kann wie ein isolierter Client (siehe Physische Umgebung oben) und verfügt über eine Internetverbindung: Einstellungen > WLAN

6. Vergewissern Sie sich, dass auf dem Gerät weder ein Sperrmuster noch ein Passwort festgelegt ist: Einstellungen > Sicherheit > Displaysperre > Keine:

7. Aktivieren Sie USB-Debugging auf Ihrem Gerät: Einstellungen > Entwickleroptionen > USB-Debugging

8. Stelle die Uhrzeit auf das 12-Stunden-Format ein: Einstellungen > Datum & Zeit > 24 Stunden nutzen Format > Aus.

9. Legen Sie fest, dass das Gerät aktiv bleibt: Einstellungen > Entwickleroptionen > Wach lassen > An:

10. Nur in Android 5.x und 4.4.x: Legen Sie fest, dass simulierte Standorte zugelassen werden: Einstellungen > Entwickleroptionen > Falsche Standorte zulassen > An:

11. Deaktivieren Sie in Android 4.2 oder höher die USB-App-Bestätigung: Einstellungen > Entwickleroptionen > Apps über USB bestätigen > Aus.

12. Richten Sie das Gerät unter Android 13 oder höher so ein, dass simulierte Modems zugelassen werden: Einstellungen > Entwickleroptionen > Mock Modem zulassen > An:

13. Starten Sie den Browser und schließen Sie alle Start-/Einrichtungsbildschirme.

14. Den Desktopcomputer, der zum Testen des Geräts verwendet werden soll, mit einem USB-Kabel verbinden Kabel.

15. Bevor Sie CTS ausführen, legen Sie Roboto2 mithilfe eines Einstellung für barrierefreie Angebote (nicht versteckt) sein.

Dateiinstallation

Installieren und konfigurieren Sie Hilfs-Apps auf dem Gerät.

1. Richten Sie Ihr Gerät gemäß Ihrer CTS-Version ein:

   • CTS-Versionen 2.1 R2 bis 4.2 R4:Gerät (oder Emulator) einrichten wie Sie die Tests zur Barrierefreiheit durchführen: adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

     Aktivieren Sie auf dem Gerät die Delegierung: Einstellungen > Bedienungshilfen > Bedienungshilfen > Bedienungshilfen delegieren

   • CTS-Version 6.x oder niedriger: Auf Geräten mit android.software.device_admin, richte dein Gerät so ein, dass es ausgeführt wird Administrationstest mithilfe von: adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk`

     Unter Einstellungen > Sicherheit > Geräteadministratoren auswählen, aktivieren Sie die zwei android.deviceadmin.cts.CtsDeviceAdminReceiver*-Geräte Administratoren. Stellen Sie sicher, dass android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver und beliebige andere vorinstallierte Geräteadministratoren bleiben deaktiviert.

2. Kopieren Sie die CTS-Mediendateien wie folgt auf das Gerät:

   1. Navigieren Sie (cd) zu dem Pfad, in dem die Mediendateien heruntergeladen werden, und entpackt.

   2. Ändern Sie die Dateiberechtigungen: chmod u+x copy_media.sh

   3. Kopieren Sie die erforderlichen Dateien:

      • Führen Sie folgenden Befehl aus, um Clips mit einer Auflösung von 720 x 480 zu kopieren:

        ./copy_media.sh 720x480
        

      • Wenn Sie die maximale Auflösung nicht kennen, kopieren Sie alle Dateien:

        ./copy_media.sh all
        

      • Wenn sich unter ADB mehrere Geräte befinden, fügen Sie die serielle Option hinzu. (-s) eines bestimmten Geräts bis zum Ende an. Um beispielsweise bis zu 720 x 480 an das Gerät mit der Seriennummer 1234567, führen Sie folgenden Befehl aus:

        ./copy_media.sh 720x480 -s 1234567