Android Studio Hedgehog | 2023.1.1 (Nov. 2023)

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

IntelliJ IDEA 2023.1-Plattformupdate

Android Studio Hedgehog enthält die Updates für IntelliJ IDEA 2023.1, durch die in der IDE von Studio. Details zu den Änderungen finden Sie in der IntelliJ IDEA 2023.1 – Versionshinweise.

Android Vitals in Statistiken zur App-Qualität analysieren

App Quality Insights beinhaltet jetzt Folgendes: Android Vitals-Daten für einen einfacheren Zugriff von Google Play erheben und die Nutzererfahrung verbessern. Verwenden Sie Android Vitals, um Probleme im Zusammenhang mit der App-Stabilität zu beheben und die App zu verbessern die Qualität deiner App bei Google Play.

Du kannst Android Vitals-Probleme ansehen, filtern und vom Stacktrace zu aus dem Tool-Fenster App Quality Insights aus. Folgen Sie einfach diese Schritte:

  1. Melde dich über das Profilsymbol in Android Studio in deinem Entwicklerkonto an mit das Ende der Symbolleiste.
  2. Öffnen Sie App Quality Insights, indem Sie auf das Tool-Fenster in auf Android Studio oder auf Ansicht > Tool-Fenster > Statistiken zur App-Qualität.
  3. Klicken Sie unter App Quality Insights auf den Tab Android Vitals.

Unterschiedliche Zahlen in Android Vitals und Crashlytics

Android Vitals und Crashlytics melden möglicherweise unterschiedliche Werte für die Anzahl der Nutzer und Ereignisse, die mit demselben Absturz verknüpft sind. Diese Abweichungen weil Play und Crashlytics Abstürze zu unterschiedlichen Zeiten und für unterschiedlichen Nutzenden. Hier sind einige Gründe, warum Play und Crashlytics Anzahl kann abweichen:

  • Play erkennt Abstürze ab dem Startzeitpunkt, Crashlytics hingegen schon. Abstürze nach der Initialisierung des Crashlytics SDK auftreten.
  • Wenn ein Nutzer die Absturzberichte beim Erhalt eines neuen Smartphones deaktiviert, werden diese Abstürze nicht an Google Play gemeldet werden; Crashlytics erkennt Abstürze jedoch anhand der Datenschutzerklärung von Google.

Neuer Power Profiler

Ab Android Studio Hedgehog zeigt der Power Profiler den Stromverbrauch an auf Geräten. Sie können diese neuen Daten im On Device Power Rails Monitor (ODPM) anzeigen. Das ODPM segmentiert die Daten nach Subsystemen, die als Power Rails bezeichnet werden. Weitere Informationen finden Sie unter Profilierbare Stromschienen. finden Sie eine Liste der unterstützten Subsysteme.

System-Trace Daten zum Energieverbrauch aufzeichnen und anzeigen. Sie ist Teil des CPU-Profilers. Diese Daten helfen Ihnen, Leistung visuell in Beziehung zu setzen, Verbrauch des Geräts mit den Aktionen in Ihrer App. Power Profiler ermöglicht die Visualisierung dieser Daten.

Der neue Power Profiler

Erstelle auf einem Pixel 6 oder höher einen System-Trace, um die Daten vom neuen Power Profiler zu sehen Gerät:

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

Der neue App-Link-Assistent bietet einen umfassenden Überblick über die Deeplinks die Sie in Ihrer App eingerichtet haben. Assistant zeigt alle vorhandenen Deeplinks im AndroidManifest.xml-Datei enthält, wird überprüft, ob die Konfiguration für diese tiefen Links korrekt ist und eine schnelle Möglichkeit bietet, Fehlkonfigurationen.

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

Live-Bearbeitung hat die Tastenkombination für den manuellen Modus aktualisiert

Live-Bearbeitung in Android Studio Hedgehog enthält eine neue Tastenkombination für den manuellen Modus (Manuell senden): Strg + \ bzw. Befehlstaste + \ für macOS. Der manuelle Modus ist hilfreich in denen Sie genau steuern möchten, wann Updates installiert werden, für die laufende Anwendung bereitgestellt. Wenn Sie zum Beispiel eine große in einer Datei geändert werden und nicht möchten, dass sich ein Zwischenstatus im . Sie können zwischen Manuell übertragen und Beim Speichern manuell senden wählen. in den Live Edit-Einstellungen oder über die entsprechende UI-Anzeige. Weitere Informationen erhalten Sie unter Live-Bearbeitung für Jetpack Schreiben:

Multipreview-Vorlagen erstellen

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ führt neue Multipreview API Vorlagen: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark, und @PreviewDynamicColors, sodass Sie mit einer einzigen Anmerkung Vorschau der Editor-UI in gängigen Szenarien ansehen.

In Android Studio Hedgehog wurde der Galeriemodus Mit der Funktion „Vorschau erstellen“ können Sie sich jeweils auf eine Vorschau konzentrieren Ressourcen beim Rendern einsparen. Wir empfehlen, den Galeriemodus zu verwenden, wenn Sie die Benutzeroberfläche Ihrer App iterieren und zu anderen Modi wechseln müssen, z. B. „Raster“ oder „Liste“, wenn Sie UI-Varianten sehen möchten.

Statusinformationen im Debugger erstellen

Wenn Teile der Benutzeroberfläche zum Schreiben unerwartet neu zusammengesetzt werden, ist das manchmal schwierig um zu verstehen, warum. Wenn Sie nun einen Haltepunkt für eine zusammensetzbare Funktion festlegen, Debugger listet die Parameter der zusammensetzbaren Funktion und ihre So können Sie leichter erkennen, welche Änderungen Neuzusammensetzung. Wenn Sie beispielsweise bei einer zusammensetzbaren Funktion eine Pause machen, kann der Debugger welche Parameter sich geändert haben, oder unverändert geblieben sind, damit du die Ursache der Neuzusammensetzung effizienter untersuchen kannst.

Gerätespiegelung

Sie können Ihr physisches Gerät jetzt im Fenster Laufende Geräte in Android Studio Wenn du den Bildschirm deines Geräts direkt in Android Studio streamst, kannst du häufige Aktionen ausführen, z. B. Apps starten und mit ihnen interagieren, das Display drehen, das Smartphone aus- und wieder aufklappen, die Lautstärke ändern direkt in der Studio-IDE.

Die Gerätespiegelung ist immer verfügbar, wenn Geräte mit dem Computer mit aktiviertem USB- oder WLAN-Debugging. Sie können die die Spiegelung über das Fenster Laufende Geräte oder die Geräte-Manager (Ansicht > Tool-Fenster > Geräte-Manager). Sie können auch Festlegen, wann die Gerätespiegelung in den Einstellungen aktiviert ist (Einstellungen > Tools > Gerätespiegelung).

Geräte-UI ausführen

Bekannte Probleme

Einige Geräte sind möglicherweise nicht in der Lage, mit einer für die Unterstützung erforderlichen Bitrate zu codieren Gerätespiegelung. In diesen Situationen wird möglicherweise ein Fehler in der Spalte Wird ausgeführt Geräte-Fenster und Protokolle ähnlich dem unten gezeigten Fenster.

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

Android Studio kann basierend auf den Einstellungen für die Gerätespiegelung automatisch Gerätespiegelung für alle verbundenen und gekoppelten Geräte. Dies kann zu Offenlegung von Informationen für Geräte, die mit dem Befehl adb tcpip verbunden sind da die Spiegelungsinformationen und Befehle über eine Kanal. Außerdem nutzt Android Studio einen unverschlüsselten Kanal für die Kommunikation mit dem ADB-Server, damit die Spiegelung von Informationen von anderen Nutzern abgefangen werden kann. auf Ihrem Hostcomputer ausführen.

Hardware-Eingangsweiterleitung

Sie können jetzt die transparente Weiterleitung der Hardwareeingaben Ihrer Workstation aktivieren. wie Maus und Tastatur, mit einem verbundenen physischen und virtuellen Gerät verbinden. Bis Aktivieren Sie die transparente Weiterleitung und klicken Sie auf Hardware-Eingabe. für das Zielgerät im Fenster Running Devices (Aktive Geräte) aus.

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

Sie können jetzt ein virtuelles Android-Gerät (Android Virtual Device, AVD) starten oder mit dem Spiegeln eines eines physischen Geräts aus, indem Sie im Fenster Running Devices (Laufende Geräte) auf das Symbol +-Symbol und wähle ein Gerät aus. Um das AVD oder die Spiegelung eines physischen schließen Sie den Geräte-Tab.

Dropdown-Menü Gerät unter Laufende Geräte

Integrierter Layout-Inspektor

Ab Android Studio Hedgehog Canary 2 können Sie den Layout Inspector direkt im Fenster mit dem Tool Laufgeräte Diese experimentelle Funktion spart und können Ihren UI-Debugging-Workflow in einem einzigen Tool-Fenster organisieren. In Im eingebetteten Modus können Sie eine Ansichtshierarchie anzeigen lassen und die Eigenschaften der einzelnen Layout Inspector-Funktionen ansehen und darauf zugreifen. So greifen Sie auf den gesamten Satz zu: müssen Sie den Layout Inspector trotzdem 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, 3D-Modus ist nur verfügbar in Snapshots.

Wenn Sie uns bei der Verbesserung des eingebetteten Layout Inspectors unterstützen möchten, senden Sie uns Feedback.

Neue Verbesserungen an der Benutzeroberfläche

Die neue UI für Android Studio verleiht Studio ein moderneres, übersichtlicheres Erscheinungsbild IDE. Wir haben uns Ihr Feedback zu Herzen genommen und Probleme in Bezug auf die die folgenden Funktionen in Android Studio Hedgehog:

  • Kompaktmodus
  • Unterstützung der vertikalen oder horizontalen Teilung
  • Projekttabs für macOS
  • Korrekturen des Modus ohne Ablenkung
  • Erweiterte Einstellungen, damit Aktionen des Tool-Fensters immer angezeigt werden

Updates des SDK-Upgradeassistenten

Der SDK Upgrade Assistant bietet eine Schritt-für-Schritt-Assistenten, der Sie bei der targetSdkVersion Upgrades. Das sind die Updates für den SDK-Upgrade-Assistenten in Android Studio Igel:

  • Wichtige Änderungen beim Upgrade auf Android 14 ansehen
  • Relevanzfilter hinzugefügt, sodass einige unnötige Schritte entfernt werden
  • Für bestimmte Änderungen genau festlegen, an welcher Stelle im Code sie eingefügt werden müssen gemacht

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

Du kannst jetzt die IDE-Optimierung für das Ziel-API-Level des Geräts deaktivieren. Von Standardmäßig reduziert Android Studio die Build-Dauer insgesamt, indem die Dexing-Funktion angepasst wird. für die API-Ebene des Zielgeräts, auf dem die Bereitstellung erfolgt. So schalten Sie diese Funktion ein: klicken Sie auf Datei > Einstellungen > Experimentell (Android Studio > Einstellungen > Experimentell unter macOS) und entfernen Sie das Häkchen bei Build für Ziel optimieren Nur API-Level des Geräts Wenn Sie diese Build-Optimierung deaktivieren, die Build-Dauer erhöhen.

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

Build Analyzer informiert Sie, wenn sich Antivirensoftware möglicherweise auf Ihren Build auswirkt die Leistung. Dies kann passieren, wenn Antivirensoftware wie Windows Defender von Gradle verwendete Verzeichnisse in Echtzeit. Build-Analysetool empfiehlt eine Liste der Verzeichnisse, die vom aktiven Scan ausgeschlossen werden sollen, und wenn möglich, wird ein Link zum Hinzufügen zu Windows Defender angezeigt. Ordner-Ausschlussliste.

Eclipse-Android-Entwicklungstool-Projekte werden nicht mehr unterstützt

Android Studio Hedgehog und höher unterstützen den Import von Eclipse-ADT nicht Projekten. Sie können diese Projekte noch öffnen, sie sind aber nicht mehr verfügbar die als Android-Projekte erkannt werden. Wenn Sie diese Art von Projekt importieren müssen Sie können eine frühere Version von Android Studio verwenden. Wenn eine bestimmte Android-Version Ihr Projekt kann nicht in Studio importiert werden. Sie können es mit einer gleichmäßigen früheren Version. Sobald das Projekt mithilfe eines einer früheren Version von Android Studio, können Sie mit dem AGP-Upgrade-Assistenten die aktuelle Version von Android Studio verwenden.

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 umfangreiche Tests durchführen, Firebase Test Lab-Geräte, wenn mit von Gradle verwalteten Geräten. Test Lab können Sie Tests gleichzeitig auf einer Vielzahl von Android-Geräten durchführen, physisch und virtuell. Diese Tests werden in Remote-Rechenzentren von Google durchgeführt. Mit Unterstützung von Gradle-verwalteten Geräten (GMD) bietet, kann das Build-System Tests mit diesen Test Lab-Geräten basierend auf den Konfigurationen in Ihrem Gradle-Dateien des Projekts.

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

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

  1. Rufen Sie zum Erstellen eines Firebase-Projekts die Firebase Console. Klicken Sie auf Projekt hinzufügen und folgen Sie der Anleitung auf dem Bildschirm, um ein Projekt zu erstellen. Merken Sie sich Ihre Projekt-ID.

    <ph type="x-smartling-placeholder">
  2. So installieren Sie die Google Cloud CLI: Installieren Sie die gcloud CLI.
  3. Lokale Umgebung konfigurieren
    1. Stellen Sie in gcloud eine Verknüpfung zu Ihrem Firebase-Projekt her: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. Autorisieren Sie die Verwendung Ihrer Nutzeranmeldedaten für den API-Zugriff. Wir empfehlen, durch Übergeben einer JSON-Datei des Dienstkontos mithilfe der DSL im Build-Skript auf Modulebene:

      Kotlin

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

      Cool

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

      Alternativ können Sie die Autorisierung über das folgende Terminal manuell vornehmen Befehl:

        gcloud auth application-default login

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

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      <ph type="x-smartling-placeholder">

  4. Erforderliche APIs aktivieren

    Im Seite "API-Bibliothek" der Google Developers Console, aktivieren Sie die Cloud Testing API und Cloud Tool Results API indem Sie diese API-Namen in das Suchfeld oben in der Konsole eingeben. Klicken Sie dann auf der Übersichtsseite der einzelnen APIs auf API aktivieren.

  5. Konfigurieren Sie Ihr Android-Projekt.

    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
  }

      Cool

        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 in das Build-Skript auf Modulebene ein:

      Kotlin

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

      Cool

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

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

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

    Kotlin

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

    Cool

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

    Um Ihre Tests mit den von Gradle verwalteten Test Lab-Geräten auszuführen, die Sie konfiguriert haben, verwenden Sie mit dem folgenden Befehl. device-name ist der Name des Geräts, in dem Sie das Gerät konfiguriert haben. Ihr Gradle-Build-Skript, z. B. ftlDevice, und BuildVariant ist der Build Variante Ihrer App, die Sie testen möchten. Beachten Sie, dass Gradle keine Tests in oder andere Google Cloud CLI-Konfigurationen für Test Lab-Geräte unterstützen.

    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. Ich können Testergebnisse auch zur weiteren Analyse in Android Studio importieren, auf Ausführen > Testverlauf in der IDE.

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

    Fügen Sie zum Skalieren Ihrer Tests mehrere von Gradle verwaltete Firebase Test Lab-Geräte zu und führen dann mit einem einzigen Befehl Tests für alle Geräte durch. Sag mal mehrere Geräte wie folgt eingerichtet haben:

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

    Wenn du sie einer Gerätegruppe namens „samsungGalaxy“ hinzufügen möchtest, verwende den groups {}-Block:

    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

    Beim Testen auf von Gradle verwalteten Test Lab-Geräten wird jetzt intelligente Fragmentierung unterstützt. Smart Bei der Fragmentierung werden die Tests automatisch so auf die Shards verteilt, dass jeder Shard läuft ungefähr gleich lang, wodurch der manuelle Zuweisungsaufwand Gesamtdauer des Testlaufs. Bei der intelligenten Fragmentierung werden dein Testverlauf oder deine Informationen verwendet wie lange es früher gedauert hat, Tests durchzuführen. den optimalen Weg finden. Sie benötigen die Version 0.0.1-alpha05 des Gradle-Plug-ins. für Firebase Test Lab die intelligente Fragmentierung verwendet.

    Geben Sie zum Aktivieren der intelligenten Fragmentierung die Dauer der Tests in jedem Shard an die Sie benötigen. Du solltest die Dauer des Ziel-Shards auf mindestens fünf festlegen Minuten unter timeoutMinutes, um die Situation zu vermeiden, dass Shards vor Abschluss der Tests abgebrochen werden.

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

    Weitere Informationen zu den neuen DSL-Optionen

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

    Es gibt weitere DSL-Optionen, die Sie konfigurieren können, um Ihre Testläufe anzupassen, oder Lösungen zu migrieren, die Sie möglicherweise bereits nutzen. Sehen Sie sich einige dieser Optionen an. enthalten, wie 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
    }
  }
}