Developer Device Platform Device Run für Android

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.

In dieser Anleitung wird beschrieben, wie Sie einen Android-Instrumentierungstest mit der gcloud beta device-run CLI ausführen und die Ergebnisse in der Google Cloud Console aufrufen. Dabei wird davon ausgegangen, dass Sie ein Google Cloud -Konto und ein Projekt haben.

Wenn Sie diese Google Cloud CLI verwenden möchten, müssen Sie die ID Ihres Google Cloud Projekts angeben. Eine Zusammenfassung der Befehle finden Sie unter gcloud beta device-run.

Hinweis

Bei diesen Schritten wird davon ausgegangen, dass Sie bereits Folgendes getan haben:

1. Sie haben ein Google Cloud -Projekt erstellt.
2. Richten Sie die Developer Device Platform gemäß der Kurzanleitung ein.
3. Sie haben sich im Terminal mit gcloud authentifiziert.
4. Übersicht über Geräteausführung mit allgemeinen Informationen.
5. Instrumentierten Test für Android erstellt.

Schritt 1: Geräte auswählen

Mit der device-run-Befehlszeile können Android-Tests auf allen verfügbaren physischen und virtuellen Geräten ausgeführt werden. Eine vollständige Liste der verfügbaren Geräte finden Sie entweder im interaktiven Gerätekatalog oder durch Ausführen des folgenden Befehls:

gcloud beta device-run devices list

Beispielausgabe:

ID        MAKE    NAME     MODEL FORM      OS_VERSION CAPACITY  AVAILABILITY  PRODUCTS
tegu-35   Google  Pixel 9a tegu  PHYSICAL  35         MEDIUM    LOW           Automation, Streaming
tokay-34  Google  Pixel 9  tokay PHYSICAL  34         HIGH      HIGH          Automation, Streaming

Informationen zum Filtern dieser Liste finden Sie im Gerätekatalog. Wenn Sie ein bestimmtes Gerät für die Testausführung verwenden möchten, geben Sie die entsprechende ID an (z. B. tegu-35) im Befehl „submit“.

Schritt 2: Instrumentierungstest ausführen

Hinweis: Diese Flags sind für Android-Tests erforderlich:

• Gerät: Geben Sie ein Gerät mit --device an: --device shiba-35
• Test: Geben Sie das Test-APK mit --test an: --test /path/to/test.apk

Geben Sie zum Ausführen des Tests einen Befehl ein, der dem folgenden ähnelt, aber Ihre eigenen Geräte-IDs und Ihren eigenen Testpfad enthält:

gcloud beta device-run sessions submit instrumentation \
--device shiba-34 \
--apps /path/to/app.apk \
--test /path/to/test.apk

Der Ergebnisberichtsordner des Jobs befindet sich unter einem Cloud Storage-Pfad wie gs://BUCKET_NAME/automation/sessions/SESSION_ID/. Sehen Sie sich die Testausgabe für den Link an, die in etwa so aussieht: https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/.

Schritt 3: Testlauf konfigurieren

Tipp :Wenn Sie alle verfügbaren Optionen für den Befehl submit instrumentation aufrufen möchten, führen Sie gcloud beta device-run sessions submit instrumentation --help aus.

Nachdem Sie einen Test ausgeführt haben, können Sie einige Konfigurationsoptionen ausprobieren:

• Mehrere Geräte: Wenn Sie dieselben Tests auf mehreren Geräten ausführen möchten, geben Sie das Flag --device mit mehreren durch Kommas getrennten Geräte-IDs an, z. B. --device shiba-34,tokay-36, oder mit mehreren --device-Flags, die jeweils eine separate Geräte-ID angeben (z. B. --device shiba-34 --device tokay-36).
• Zusätzliche Apps: Sie können optional ein oder mehrere APKs angeben, die vor dem Ausführen der Tests installiert werden sollen. Verwenden Sie dazu das Flag --apps=path1,path2,...,path_n. Die von Ihnen angegebene Reihenfolge ist die Reihenfolge, in der diese Apps installiert werden.
• Test-Zeitüberschreitung: Begrenzen Sie die Ausführungsdauer: --instrumentation-timeout=10m (Der gültige Bereich liegt zwischen 1m und 1h und der Standardwert ist 5m).
• Benutzerdefinierter Cloud Storage-Bucket: Wenn Sie keinen Cloud Storage-Bucket mit dem Flag --bucket-name= angeben, verwendet die Google Cloud CLI einen Standard-Bucket mit dem Namen PROJECT_ID-devicerun.
• Wiederholungen instabiler Tests: Legen Sie die maximale Anzahl der Versuche fest, instabile Tests noch einmal auszuführen: --flaky-test-attempts=3 (Standardwert: 1 Versuch).

Schritt 4: Sharding verwenden

Wenn Sie die Developer Device Platform in einen CI/CD-Workflow (Continuous Integration und Continuous Delivery) einbinden möchten, sollten Sie Ihre Tests aufteilen. Beim Test-Sharding wird eine Reihe von Tests in Untergruppen (Shards) unterteilt, die separat und isoliert ausgeführt werden. Die Developer Device Platform führt automatisch jeden Shard parallel auf mehreren Geräten aus und schließt den gesamten Testsatz in kürzerer Zeit ab.

Achtung :Das Sharding von Tests kann mehr kosten. Obwohl durch Test-Sharding die Zeit verkürzt wird, die für die Ausführung aller Tests benötigt wird, kann der Aufwand für den Start Ihrer App auf jedem Shard die einzelnen Gerätezeiten verlängern.

Schritt 4.1: Sharding-Option auswählen

Wenn Ihre Jobs nur eine geringe Anzahl von Testläufen haben oder die Gesamtausführungszeit aller Testläufe nicht lang ist, ist es nicht erforderlich, Sharding zu verwenden. Wenn Sie eine große Anzahl von Testläufen haben oder die Gesamtausführungszeit aller Testläufe lang ist, sollten Sie Sharding verwenden.

Die Developer Device Platform unterstützt sowohl intelligentes als auch einheitliches Sharding. Berücksichtigen Sie bei der Entscheidung, wie Sie Ihre Tests aufteilen, die folgenden Optionen:

• Wenn alle Testläufe ungefähr gleich lange dauern, verwenden Sie einheitliches Sharding, indem Sie alle Testläufe in n Shards aufteilen.

• Wenn die Ausführungszeit der verschiedenen Testläufe stark variiert, verwenden Sie Smart Sharding. Die Developer Device Platform verwendet die bisherige Testausführungszeit, um verschiedene Shards zu erstellen, und versucht, alle Shards in einem ähnlichen Zeitraum abzuschließen.

Hinweis :Die Anzahl der Shards ist konfigurierbar. Wenn die Developer Device Platform viele Shards parallel ausführt, kann die Verfügbarkeit von Geräten zu Engpässen bei Testläufen führen. Aus diesem Grund empfehlen wir, dass die Anzahl der Geräte, die im --device-Flag angegeben sind, kleiner oder gleich der Anzahl der Shards ist.

Einheitliche Fragmentierung

Wenn Sie Ihre Tests mit gleichmäßiger Aufteilung auf mehrere Geräte aufteilen möchten, fügen Sie dem sessions submit instrumentation-Befehl die Flags --sharding-option=uniform und --uniform-sharding-count= hinzu:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
 --device shiba-34,tokay-36 \
    --sharding-option=uniform \
    --uniform-sharding-count=2

Die Ausgabe sollte Job status: 2 running enthalten. Der Dienst erstellt zwei Jobs, einen für jedes Gerät. Da die Eingaben für beide Jobs identisch sind, zentralisiert der Dienst die Validierung und führt sie nur einmal aus.

Die beiden Jobs werden in der endgültigen Ausgabe des Befehls nach Abschluss separat aufgeführt:

JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED

Smart Sharding

Wenn Sie Ihre Tests mit Smart Sharding aufteilen möchten, fügen Sie dem sessions submit instrumentation-Befehl die Flags --sharding-option=smart, --smart-sharding-max-shard-count=, --smart-sharding-target-duration= (in Minuten oder 1 h) und --smart-sharding-record-name= hinzu:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34,shiba-35,tokay-36 \
    --sharding-option=smart \
    --smart-sharding-max-shard-count=3 \
    --smart-sharding-target-duration=5m \
    --smart-sharding-record-name=test.yaml

Sie sollten eine endgültige Ausgabe sehen, die darauf hinweist, dass drei Jobs ausgeführt wurden:

Session [session-3cd0564a] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED
job-002   execution-000   PASSED

Hier ist eine Zusammenfassung der hier verwendeten Smart Sharding-Flags:

• --smart-sharding-max-shard-count=SMART_SHARDING_MAX_SHARD_COUNT: Gibt die maximale Anzahl von Shards an, die für das Smart Sharding erstellt werden sollen. Wenn der Wert nicht festgelegt oder auf 0 gesetzt ist, werden die vom System definierten Höchstwerte verwendet. Der gültige Bereich liegt zwischen 0 und 20 für physische Geräte und zwischen 0 und 200 für virtuelle Geräte.

• --smart-sharding-target-duration=SMART_SHARDING_TARGET_DURATION: Geben Sie die angestrebte Ausführungszeit (z.B. 2 Minuten, 10 Minuten, 1 Stunde) pro Shard für Smart Sharding an. Der gültige Bereich liegt zwischen 2 Minuten und 1 Stunde. Erforderlich, wenn --sharding-option=smart.

• --smart-sharding-record-name=SMART_SHARDING_RECORD_NAME: Geben Sie den Namen der Datei mit dem Smart Sharding-Datensatz ohne die Dateiendung an. Erforderlich, wenn „--sharding-option=smart“ festgelegt ist. Diese YAML-Datei befindet sich im Google CloudStorage-Bucket, das durch --bucket-name angegeben wird, im Verzeichnis smart-sharding/. Wenn die Datei nicht vorhanden ist, wird sie automatisch erstellt. Andernfalls wird ihr Inhalt nach Abschluss der Sitzung aktualisiert.

Schritt 5: Testlauf ansehen und verwalten

Sowohl im asynchronen als auch im synchronen Modus des Befehls sessions submit instrumentation können Sie den Befehl sessions describe verwenden, um den Jobstatus während der Ausführung abzufragen oder das Ergebnis nach Abschluss abzurufen:

gcloud beta device-run sessions describe SESSION_ID

Die Ausgabe fasst die Testergebnisse zusammen und enthält Links zu den Ergebnissen in der Google Cloud -Konsole. Beispiel:

Session SESSION_ID finished with result [FAILED].
Result files are stored at [https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   all             FAILED: 2 test cases failed, 5 passed

Verwenden Sie den folgenden Befehl, um alle laufenden und abgeschlossenen Sitzungen aufzulisten:

gcloud beta device-run sessions list

Sie erhalten eine Ausgabe mit der Liste der Sitzungen in Ihrem Projekt, die in etwa so aussieht:

SESSION_ID                                    START_TIME                STATE
session-4825e153                              2026-07-28T16:38:43.155Z  DONE
session-813ca602                              2026-07-28T22:40:32.415Z  DONE
session-67cd0570                              2026-07-16T08:25:55.474Z  DONE
session-17cc299c                              2026-07-14T14:31:33.649Z  DONE
session-911d0763                              2026-07-09T00:39:02.051Z  DONE
session-4e943fea                              2026-07-15T23:08:32.252Z  DONE
session-0132e458                              2026-08-20T18:33:19.751Z  DONE
session-1077f07b                              2026-07-28T22:35:43.848Z  DONE
session-71b054c6                              2026-07-15T01:15:41.643Z  DONE
session-4f8b2e45                              2026-08-06T23:11:56.161Z  DONE

Der Befehl sessions list unterstützt alle Standard-Google Cloud CLI-Flagoptionen. Beispiel:

gcloud beta device-run sessions list --limit 5

Die Ergebnisse sehen in etwa so aus:

SESSION_ID                            START_TIME                STATE
session-4825e153                      2026-07-28T16:38:43.155Z  DONE
session-813ca602                      2026-07-28T22:40:32.415Z  DONE
93ec2df2-d5bf-4c36-b7f7-c2a4fb0dc3ce  2026-07-03T05:10:58.015Z  DONE
session-67cd0570                      2026-07-16T08:25:55.474Z  DONE
session-17cc299c                      2026-07-14T14:31:33.649Z  DONE

So finden Sie alle laufenden Sitzungen:

gcloud beta device-run sessions list --filter RUNNING

Wenn Sie laufende Sitzungen haben, sehen Sie Ergebnisse wie diese:

SESSION_ID        START_TIME  STATE
session-d7ff8b81              RUNNING

Andernfalls erhalten Sie Listed 0 items..

Führen Sie den folgenden Befehl mit Ihrer Sitzungs-ID aus, um eine laufende Sitzung abzubrechen:

gcloud beta device-run sessions cancel SESSION_ID

Der Befehl wird sofort zurückgegeben, da die Sitzung nur als zu stornieren markiert ist. Die Kündigung erfolgt asynchron im Backend.

Wenn die Sitzung bereits beendet ist, wird nur der aktuelle Status ausgegeben. Wenn Sie den Abbruch einer abgeschlossenen Sitzung anfordern, ist das kein Fehler.

Nächste Schritte

Als Nächstes suchen und analysieren Sie Logs.