Developer Device Platform – Übersicht über Geräteausführungen

Willkommen bei „Developer Device Platform Device Run“. Mit diesem Dienst können Sie Tests und ausführbare Dateien auf physischen und virtuellen Android-Geräten sowie auf physischen iOS-Geräten in der Cloud ausführen. Auf dieser Seite werden die Funktionen zusammengefasst und Gemeinsamkeiten zwischen der Ausführung von Android-Instrumentierungstests, ausführbaren Android-Dateien und iOS-Tests beschrieben. Plattformspezifische Schritte finden Sie unter Device Run für Android und Device Run für iOS für.

Wenn Sie von Firebase Test Lab zu Developer Device Platform migrieren, lesen Sie unsere Migrationsanleitung, die Übersetzung von Befehlen und Flags sowie die Informationen zu Migrationskenntnissen für KI-Agents.

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

Hauptmerkmale

Developer Device Platform Device Run ist ein Google Cloud Dienst, mit dem Sie automatisierte Testsuiten auf physischen und virtuellen Mobilgeräten ausführen können. Device Run wurde für moderne CI/CD-Workflows (Continuous Integration und Continuous Delivery) entwickelt und bietet eine Befehlszeilensteuerung über die Google Cloud CLI (gcloud beta device-run). So können Teams Testsuiten auf dedizierter Hardware und in virtuellen Umgebungen ausführen, verwalten und skalieren.

1. Plattformübergreifende automatisierte Tests

  • Android- und iOS-Unterstützung: Device Run unterstützt integrierte Test frameworks, darunter Android-Instrumentierungstests (.apk), ausführbare Android Dateien (kompilierte Binärdateien) und iOS-XCTests (.ipa oder .zip).
  • Flexible Geräteauswahl: Mit dem Flag --device können Sie bestimmte physische oder virtuelle Geräte auswählen, die im Gerätekatalog aufgeführt sind. Verwenden Sie dazu Betriebssystem- und Modellkennungen (z. B. Pixel- oder iPhone-Modelle).
  • Parallele Ausführung auf mehreren Geräten: Sie können identische Testsuiten gleichzeitig auf mehreren Geräten ausführen, indem Sie durch Kommas getrennte Geräte- IDs angeben oder mehrere --device Flags verwenden.

2. Flexible Ausführungsmodi und ‑steuerungen

  • Synchrone und asynchrone Übermittlungen: Testläufe werden standardmäßig synchron ausgeführt und nach Abschluss wird eine Zusammenfassung angezeigt. Wenn Sie das Flag --async hinzufügen, wird sofort eine Sitzungs-ID für die nicht blockierende Ausführung zurückgegeben, die später mit gcloud beta device-run sessions wait überwacht werden kann.
  • Benutzerdefinierte Zeitlimits für die Ausführung*: Mit --instrumentation-timeout oder --xctest-timeout können Sie Zeitlimits für die Ausführungsdauer konfigurieren.
  • Wiederholungen bei instabilen Tests: Legen Sie die maximale Anzahl von Wiederholungen für instabile Testausführungen fest mit dem Flag --flaky-test-attempts.

3. Verwaltung von Softwareversionen und Abhängigkeiten

  • Konfigurierbare Testumgebungen*: Sie können bestimmte Softwareumgebungsversionen wie AndroidX Test Orchestrator und Apple Xcode ermitteln, prüfen und auswählen, bevor Sie Testläufe starten.
  • Versionsermittlung: Mit den Befehlen gcloud beta device-run software-versions list und describe können Sie aktive Softwarepakete, unterstützte Betriebssystemversionen, und Standardspezifikationen für die Laufzeit anzeigen.

4. Speicher- und Artefaktverwaltung

  • Cloud Storage-Integration: Testeingaben (APKs, IPAs, unterstützende Apps) und Ausgabeartefakte (Logs, Testberichte) werden in Cloud Storage gespeichert.
  • Bucket-Flexibilität: Standardmäßig wird ein Projekt-Bucket mit dem Namen PROJECT_ID-devicerun verwendet. Alternativ können Sie mit dem Flag --bucket-name einen benutzerdefinierten Bucket angeben. Sie haben die vollständige Kontrolle über diesen Bucket und müssen seine Inhalte manuell entfernen, wenn sie nicht mehr benötigt werden. Alternativ können Sie die automatische Lebenszyklusverwaltung für den Bucket konfigurieren. Eine Anleitung finden Sie unter Objekte löschen.
  • Direkte Cloud-Pfade: Sie können direkt auf vorhandene gs:// Pfade für große Dateien verweisen, um den Upload zu vermeiden.

5. Erweiterte Android-Testfunktionen

  • Android Test Orchestrator: Sie können die Testausführung isolieren, indem Sie jeden Test in einer eigenen Instrumentation Instanz ausführen. So verhindern Sie einen gemeinsamen App-Status und isolieren App-Abstürze.
  • Test Sharding:
    • Einheitliches Sharding: Die Testfälle werden gleichmäßig auf eine bestimmte Anzahl von Shards aufgeteilt (--sharding-option=uniform).
    • Intelligentes Sharding: Hierbei werden Verlaufsdaten zur Testausführung verwendet, um Testfälle dynamisch auf Shards zu verteilen und eine bestimmte Gesamtausführungsdauer zu erreichen (--sharding-option=smart).

6. Sitzungsverwaltung und Diagnose

  • Vollständige Sitzungssteuerung: Mit sessions list, sessions describe und sessions cancel können Sie aktive oder frühere Testläufe auflisten, beschreiben, filtern oder abbrechen.
  • Frühe Eingabevalidierung: Es wird eine automatische Validierung der übermittelten Test Binärdateien und Konfigurationsartefakte durchgeführt. Bei Fehlern werden explizite Fehlerdetails und Ursachen (z. B. nicht übereinstimmende Zielpakete) angezeigt.

Haupteinstellungen

Erforderliche Flags

Beachten Sie, dass diese Flags erforderlich sind:

  • Gerät: Geben Sie ein Gerät mit --device an: --device shiba-35 oder --device iphonese3-18-4
  • Test oder ausführbare Datei: Geben Sie das Testpaket mit --test an (--test /path/to/test.apk oder --test /path/to/MyTests.zip) für Testläufe oder die ausführbare Binärdatei oder das Skript mit --executable (--executable /path/to/my_executable) für die Ausführung ausführbarer Android-Dateien.

Die folgenden Konfigurationsoptionen sind für alle Device Run-Sitzungen gleich.

Cloud Storage-Pfade für Eingabe und Ausgabe

  • Benutzerdefinierter Cloud Storage-Bucket: Sie können einen benutzerdefinierten Cloud Storage Bucket für Eingaben und Ausgaben angeben: --bucket-name=my-custom-bucket Wenn Sie mit dem Flag --bucket-name= keinen Cloud Storage-Bucket angeben, verwendet die Google Cloud CLI einen Standard-Bucket mit dem Namen PROJECT_ID-devicerun.
  • Eingabedateien: Wenn Sie mit den Flags --test, --executable, --apps, --additional-apps, --other-files-to-push oder --xctestrun-file einen lokalen Pfad angeben, kopiert die Google Cloud CLI ihn bei jeder Ausführung des Befehls automatisch in Ihren Cloud Storage-Bucket unter gs://BUCKET_NAME/automation/inputs/DATE_TIME_FOUR_CHARS_SUFFIX/. Standardmäßig ist BUCKET_NAME auf PROJECT_ID-devicerun festgelegt.
  • Cloud-Pfade: Da das Hochladen großer Dateien zeitaufwendig sein kann, können Sie direkt auf sie verweisen, indem Sie ihre Cloud Storage-gs://Pfade verwenden. So sparen Sie Zeit beim Hochladen.
  • Ergebnisdateien: Ausgabeartefakte werden in Ihren Cloud Storage Bucket unter gs://BUCKET_NAME/automation/sessions/session-[SESSION_ID]/ hochgeladen.

Eingabevalidierung

Developer Device Platform versucht, Ihre Eingaben einschließlich Artefakte zu validieren. Bei fehlerhaften Eingaben wird ERROR anstelle von PASSED oder FAILED zurückgegeben:

Session [session-94b57778] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   ERROR

Hängen Sie jetzt --full an den Befehl sessions describe an, um weitere Details zur Sitzung zu sehen:

gcloud beta device-run sessions describe --full session-94b57778

Die Ausgabe sieht dann ungefähr so aus:

name: projects/user-test1/locations/global/sessions/session-94b57778
sessionConfig:
  displayName: instrumentation-session
  jobConfigs:
  -   action:
      androidInstrumentationTest:
        testInstallable:
          files:
          -   gcsInputFile:
              path: gs://user-test1-devicerun/automation/inputs/2026-09-16_18:55.17372947_EECF/my-test.apk
    allocationConfig:
      deviceConfigs:
      -   actions:
        -   androidLogcat: {}
        requirement:
          deviceId: mediumphone-arm-34
    displayName: job-000
  outputDirectoryConfig:
    gcsOutputDirectory:
      path: gs://user-test1-devicerun/automation/sessions
sessionReport:
  endTime: '2026-09-16T18:55:49.721Z'
  id: ed681f23-669b-4464-8a93-b28456e58136
  jobReports:
  -   displayName: job-000
    endTime: '2026-09-16T18:55:45.839Z'
    executionReports:
    -   displayName: execution-000
      endTime: '2026-09-16T18:55:46.694Z'
      id: ce370173-af94-4dd7-acc6-0863e4d2e9ec
      result:
        cause:
          summary:
            message: The instrumentation target package does not match any of the
              installable packages.
            reason: INSTRUMENTATION_TARGET_MISMATCH
            type: CUSTOMER
        resultType: ERROR
      startTime: '1970-01-01T00:00:00Z'
      status:
        statusType: PENDING
    id: 953b5106-3c20-40f0-aceb-18af89cd1b83
    result:
      cause:
        summary:
          message: The instrumentation target package does not match any of the installable
            packages.
          reason: INSTRUMENTATION_TARGET_MISMATCH
          type: CUSTOMER
      resultType: ERROR
    startTime: '2026-09-16T18:55:31.651Z'
    status:
      statusType: DONE
  result:
    resultType: ERROR
  startTime: '2026-09-16T18:55:24.442Z'
  status:
    statusType: DONE

Nächste Schritte

Android-Test oder ausführbare Datei ausführen oder iOS-Test ausführen mit Developer Device Platform.