Fehlerbehebung und häufig gestellte Fragen zur Developer Device Platform

Vorschau

Dieses Produkt oder Feature unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Auf dieser Seite finden Sie Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte Fragen zum Ausführen von Tests mit der Developer Device Platform. Wenn Sie nicht finden, wonach Sie suchen, oder weitere Hilfe benötigen, wenden Sie sich an uns.

Fehlerbehebung

Warum dauert es so lange, bis mein Test ausgeführt wird?

Wenn Sie ein Gerät mit hoher Kapazität im Katalog der Developer Device Platform auswählen, können Tests schneller gestartet werden. Wenn ein Gerät eine geringe Kapazität hat, kann es länger dauern, bis Tests ausgeführt werden. Wenn die Anzahl der aufgerufenen Tests viel größer ist als die Kapazität der ausgewählten Geräte, kann es länger dauern, bis die Tests abgeschlossen sind.

Tests, die auf Geräten mit beliebiger Kapazität ausgeführt werden, können aus folgenden Gründen länger dauern:

• Traffic, der sich auf die Geräteverfügbarkeit und die Testgeschwindigkeit auswirkt.
• Geräte- oder Infrastrukturfehler, die jederzeit auftreten können. Wenn Sie prüfen möchten, ob es eine gemeldete Infrastruktur für die Developer Device Platform gibt, sehen Sie im Dashboard Google Cloud Personalized Service Health nach.

Weitere Informationen zur Gerätekapazität auf der Developer Device Platform finden Sie im Gerätekatalog.

Warum erhalte ich nicht aussagekräftige Testergebnisse?

Nicht eindeutige Testergebnisse sind in der Regel auf abgebrochene Testläufe oder Infrastrukturfehler zurückzuführen. Zusätzlich zu PASSED und FAILED kann die Developer Device Platform auch ERROR, TIMED_OUT und CANCELLED zurückgeben.

Infrastrukturfehler werden durch interne Probleme der Developer Device Platform verursacht, z. B. Netzwerkfehler oder unerwartetes Geräteverhalten. Die Developer Device Platform wiederholt Testläufe, bei denen Infrastrukturfehler auftreten, intern mehrmals, bevor ein nicht eindeutiges Ergebnis gemeldet wird.

So ermitteln Sie die Ursache des Fehlers:

1. Prüfen Sie im Google Cloud Service Health-Dashboard, ob bekannte Ausfälle vorliegen.

2. Wiederholen Sie den Test auf der Developer Device Platform, um zu prüfen, ob er reproduzierbar ist.

   Hinweis :Für Infrastrukturfehler werden Ihnen auf der Developer Device Platform keine Gebühren berechnet.

3. Führen Sie den Test gegebenenfalls auf einem anderen Gerät oder Gerätetyp aus. Weitere Informationen finden Sie im Gerätekatalog.

Warum dauern meine Tests durch Sharding länger?

Durch Sharding können Ihre Tests länger dauern, wenn die von Ihnen angegebene Anzahl von Shards die Anzahl der Geräte überschreitet, die auf der Developer Device Platform verfügbar sind. Um diese Situation zu vermeiden, sollten Sie die Anzahl der Geräte auf die Anzahl der Shards beschränken. Weitere Informationen zur Auswahl eines anderen Geräts finden Sie im Gerätekatalog.

Warum dauert es so lange, bis mein Test beginnt?

Wenn Sie eine Testanfrage senden, wird Ihre App zuerst validiert, neu signiert usw., um sie für die Ausführung von Tests auf einem Gerät vorzubereiten. Normalerweise dauert dieser Vorgang nur wenige Sekunden, kann aber durch Faktoren wie die Größe Ihrer App beeinflusst werden.

Nachdem Ihre App vorbereitet wurde, werden Testläufe geplant und in eine Warteschlange gestellt, bis ein Gerät für die Ausführung bereit ist.

Hinweis :Die Wartezeit Ihres Tests auf ein verfügbares Gerät wird nicht auf die Abrechnungszeit angerechnet.

Warum dauert es so lange, bis mein Test abgeschlossen ist?

Nach Abschluss der Testausführung werden Testartefakte vom Gerät heruntergeladen, verarbeitet und in Cloud Storage hochgeladen. Die Dauer dieses Schritts kann durch die Menge und Größe der Artefakte beeinflusst werden.

Android-spezifische Fehlerbehebung

App gibt keine Daten zurück und Screenshots sind nicht zu finden

Artefakte der Testausführung (z. B. Screenshots und Logdateien) werden in Cloud Storage gespeichert und direkt in der Google Cloud -Konsole gerendert. Prüfen Sie, ob Sie Rollen auf Projektebene zugewiesen haben.

Außerdem hat die Developer Device Platform ein eigenes Dienst-Agent, das eigene Anmeldedaten anstelle Ihrer verwendet, um:

• In Cloud Storage-Buckets und -Objekte lesen und schreiben
• Cloud Storage-Eingabedateien auf das interne System herunterladen
• Dateien aus dem internen System in den Cloud Storage-Ausgabe-Bucket hochladen

Möglicherweise haben Sie Zugriff auf einen Cloud Storage-Bucket und eine Datei, aber dieser Bucket gehört zu einem anderen Google Cloud Projekt als dem, das in DDP verwendet wird. Daher hat das Dienstkonto der Developer Device Platform keinen Zugriff darauf.

Möglicherweise haben Sie auch zusätzliche Zugriffssteuerungen für einzelne Buckets. Informationen dazu, wie Sie Dateien in Ihre Tests einbeziehen, finden Sie unter Device Run.

Warum erhalte ich nur teilweise oder gar keine Ergebnisse für Instrumentierungstests?

Wenn Sie Instrumentierungstests ausführen, ist die Gesamtzahl der Testläufe möglicherweise geringer als erwartet. Das liegt oft daran, dass die Developer Device Platform das Logcat nicht nach Start- oder Endmarkierungen für Testläufe parsen kann, die normalerweise von AndroidJUnitRunner generiert werden.

Das sind häufige Ursachen für dieses Problem:

Problembeschreibung	Mögliche Lösung
Der Testlauf wurde aufgrund einer Zeitüberschreitung nicht ausgeführt. Wenn die Gesamtdauer der Tests länger als ein von Ihnen angegebenes oder ein maximales Zeitlimit ist, werden die restlichen Testläufe von der Developer Device Platform abgebrochen.	Erhöhen Sie das Instrumentierungs-Zeitlimit für den Test mit `--instrumentation-timeout`, damit alle Tests abgeschlossen werden können. Teilen Sie die Tests in Shards auf, falls Sie das noch nicht getan haben. So wird in jedem Shard nur eine Teilmenge der Tests ausgeführt und die Ausführung dauert weniger lange. Wenn Sie die Fragmentierung bereits aktiviert haben, erhöhen Sie die Anzahl der Shards.
Der Testlauf konnte nicht abgeschlossen werden, da er vorzeitig beendet wurde oder hängen geblieben ist. Der Testlauf kann aufgrund einer nicht abgefangenen Ausnahme oder eines Zusicherungsfehlers vorzeitig beendet werden. Testläufe können in einer Endlosschleife hängen bleiben oder nicht fortgesetzt werden, z. B. wenn in der App nicht die richtige Ansicht angezeigt wird und der Testlauf die Aktion nicht auf der Benutzeroberfläche ausführen kann.	Sehen Sie sich das Video und die logcat an, um herauszufinden, wo der Test beendet wurde.
Ein benutzerdefinierter Test-Runner (einschließlich der Erweiterung von AndroidJUnitRunner) ist unerwartet abgestürzt oder hat unerwartete Markierungen für den Start oder das Ende von Testläufen in logcat geschrieben.	Überprüfen Sie den Code des Test-Runners.
Es wurden zu viele Logs in logcat geschrieben, was zu einer Überlastung des Puffers oder einem Absturz des logcat-Prozesses führte.	Schreibvorgänge auf logcat reduzieren
Die getestete App ist abgestürzt.	Debuggen Sie Ihre App.

---

FAQ

Wo finde ich Informationen zu den Preisen für die Developer Device Platform?

Weitere Informationen finden Sie unter Fragen zu Preisen und Abrechnung.

Wo finde ich Gerätedetails wie die Auflösung?

Detaillierte Geräteinformationen sind über die API verfügbar und können über die Developer Device Platform CLI mit dem Befehl device-run devices describe <device-id> aufgerufen werden:

gcloud beta device-run devices describe DEVICE_ID

Woher weiß ich, ob der Traffic, der mein Backend erreicht, von der Developer Device Platform stammt?

In Ihrem Backend können Sie anhand der Quell-IP-Adresse und unserer IP-Bereiche feststellen, ob der Traffic von Testgeräten stammt, die auf der Developer Device Platform gehostet werden.

Funktioniert die Developer Device Platform mit VPC-SC?

Die Entwicklergeräteplattform funktioniert nicht mit VPC-SC. Dadurch wird das Kopieren von Apps und anderen Testartefakten zwischen dem internen Speicher der Entwicklergeräteplattform und den Ergebnis-Buckets der Nutzer blockiert.

Wie kann ich fehlerhafte Tests auf der Developer Device Platform reduzieren?

Um instabiles Verhalten in Ihren Tests zu erkennen, empfehlen wir die Verwendung der Option --flaky-test-attempts. Deflake-Wiederholungen werden genauso abgerechnet oder auf Ihr Tageskontingent angerechnet wie normale Testausführungen.

Beachten Sie Folgendes:

• DDP führt den Wiederholungsversuch standardmäßig sequenziell aus, um Kosten zu sparen. Nutzer müssen --flaky-test-parallel-retry so einstellen, dass die Ausführung parallel erfolgt.
• Das Flag --flaky-test-retry-level gibt an, ob die Wiederholung auf der Ebene shard oder auf der Ebene der einzelnen test erfolgen soll. Der Standardwert ist shard. Legen Sie den Wert auf test fest, um die Größe und Dauer des Wiederholungsversuchs zu verringern.

Hinweis :Infrastrukturfehler sind unabhängig von der Funktion zum Entfernen von Flakes und lösen keine Wiederholungen zum Entfernen von Flakes aus.

iOS-spezifische FAQs

Unterstützt die Developer Device Platform Appium, Flutter/FlutterDriver, ReactNative/Jest oder Cucumber?

Einige dieser Elemente sind zwar auf unserer Roadmap, wir können jedoch nicht zusagen, dass wir diese Test- und App-Entwicklungsplattformen unterstützen werden.

Warum fehlen in den Ergebnissen meines iOS-Tests Videos?

Die Unterstützung für Videos in den Ergebnissen ist für iOS 18 oder höher geplant.

Android-spezifische FAQs

Unterstützt die Developer Device Platform Wearables?

Ja. Die Developer Device Platform unterstützt die Google Pixel Watch. Sie können jetzt Tests für Ihre eigenständige Wear OS-App auf Google Pixel Watches ausführen. Weitere Informationen zu Geräten der Developer Device Platform finden Sie im Gerätekatalog.

Unterstützt die Developer Device Platform die neuesten Google-Geräte?

Ja. Die Developer Device Platform unterstützt das Google Pixel Tablet und das Google Pixel Fold. Sie können Ihre Tests auf Ihren eigenständigen physischen Geräten ausführen. Weitere Informationen zu den in der Developer Device Platform verfügbaren Geräten

Unterstützt die Developer Device Platform Appium, Flutter/FlutterDriver, ReactNative/Jest oder Cucumber?

Einige dieser Elemente sind zwar auf unserer Roadmap, wir können jedoch nicht zusagen, dass wir diese Test- und App-Entwicklungsplattformen unterstützen werden. Wenn Sie Ihre App jedoch mit einem Framework erstellt haben, das Espresso unterstützt (z. B. Flutter), können Sie einen Instrumentierungstest mit Espresso schreiben und den Test dann auf der Developer Device Platform ausführen.

Unterstützt die Developer Device Platform das Testen von verschleierten Apps, z. B. mit ProGuard oder R8?

Die Developer Device Platform unterstützt die Verschleierung oder Entschleierung nicht explizit. Die App wird wahrscheinlich ausgeführt, aber alle verschleierten App-Daten, z. B. Stacktraces, werden in den Logs verschleiert angezeigt.

Kann ich mein faltbares Gerät in verschiedenen faltbaren Zuständen und Positionen verwenden, wenn ich auf der Developer Device Platform teste?

Ja. Sie können Ihr faltbares Gerät in verschiedenen Faltzuständen und Positionen testen.

Faltbare Geräte können sich in verschiedenen gefalteten Zuständen befinden, z. B. FLAT (vollständig geöffnet) oder HALF_OPENED (zwischen vollständig geöffnet und vollständig geschlossen).

Posen bestehen dagegen aus einer bestimmten Geräteausrichtung und einem bestimmten Zustand des faltbaren Geräts. Beispiele sind die Tischposition, die ein HALF_OPENED-Zustand in horizontaler Ausrichtung ist, oder die Buchposition, die ein HALF_OPENED-Zustand in vertikaler Ausrichtung ist.

Wenn Sie Instrumentationstests ausführen, können Sie die Jetpack WindowManager-Bibliothek verwenden und der Dokumentation zum Testen Ihrer App auf faltbaren Geräten folgen, um verschiedene Status und Positionen zu testen.

Alternativ sind verfügbare Status gerätespezifisch und können über die adb shell command cmd device_state gesteuert werden.

• Führen Sie adb shell cmd device_state state aus, um den aktuellen Status aufzulisten.
• Wenn Sie den aktuellen Status festlegen oder überschreiben möchten, führen Sie adb shell cmd device_state state <IDENTIFIER> aus.
• Führen Sie adb shell cmd device_state state reset aus, um den Status zurückzusetzen.
• Führen Sie den Befehl adb shell cmd device_state print-states auf dem faltbaren Gerät aus, um die verfügbaren Status zu prüfen.

Google Pixel Fold (Modell-ID felix)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSED', app_accessible=true},
      DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
      DeviceState{identifier=2, name='OPENED', app_accessible=true},
      DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]

Samsung Galaxy Z Fold4 (Modell-ID q4q)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSE', app_accessible=true},
      DeviceState{identifier=1, name='TENT', app_accessible=true},
      DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
      DeviceState{identifier=3, name='OPEN', app_accessible=true},
]

Kann ich die Developer Device Platform ausprobieren, wenn ich keine App habe?

Anders als bei anderen Developer Device Platform-Produkten müssen Sie kein Developer Device Platform SDK hinzufügen, um die Developer Device Platform zu verwenden. Wenn Sie noch keine App haben, können Sie ein APK online herunterladen oder eine App und ein Test-APK aus einem der Beispiele im AndroidX-GitHub-Repository erstellen. Für einen Instrumentationstest sind sowohl eine App als auch ein Test-APK erforderlich, die aus Quellcode erstellt werden. Weitere Informationen finden Sie unter Instrumentierte Tests.

Weitere Informationen zu den Funktionen der Developer Device Platform finden Sie in der DDP-Produktübersicht.

Welche Geräte eignen sich am besten für Screenshot-Diff-Tests?

Beim Screenshot-Diff-Test basieren Testassertions auf dem Vergleich von Screenshots, die während der Ausführung eines Tests aufgenommen wurden, mit Golden-Images, die das erwartete Verhalten darstellen. Solche Tests sind auf einigen Gerätetypen möglicherweise anfälliger als auf anderen. Wir empfehlen, für diese Art von Tests Arm-Emulatoren (*.arm) zu verwenden. Arm-Emulatorgeräte verwenden Images, die den generischen Emulatoren von Android Studio sehr ähnlich oder identisch sind.

Außerdem empfehlen wir, Testbibliotheken zu verwenden, mit denen Screenshot-Tests bei erwarteten Änderungen robuster werden.

Werden virtuelle Geräte über die Developer Device Platform aktualisiert?

Ja. Virtuelle Geräte werden aktualisiert, wenn die folgenden Änderungen vorgenommen werden:

1. Aktualisierungen vorhandener Bilder
2. Einstellung früherer API-Levels
3. Neue Android-API-Levels werden hinzugefügt

Wie aktiviere ich Abdeckungsberichte?

Wenn Sie Coverage-Berichte aktivieren möchten, fügen Sie coverage=true dem Feld additional-test-options hinzu. Wenn Sie Android Test Orchestrator verwenden, müssen Sie einen Verzeichnispfad zum Speichern der Abdeckungsergebnisse angeben:

--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/

Wenn Sie Orchestrator nicht verwenden, können Sie einen Dateipfad angeben:

--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec

Wie melde ich mich in einer Wear-App ohne Smartphone an?

Wenn für die Anmeldung in Ihrer App normalerweise ein Smartphone erforderlich ist, können Sie eine Build-Variante erstellen, bei der die Anmeldung übersprungen wird und ein in Ihren Test-Build eingebettetes Token verwendet wird. Alternativ können Sie Daten aus Dateien auf dem Datenträger lesen, die in der Regel mit dem Flag --other-files-to-push übertragen werden.

---