Android Studio Hedgehog | 2023.1.1 (Nov. 2023)

Die folgenden neuen Funktionen sind in Android Studio Hedgehog verfügbar.

Plattformupdate für IntelliJ IDEA 2023.1

Android Studio Hedgehog enthält die Updates für IntelliJ IDEA 2023.1, die die Studio IDE verbessern. Weitere Informationen zu den Änderungen finden Sie in den Versionshinweisen für IntelliJ IDEA 2023.1.

Android Vitals in App Quality Insights analysieren

App Quality Insights enthält jetzt auch Android Vitals-Daten. So können Sie einfacher auf die von Google Play erfassten Kernmesswerte zugreifen und die Nutzerfreundlichkeit verbessern. Mit Android Vitals kannst du Probleme mit der App-Stabilität beheben und die Qualität deiner App bei Google Play verbessern.

Im Toolfenster App Quality Insights kannst du Android Vitals-Probleme aufrufen, filtern und vom Stacktrace zu Code wechseln. Gehen Sie dazu so vor:

  1. Melde dich in Android Studio über das Profilsymbol am Ende der Symbolleiste in deinem Entwicklerkonto an.
  2. Öffnen Sie App Quality Insights, indem Sie in Android Studio auf das Toolfenster oder auf Ansicht > Toolfenster > App Quality Insights klicken.
  3. Klicken Sie in App Quality Insights auf den Tab Android Vitals.

Unterschiedliche Zahlen in Android Vitals und Crashlytics

Beachten Sie, dass Android Vitals und Crashlytics unterschiedliche Werte für die Anzahl der Nutzer und Ereignisse melden, die mit demselben Absturz in Verbindung stehen. Das liegt daran, dass Play und Crashlytics Abstürze zu unterschiedlichen Zeiten und für unterschiedliche Nutzer erkennen können. Im Folgenden finden Sie einige Gründe dafür, warum die Anzahl der Play- und Crashlytics-Anzahl abweichen kann:

  • Google Play erkennt Abstürze, die beim Booten beginnen, während Crashlytics Abstürze erfasst, die nach der Initialisierung des Crashlytics SDK auftreten.
  • Wenn ein Nutzer die Absturzberichte deaktiviert, wenn er ein neues Smartphone erhält, werden diese Abstürze nicht an Play gemeldet. Crashlytics erfasst jedoch Abstürze gemäß der eigenen Datenschutzerklärung einer App.

Neuer Power Profiler

Ab Android Studio Hedgehog zeigt der Power Profiler den Energieverbrauch von Geräten an. Sie können diese neuen Daten im On Device Power Rails Monitor (ODPM) ansehen. Das ODPM segmentiert die Daten nach Subsystemen, die als Power Rails bezeichnet werden. Eine Liste der unterstützten Subsysteme finden Sie unter Profilierbare Stromleisten.

Das System Trace zeichnet die Energieverbrauchsdaten auf und zeigt sie an. Er ist Teil des CPU-Profilers. Mithilfe dieser Daten können Sie den Energieverbrauch des Geräts visuell mit den Aktionen in Beziehung setzen, die in Ihrer App ausgeführt werden. Mit dem Power Profiler können Sie diese Daten visualisieren.

Der neue Power Profiler

Erstellen Sie zum Ansehen der Daten aus dem neuen Power Profiler einen System-Trace auf einem Pixel 6 oder höher:

  1. Wählen Sie View > Tool Windows > Profiler aus.
  2. Klicken Sie auf eine beliebige Stelle auf der CPU-Zeitachse, um den CPU-Profiler zu öffnen und einen System-Trace zu starten.

Der neue App-Link-Assistent bietet einen umfassenden Überblick über die in Ihrer App eingerichteten Deeplinks. Er zeigt alle vorhandenen Deeplinks in der Datei AndroidManifest.xml der App an, prüft, ob die Konfiguration für diese Deeplinks korrekt ist, und bietet eine schnelle Möglichkeit, die Fehlkonfigurationen automatisch zu beheben.

Um den App-Link-Assistenten zu öffnen, rufen Sie in Android Studio Tools > App-Link-Assistent auf. Weitere Informationen zu App-Links finden Sie unter Android-App-Links hinzufügen.

Live-Bearbeitung hat den Kurzbefehl für den manuellen Modus aktualisiert

Live Edit in Android Studio Hedgehog bietet eine neue Tastenkombination für den manuellen Modus (Manuell übertragen): Strg + \ (Befehlstaste + \ für macOS). Der manuelle Modus ist hilfreich, wenn Sie präzise steuern möchten, wann Updates für die laufende Anwendung bereitgestellt werden. Das ist beispielsweise der Fall, wenn Sie eine umfangreiche Änderung in einer Datei vornehmen und nicht möchten, dass ein Zwischenstatus auf dem Gerät widergespiegelt wird. Du kannst in den Live Edit-Einstellungen oder über die Live Edit UI-Anzeige zwischen Manuell senden und Beim Speichern manuell senden auswählen. Weitere Informationen finden Sie im Videoclip unter Live-Bearbeitung für Jetpack Compose.

Vorlagen mit mehreren Vorschauen erstellen

Mit androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ werden neue Multipreview API-Vorlagen eingeführt: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark und @PreviewDynamicColors. Mit nur einer Annotation können Sie sich also in gängigen Szenarien eine Vorschau der Compose-UI ansehen.

In Android Studio Hedgehog wurde ein neuer Galeriemodus für die Vorschaufunktion eingeführt, mit dem Sie sich jeweils auf eine Vorschau konzentrieren und Ressourcen für das Rendering sparen können. Wir empfehlen den Galeriemodus, wenn Sie die Benutzeroberfläche Ihrer App iterieren und in andere Modi wie „Raster“ oder „Liste“ wechseln müssen, wenn Sie UI-Varianten sehen möchten.

Statusinformationen im Debugger erstellen

Wenn sich Teile der Benutzeroberfläche zum Schreiben unerwartet neu zusammensetzen, ist manchmal schwer nachvollziehbar, warum. Wenn Sie jetzt einen Haltepunkt für eine zusammensetzbare Funktion festlegen, werden im Debugger die Parameter der zusammensetzbaren Funktion und ihr Status aufgelistet. So können Sie leichter erkennen, welche Änderungen die Neuzusammensetzung verursacht haben könnten. Wenn Sie beispielsweise eine zusammensetzbare Funktion pausieren, teilt Ihnen der Debugger genau mit, welche Parameter „Geändert“ oder „Unverändert“ geblieben sind. So können Sie die Ursache der Neuzusammensetzung effizienter untersuchen.

Gerätespiegelung

Sie können Ihr physisches Gerät jetzt im Fenster Running Devices in Android Studio spiegeln. Wenn Sie den Bildschirm Ihres Geräts direkt zu Android Studio streamen, können Sie gängige Aktionen wie das Starten und Interagieren mit Apps, das Drehen des Bildschirms, das Aus- und Zuklappen des Smartphones, das Ändern der Lautstärke und vieles mehr direkt von der Studio-IDE aus ausführen.

Die Gerätespiegelung ist immer verfügbar, wenn mit dem Computer verbundene Geräte mit aktiviertem USB- oder kabellosem Debugging verbunden sind. Sie können das Spiegeln über das Fenster Aktive Geräte oder den Geräte-Manager (Ansicht > Tool-Fenster > Geräte-Manager) starten und beenden. Sie können auch in den Einstellungen festlegen, wann die Gerätespiegelung aktiviert wird (Einstellungen > Tools > Gerätespiegelung).

Benutzeroberfläche für laufende Geräte

Bekannte Probleme

Einige Geräte können möglicherweise nicht mit einer für die Gerätespiegelung ausreichenden Bitrate codiert werden. In diesen Situationen wird möglicherweise ein Fehler im Fenster Laufende Geräte sowie ähnliche Protokolle wie unten angezeigt.

2023-06-01 15:32:22,675 [  56094]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - Too many video encoder errors:
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - encoder: c2.android.vp8.encoder
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - mime type: video/x-vnd.on2.vp8
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max resolution: 640x640
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - min resolution: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - alignment: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate: 960
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate for 288x640: 960
2023-06-01 15:32:22,870 [  56289]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max bitrate: 20000000
2023-06-01 15:32:22,871 [  56290]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - terminated with code 1

Datenschutzhinweise

Je nach den Einstellungen für die Gerätespiegelung kann Android Studio die Gerätespiegelung für alle verbundenen und gekoppelten Geräte automatisch starten. Dies kann dazu führen, dass Informationen für Geräte offengelegt werden, die mit dem Befehl adb tcpip verbunden sind, da die Spiegelungsinformationen und Befehle über einen unverschlüsselten Kanal übergeben werden. Darüber hinaus verwendet Android Studio einen unverschlüsselten Kanal für die Kommunikation mit dem ADB-Server, sodass Spiegelungen von anderen Nutzern auf Ihrem Hostcomputer abgefangen werden können.

Weiterleitung von Hardware-Eingaben

Sie können jetzt die transparente Weiterleitung der Hardwareeingaben Ihrer Workstation, z. B. Maus und Tastatur, an ein verbundenes physisches und virtuelles Gerät aktivieren. Klicken Sie zum Aktivieren der transparenten Weiterleitung im Fenster Running Devices für das Zielgerät auf Hardware-Eingabe .

Geräte direkt über das Fenster „Aktive Geräte“ verwalten

Sie können jetzt direkt im Fenster Running Devices ein virtuelles Android-Gerät (AVD) starten oder das Spiegeln eines physischen Geräts starten. Klicken Sie dazu auf das Symbol + und wählen Sie ein Gerät aus. Schließen Sie den Geräte-Tab, um das AVD oder die Spiegelung eines physischen Geräts zu beenden.

Drop-down-Menü „Geräte“ unter „Aktive Geräte“

Eingebetteter Layout Inspector

Ab Android Studio Hedgehog Canary 2 können Sie den Layout Inspector direkt im Fenster Aktive Geräte ausführen. Mit dieser experimentellen Funktion wird Platz auf dem Bildschirm eingespart und der UI-Fehlerbehebungsworkflow in einem einzigen Toolfenster organisiert. Im eingebetteten Modus können Sie eine Ansichtshierarchie darstellen, die Eigenschaften der einzelnen Ansichten prüfen und auf andere gängige Funktionen des Layout Inspectors zugreifen. Wenn Sie alle Optionen nutzen möchten, müssen Sie den Layout Inspector in einem eigenständigen Fenster ausführen (Datei > Einstellungen > Experimentell > Layout Inspector unter Windows oder Android Studio > Einstellungen > Experimentell > Layout Inspector unter macOS).

Eine Einschränkung des eingebetteten Layout Inspectors besteht darin, dass der 3D-Modus nur in Snapshots verfügbar ist.

Bitte senden Sie uns Feedback, damit wir den eingebetteten Layout Inspector verbessern können.

Neue Verbesserungen an der Benutzeroberfläche

Die neue Benutzeroberfläche von Android Studio verleiht der Studio IDE ein modernes und übersichtlicheres Erscheinungsbild. Wir haben uns Ihr bisheriges Feedback zu Herzen genommen und Probleme im Zusammenhang mit den folgenden Funktionen in Android Studio Hedgehog behoben:

  • Kompaktmodus
  • Unterstützung für das vertikale oder horizontale Teilen
  • Projekttabs für macOS
  • Korrekturen im Modus ohne Ablenkung
  • Erweiterte Einstellungen, um Aktionen für Toolfenster immer anzeigen zu lassen

Assistant-Updates für das SDK-Upgrade

Im SDK Upgrade Assistant finden Sie eine detaillierte Anleitung für targetSdkVersion-Upgrades. Dies sind die Aktualisierungen des SDK-Upgrade-Assistenten in Android Studio Hedgehog:

  • Wichtige Änderungen beim Upgrade auf Android 14
  • Relevanzfilter hinzugefügt, um unnötige Schritte zu eliminieren
  • Bei bestimmten Änderungen muss genau angegeben werden, an welcher Stelle im Code die Änderungen vorgenommen werden müssen.

Build-Optimierung nur für Ziel-API-Level deaktivieren

Du kannst jetzt die IDE-Optimierung für das Zielgeräte-API-Level deaktivieren. Standardmäßig verringert Android Studio die Gesamt-Build-Zeit, indem der Dexing-Prozess an das API-Level des Zielgeräts angepasst wird, auf dem die Bereitstellung erfolgt. Wenn Sie diese Funktion deaktivieren möchten, gehen Sie zu Datei > Einstellungen > Experimentell (Android Studio > Einstellungen > Experimentell unter macOS) und entfernen Sie das Häkchen bei Build nur für Zielgeräte-API-Level optimieren. Das Deaktivieren dieser Build-Optimierung kann die Build-Dauer erhöhen.

[Nur Windows] Auswirkungen von Antivirensoftware auf die Build-Geschwindigkeit minimieren

Build Analyzer informiert Sie, wenn Antivirensoftware die Build-Leistung beeinträchtigen könnte. Dies kann passieren, wenn von Antivirensoftware wie Windows Defender die von Gradle verwendeten Verzeichnisse in Echtzeit gescannt werden. Build Analyzer empfiehlt eine Liste von Verzeichnissen, die vom aktiven Scannen ausgeschlossen werden sollen, und bietet nach Möglichkeit einen Link, um sie der Ausschlussliste des Windows Defender-Ordners hinzuzufügen.

Eclipse-Android-Entwicklungstools werden nicht mehr unterstützt

Android Studio Hedgehog und höher unterstützen das Importieren von Eclipse ADT-Projekten nicht. Sie können diese Projekte weiterhin öffnen, sie werden aber nicht mehr als Android-Projekte erkannt. Wenn Sie diese Art von Projekt importieren müssen, können Sie eine frühere Version von Android Studio verwenden. Wenn Ihr Projekt mit einer bestimmten Version von Android Studio nicht importiert werden kann, können Sie es mit einer noch früheren Version versuchen. Nachdem das Projekt mit einer früheren Version von Android Studio in ein Android-Projekt umgewandelt wurde, können Sie den AGP-Upgradeassistenten verwenden, um mit der neuesten Android Studio-Version an diesem Projekt zu arbeiten.

Firebase Test Lab-Geräte mit von Gradle verwalteten Geräten verwenden

Wenn Sie AGP 8.2.0-alpha03 oder höher verwenden, können Sie Ihre automatisierten instrumentierten Tests in großem Maßstab auf Firebase Test Lab-Geräten ausführen, wenn Sie Gradle-verwaltete Geräte verwenden. Mit Test Lab können Sie Ihre Tests gleichzeitig auf einer Vielzahl von physischen und virtuellen Android-Geräten ausführen. Diese Tests werden in Remote-Rechenzentren von Google durchgeführt. Dank der Unterstützung von Gradle-verwalteten Geräten (GMD) kann das Build-System jetzt Tests für diese Test Lab-Geräte basierend auf den Konfigurationen in den Gradle-Dateien Ihres Projekts vollständig verwalten.

Erste Schritte mit Gradle-verwalteten Firebase Test Lab-Geräten

In den folgenden Schritten wird beschrieben, wie Sie Firebase Test Lab-Geräte mit GMD verwenden. Beachten Sie, dass in diesen Schritten die Nutzeranmeldedaten über die gcloud CLI bereitgestellt werden. Dies gilt möglicherweise nicht für alle Entwicklungsumgebungen. Weitere Informationen dazu, welcher Authentifizierungsprozess für Ihre Anforderungen zu verwenden ist, finden Sie unter Funktionsweise von Standardanmeldedaten für Anwendungen.

  1. Rufen Sie die Firebase Console auf, um ein Firebase-Projekt zu erstellen. Klicken Sie auf Projekt hinzufügen und folgen Sie den Aufforderungen auf dem Bildschirm, um ein Projekt zu erstellen. Merken Sie sich Ihre Projekt-ID.

  2. Führen Sie die Schritte unter gcloud CLI installieren aus, um die Google Cloud CLI zu installieren.
  3. Konfigurieren Sie Ihre lokale Umgebung.
    1. Erstellen Sie eine Verknüpfung zu Ihrem Firebase-Projekt in gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. Autorisieren Sie die Verwendung Ihrer Nutzeranmeldedaten für den API-Zugriff. Wir empfehlen zur Autorisierung eine JSON-Datei für das Dienstkonto an Gradle. Dazu verwenden Sie DSL im Build-Script auf Modulebene:

      Kotlin

        firebaseTestLab {
    ...
    serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
  }

      Groovig

        firebaseTestLab {
    ...
    serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
  }

      Alternativ können Sie mit dem folgenden Terminalbefehl eine manuelle Autorisierung ausführen:

        gcloud auth application-default login

    3. Optional: Fügen Sie Ihr Firebase-Projekt als Kontingentprojekt hinzu. Dieser Schritt ist nur erforderlich, wenn Sie das kostenlose Kontingent für Test Lab überschreiten. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. Aktivieren Sie die erforderlichen APIs.

    Aktivieren Sie auf der Seite „API-Bibliothek“ der Google Developers Console die Cloud Testing API und die Cloud Tool Results API. Geben Sie dazu die Namen der APIs in das Suchfeld oben in der Console ein und klicken Sie dann auf der Übersichtsseite der einzelnen APIs auf API aktivieren.

  5. Android-Projekt konfigurieren

    1. Fügen Sie das Firebase Test Lab-Plug-in in das Build-Skript der obersten Ebene ein:

      Kotlin

        plugins {
    ...
    id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
  }

      Groovig

        plugins {
    ...
    id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
  }

    2. Aktivieren Sie benutzerdefinierte Gerätetypen in der Datei gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true

    3. Fügen Sie das Firebase Test Lab-Plug-in dem Build-Skript auf Modulebene hinzu:

      Kotlin

        plugins {
    ...
    id "com.google.firebase.testlab"
  }

      Groovig

        plugins {
    ...
    id 'com.google.firebase.testlab'
  }

    Tests auf einem von Gradle verwalteten Firebase Test Lab-Gerät erstellen und ausführen

    Sie können im Build-Skript auf Modulebene ein Firebase Test Lab-Gerät für Gradle angeben, das zum Testen Ihrer App verwendet wird. Im folgenden Codebeispiel wird ein Pixel 3 mit API-Level 30 als von Gradle verwaltetes Test Lab-Gerät namens ftlDevice erstellt. Der Block firebaseTestLab {} ist verfügbar, wenn Sie das Plug-in com.google.firebase.testlab auf Ihr Modul anwenden. Die mindestens unterstützte Version des Android Gradle-Plug-ins ist 8.2.0-alpha01.

    Kotlin

    firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    Groovig

    firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    Verwenden Sie den folgenden Befehl, um Ihre Tests mit den von Ihnen konfigurierten Gradle-verwalteten Test Lab-Geräten auszuführen. device-name ist der Name des Geräts, das Sie in Ihrem Gradle-Build-Skript konfiguriert haben, z. B. ftlDevice. BuildVariant ist die Build-Variante Ihrer App, die Sie testen möchten. Gradle führt keine parallelen Tests aus und unterstützt auch keine anderen Google Cloud CLI-Konfigurationen für Test Lab-Geräte.

    Unter Windows:

    gradlew device-nameBuildVariantAndroidTest

    Unter Linux oder macOS:

    ./gradlew device-nameBuildVariantAndroidTest

    Die Testausgabe enthält einen Pfad zu einer HTML-Datei, die den Testbericht enthält. Sie können die Testergebnisse auch zur weiteren Analyse in Android Studio importieren. Klicken Sie dazu in der IDE auf Ausführen > Testverlauf.

    Tests für eine Gerätegruppe erstellen und ausführen

    Wenn Sie Ihre Tests skalieren möchten, fügen Sie mehrere von Gradle verwaltete Firebase Test Lab-Geräte einer Gerätegruppe hinzu und führen Sie dann mit einem einzigen Befehl Tests auf allen aus. Angenommen, Sie haben mehrere Geräte folgendermaßen eingerichtet:

    firebaseTestLab {
  managedDevices {
    create("GalaxyS23Ultra") { ... }
    create("GalaxyZFlip3") { ... }
    create("GalaxyZFold3") { ... }
    create("GalaxyTabS2") { ... }
  }
}

    Verwende den groups {}-Block, um sie einer Gerätegruppe namens „samsungGalaxy“ hinzuzufügen:

    firebaseTestLab {
  managedDevices {...}
}

android {
  ...
  testOptions {
    managedDevices {
      groups {
        create("samsungGalaxy") {
          targetDevices.add(devices["GalaxyS23Ultra"])
          targetDevices.add(devices["GalaxyZFlip3"])
          targetDevices.add(devices["GalaxyZFold3"])
          targetDevices.add(devices["GalaxyTabS3"])
        }
      }
    }
  }
}

    Verwenden Sie den folgenden Befehl, um Tests auf allen Geräten in der Gerätegruppe auszuführen:

    Unter Windows:

    gradlew group-nameGroupBuildVariantAndroidTest

    Unter Linux oder macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest

    Testläufe mit intelligenter Fragmentierung optimieren

    Tests auf Gradle-verwalteten Test Lab-Geräten unterstützen jetzt intelligente Fragmentierung. Durch die intelligente Fragmentierung werden Ihre Tests automatisch auf Shards verteilt, sodass jeder Shard ungefähr zur gleichen Zeit ausgeführt wird. Dadurch wird der manuelle Zuweisungsaufwand und die gesamte Testlaufdauer reduziert. Bei der intelligenten Fragmentierung werden der Testverlauf oder Informationen darüber, wie lange die vorherige Ausführung von Tests gedauert hat, verwendet, um Tests optimal zu verteilen. Sie benötigen Version 0.0.1-alpha05 des Gradle-Plug-ins für Firebase Test Lab, um die intelligente Fragmentierung zu verwenden.

    Um die intelligente Fragmentierung zu aktivieren, geben Sie die Zeit an, die Tests innerhalb jedes Shards in Anspruch nehmen sollen. Sie sollten die Dauer der Ziel-Shard-Zeit auf mindestens fünf Minuten unter timeoutMinutes festlegen, um zu vermeiden, dass Shards abgebrochen werden, bevor die Tests beendet werden können.

    firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

    Weitere Informationen zu den neuen DSL-Optionen

    DSL für von Gradle verwaltete Firebase Test Lab-Geräte wurde aktualisiert

    Es gibt weitere DSL-Optionen, die Sie konfigurieren können, um Ihre Testläufe anzupassen oder von anderen Lösungen zu migrieren, die Sie möglicherweise bereits verwenden. Einige dieser Optionen werden im folgenden Code-Snippet beschrieben.

    firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       * 
       * Default to 0 for no sharding.
       */
      numUniformShards = 20

      /**
      * For smart sharding, the target length of time each shard should takes in
      * minutes. Maxes out at 50 shards for physical devices and 100 shards for
      * virtual devices.
      *
      * Only one of numUniformShards or targetedShardDurationMinutes can be set.
      *
      * Defaults to 0 for no smart sharding.
      */
      targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
    }
  }
}