Android Studio Hedgehog | 1.1023.2023 (listopad 2023 r.)

Oto nowe funkcje w Android Studio Hedgehog.

Aktualizacja platformy IntelliJ IDEA 2023.1

Android Studio Hedgehog zawiera aktualizacje IntelliJ IDEA 2023.1, które poprawiają działanie IDE Studio. Szczegóły zmian znajdziesz w informacjach o wersji IntelliJ IDEA 2023.1.

Analizowanie Android Vitals w statystykach jakości aplikacji

Statystyki dotyczące jakości aplikacji obejmują teraz dane z Android Vitals, dzięki czemu masz łatwiejszy dostęp do podstawowych danych zbieranych przez Google Play i możesz zwiększyć wygodę użytkowników. Za pomocą Android Vitals możesz rozwiązywać problemy ze stabilnością aplikacji i poprawiać jej jakość w Google Play.

W oknie narzędzia App Quality Insights możesz wyświetlać problemy z Android Vitals, filtrować je i przechodzić ze zrzutu stosu do kodowania. Aby rozpocząć, wykonaj te czynności:

  1. Zaloguj się na konto dewelopera w Android Studio, klikając ikonę profilu na końcu paska narzędzi.
  2. Otwórz statystyki dotyczące jakości aplikacji, klikając okno narzędzia w Android Studio lub Widok > Okna narzędzi > Statystyki dotyczące jakości aplikacji.
  3. Kliknij kartę Android Vitals w sekcji Statystyki jakości aplikacji.

Różnice między Android Vitals i Crashlytics

Pamiętaj, że Android Vitals i Crashlytics mogą podawać różne wartości liczby użytkowników i zdarzeń powiązanych z tą samą awarią. Dzieje się tak, ponieważ Play i Crashlytics mogą wychwytywać awarie w różnych momentach i u różnych użytkowników. Oto kilka powodów, dla których wartości w Play i Crashlytics mogą się różnić:

  • Google Play wychwytuje awarie już w momencie uruchomienia, natomiast Crashlytics wykrywa awarie, które mają miejsce po zainicjowaniu pakietu SDK Crashlytics.
  • Jeśli użytkownik zrezygnuje z raportów o awariach po zmianie telefonu na nowy telefon, nie będą one przesyłane do Google Play, ale Crashlytics wykryje je zgodnie z własną polityką prywatności aplikacji.

Nowy program Power Profiler

Począwszy od Android Studio Hedgehog, program Power Profiler pokazuje zużycie energii przez urządzenia. Nowe dane możesz wyświetlić na ekranie On Device Power Rails Monitor (ODPM). ODPM segmentuje dane według podsystemów zwanych Power Rails. Listę obsługiwanych podsystemów znajdziesz w sekcji Profilerowe tablice zasilające.

Śledzenie systemu rejestruje i wyświetla dane zużycia energii. Jest częścią narzędzia do profilowania procesora. Te dane pozwalają graficznie skorelować zużycie energii przez urządzenie z działaniami podejmowanymi w aplikacji. Program Power Profiler umożliwia wizualizację tych danych.

Nowy program Power Profiler

Aby wyświetlić dane z nowego programu Power Profiler, wykonaj śledzenie systemu na urządzeniu Pixel 6 lub nowszym:

  1. Wybierz Widok > Okna narzędzi > Profiler.
  2. Kliknij dowolne miejsce na osi czasu procesora, aby otworzyć program profilujący CPU i uruchomić śledzenie systemu.

Nowy Asystent linków aplikacji zapewnia szczegółowe informacje o precyzyjnych linkach skonfigurowanych w Twojej aplikacji. Asystent wyświetla wszystkie istniejące precyzyjne linki w pliku AndroidManifest.xml aplikacji, sprawdza, czy ich konfiguracja jest prawidłowa, i umożliwia szybkie naprawianie błędów konfiguracji.

Aby otworzyć Asystenta linków aplikacji, w Android Studio kliknij Narzędzia > Asystent linków aplikacji. Więcej informacji o linkach aplikacji znajdziesz w artykule Dodawanie linków aplikacji na Androida.

Aktualizacja na żywo – zaktualizowany skrót do trybu ręcznego

Edycja na żywo w Studio Hedgehog na Androidzie zawiera nowy skrót do trybu ręcznego (Push ręcznie): Control+\ (Command+\ w systemie macOS). Tryb ręczny jest przydatny w sytuacjach, gdy chcesz mieć dokładną kontrolę nad tym, kiedy aktualizacje są wdrażane w działającej aplikacji. Jeśli np. wprowadzasz w pliku dużą zmianę na dużą skalę i nie chcesz, aby żaden stan pośredni był odzwierciedlany na urządzeniu. W ustawieniach edycji na żywo możesz wybrać opcję Przekaż ręcznie lub Wyślij ręcznie podczas zapisywania lub korzystając ze wskaźnika interfejsu edycji na żywo. Więcej informacji znajdziesz w klipie wideo w artykule Live Edit for Jetpack Compose ( w języku angielskim).

Tworzenie szablonów podglądu z wieloma podglądami

androidx.compose.ui:ui-tooling-preview w wersji 1.6.0-alpha01+ zawiera nowe szablony interfejsu Multipreview API: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark i @PreviewDynamicColors, dzięki którym za pomocą jednej adnotacji możesz w typowych scenariuszach wyświetlać podgląd interfejsu tworzenia wiadomości.

W Android Studio Hedgehog wprowadziliśmy nowy tryb galerii w podglądzie tworzenia wiadomości, który pozwala skupić się na jednym podglądzie naraz i zaoszczędzić zasoby związane z renderowaniem. Zalecamy korzystanie z trybu galerii, gdy chcesz iterować interfejs aplikacji, i przełączanie się na inne tryby, np. Siatka lub Lista, gdy chcesz zobaczyć warianty interfejsu.

Tworzenie informacji o stanie w debugerze

Gdy elementy interfejsu tworzenia wiadomości nieoczekiwanie zmieniają się, czasem trudno zrozumieć, dlaczego tak się dzieje. Teraz podczas ustawiania punktu przerwania dla funkcji kompozycyjnej debugger wyświetla parametry funkcji kompozycyjnej i ich stan, co ułatwia identyfikowanie zmian, które mogły spowodować zmianę kompozycji. Jeśli na przykład wstrzymasz działanie funkcji kompozycyjnej, debuger może dokładnie określić, które parametry zostały zmienione, a które pozostały bez zmian. Dzięki temu możesz skuteczniej zbadać przyczynę zmiany kompozycji.

Dublowanie urządzenia

Odbicie lustrzane urządzenia fizycznego jest teraz możliwe w oknie Uruchomione urządzenia w Android Studio. Dzięki strumieniowemu przesyłaniu wyświetlacza urządzenia bezpośrednio do Android Studio możesz wykonywać typowe działania, takie jak uruchamianie aplikacji i korzystanie z nich, obracanie ekranu, składanie i rozkładanie telefonu, zmienianie głośności oraz wykonywanie innych działań bezpośrednio w interfejsie IDE Studio.

Powielanie urządzeń jest zawsze dostępne, gdy do komputera podłączone są urządzenia, na których włączono debugowanie USB lub debugowanie bezprzewodowe. Powielanie możesz uruchomić i zatrzymać w oknie Uruchomione urządzenia lub w Menedżerze urządzeń (Widok > Narzędzia > Okna > Menedżer urządzeń). Możesz też dostosować czas włączenia odbicia lustrzanego urządzenia w ustawieniach (Ustawienia > Narzędzia > Duplikowanie urządzenia).

Interfejs uruchomionych urządzeń

Znane problemy

Niektóre urządzenia mogą nie mieć możliwości kodowania z szybkością transmisji wystarczającej do powielania treści. W takiej sytuacji w oknie Uruchomione urządzenia może pojawić się błąd oraz dzienniki podobne do pokazanego poniżej.

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

Informacje na temat ochrony prywatności

Na podstawie ustawień powielania urządzeń Android Studio może automatycznie rozpocząć tworzenie odbicia lustrzanego urządzenia na dowolnych połączonych i sparowanych urządzeniach. Może to spowodować ujawnienie informacji o urządzeniach połączonych za pomocą polecenia adb tcpip, ponieważ powielane informacje i polecenia są przekazywane przez niezaszyfrowany kanał. Dodatkowo Android Studio do komunikacji z serwerem adb używa nieszyfrowanego kanału, dzięki czemu informacje powielone mogą zostać przechwycone przez innych użytkowników na hoście.

Przekazywanie danych wejściowych sprzętowych

Możesz teraz włączyć przejrzyste przekazywanie danych wejściowych sprzętowych stacji roboczej, takich jak mysz i klawiatura, do podłączonego urządzenia fizycznego i wirtualnego. Aby włączyć przejrzyste przekazywanie dalej, kliknij Dane wejściowe sprzętowe przy urządzeniu docelowym w oknie Uruchomione urządzenia.

Zarządzanie urządzeniami bezpośrednio w oknie Uruchomione urządzenia

Teraz możesz uruchomić urządzenie wirtualne z Androidem (AVD) lub utworzyć odbicie lustrzane urządzenia fizycznego bezpośrednio w oknie Uruchomione urządzenia, klikając ikonę + i wybierając urządzenie. Aby zatrzymać AVD lub powielanie treści z urządzenia fizycznego, zamknij kartę urządzenia.

Menu urządzeń z listy Uruchomione urządzenia

Inspektor układu umieszczonego

Począwszy od Androida Studio Hedgehog Canary 2, możesz uruchomić Inspektora układu bezpośrednio w oknie narzędzia Uruchomione urządzenia. Ta eksperymentalna funkcja oszczędza miejsce na ekranie i pomaga uporządkować przepływ pracy debugowania UI w jednym oknie narzędzia. W trybie umieszczonym możesz wyświetlać hierarchię widoków, sprawdzać właściwości poszczególnych widoków i korzystać z innych popularnych funkcji Inspektora układu. Aby uzyskać dostęp do wszystkich opcji, musisz uruchomić Inspektor układu w samodzielnym oknie (Plik > Ustawienia > Eksperymentalny > Inspektor układu (Windows) lub Android Studio > Ustawienia > Eksperymentalny > Inspektor układu w systemie macOS).

Ograniczeniem wbudowanego Inspektora układu jest to, że tryb 3D jest dostępny tylko w przypadku zrzutów.

Aby pomóc nam w udoskonaleniu wbudowanego Inspektora układu, prześlij nam opinię.

Nowe ulepszenia interfejsu

Nowy interfejs w Android Studio to bardziej nowoczesny i bardziej przejrzysty wygląd i styl IDE Studio. Wysłuchaliśmy Waszych opinii i naprawiliśmy problemy związane z tymi funkcjami w Android Studio Hedgehog:

  • Tryb kompaktowy
  • Obsługa podziału w pionie lub w poziomie.
  • Karty projektu w systemie macOS
  • Poprawki w trybie nie rozpraszającym uwagi
  • Ustawienia zaawansowane dotyczące zawsze pokazywania działań w oknie narzędzi

Aktualizacje Asystenta aktualizacji pakietu SDK

Asystent uaktualniania SDK udostępnia szczegółowe instrukcje umożliwiające przejście na targetSdkVersion. Oto aktualizacje Asystenta uaktualniania pakietu SDK w Android Studio w Hedgehog:

  • Zobacz niezbędne zmiany związane z przejściem na Androida 14
  • Dodanie filtrów trafności w celu usunięcia niektórych niepotrzebnych kroków
  • W przypadku niektórych zmian możesz dokładnie wskazać miejsce w kodzie, w którym należy je wprowadzić

Wyłącz optymalizację kompilacji tylko dla docelowego poziomu interfejsu API

Możesz teraz wyłączyć optymalizację IDE na poziomie interfejsu API urządzenia docelowego. Domyślnie Android Studio skraca ogólny czas kompilacji, dostosowując proces dexing do poziomu interfejsu API urządzenia docelowego. Aby wyłączyć tę funkcję, wybierz Plik > Ustawienia > Eksperymentalne (Android Studio > Ustawienia > Eksperymentalne w systemie macOS) i odznacz opcję Optymalizuj kompilację tylko pod kątem interfejsu API urządzenia docelowego. Pamiętaj, że wyłączenie optymalizacji kompilacji może wydłużyć czas kompilacji.

[Tylko w systemie Windows] Zminimalizuj wpływ oprogramowania antywirusowego na szybkość kompilacji.

Analizator kompilacji informuje, czy oprogramowanie antywirusowe może wpływać na wydajność kompilacji. Może się tak zdarzyć, jeśli oprogramowanie antywirusowe, takie jak Windows Defender, skanuje w czasie rzeczywistym katalogi używane przez Gradle. Analizator kompilacji zaleca listę katalogów do wykluczenia z aktywnego skanowania oraz, jeśli to możliwe, udostępnia link umożliwiający dodanie ich do listy wykluczeń folderów usługi Windows Defender.

Projekty Eclipse Android Development Tool nie są już obsługiwane

Android Studio Hedgehog i nowsze wersje nie obsługują importowania projektów Eclipse ADT. Nadal możesz otwierać te projekty, ale nie są już one rozpoznawane jako projekty Androida. Jeśli chcesz zaimportować projekt tego typu, możesz użyć wcześniejszej wersji Android Studio. Jeśli konkretna wersja Androida Studio nie pozwala na zaimportowanie projektu, możesz wypróbować ją jeszcze raz. Po przekształceniu projektu w projekt na Androida we wcześniejszej wersji Android Studio możesz korzystać z Asystenta uaktualniania AGP, aby pracować w tym projekcie przy użyciu najnowszej wersji Androida Studio.

Używanie urządzeń z Laboratorium Firebase w połączeniu z urządzeniami zarządzanymi przez Gradle

Jeśli korzystasz z AGP w wersji 8.2.0–alfa03 lub nowszej, możesz przeprowadzać zautomatyzowane testy instrumentalne na dużą skalę na urządzeniach w Laboratorium Firebase, gdy używasz urządzeń zarządzanych przez Gradle. Laboratorium pozwala jednocześnie przeprowadzać testy na wielu różnych urządzeniach z Androidem – zarówno fizycznych, jak i wirtualnych. Te testy są przeprowadzane w odległych centrach danych Google. Dzięki obsłudze urządzeń zarządzanych przez Gradle (GMD) system kompilacji może teraz w pełni zarządzać przeprowadzanymi testami na urządzeniach z Laboratorium na podstawie konfiguracji w plikach Gradle projektu.

Pierwsze kroki z urządzeniami w Laboratorium Firebase zarządzanym przez Gradle

Poniżej znajdziesz instrukcje, jak zacząć korzystać z urządzeń w Laboratorium Firebase z GMD. Pamiętaj, że do podania danych logowania użytkownika musisz użyć interfejsu wiersza poleceń gcloud. Może to nie mieć zastosowania we wszystkich środowiskach programistycznych. Więcej informacji o procesie uwierzytelniania, który należy zastosować do Twoich potrzeb, znajdziesz w artykule Jak działają domyślne dane logowania aplikacji.

  1. Aby utworzyć projekt Firebase, otwórz konsolę Firebase. Aby utworzyć projekt, kliknij Dodaj projekt i postępuj zgodnie z instrukcjami wyświetlanymi na ekranie. Zapamiętaj identyfikator projektu.

  2. Aby zainstalować Google Cloud CLI, wykonaj czynności opisane w artykule Instalowanie interfejsu wiersza poleceń gcloud.
  3. Skonfiguruj środowisko lokalne.
    1. Połącz z projektem Firebase w gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. Autoryzuj użycie danych logowania użytkownika do uzyskiwania dostępu do interfejsu API. Zalecamy autoryzację przez przekazanie do Gradle pliku JSON konta usługi za pomocą DSL w skrypcie kompilacji na poziomie modułu:

      Kotlin

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

      Odlotowy

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

      Możesz też autoryzować je ręcznie, korzystając z tego polecenia w terminalu:

        gcloud auth application-default login

    3. Opcjonalnie: dodaj projekt Firebase jako projekt limitu. Ten krok jest wymagany tylko wtedy, gdy przekroczysz bezpłatny limit Laboratorium. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. Włącz wymagane interfejsy API.

    Na stronie biblioteki interfejsów API w Google Developers Console włącz interfejsy Cloud Testing API i Cloud Tool Results API, wpisując te nazwy w polu wyszukiwania u góry konsoli, a potem klikając Włącz API na stronie z omówieniem danego interfejsu.

  5. Skonfiguruj projekt na Androida.

    1. Dodaj wtyczkę Laboratorium Firebase do skryptu kompilacji najwyższego poziomu:

      Kotlin

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

      Odlotowy

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

    2. Włącz niestandardowe typy urządzeń w pliku gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true

    3. Dodaj wtyczkę Laboratorium Firebase do skryptu kompilacji na poziomie modułu:

      Kotlin

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

      Odlotowy

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

    Tworzenie i przeprowadzanie testów na zarządzanym przez Gradle urządzeniu Laboratorium Firebase

    W skrypcie kompilacji na poziomie modułu możesz wskazać urządzenie Laboratorium Firebase do testowania aplikacji Gradle. Poniższy przykładowy kod tworzy urządzenie Pixel 3 z interfejsem API na poziomie 30 jako zarządzane przez Gradle urządzenie o nazwie ftlDevice. Blok firebaseTestLab {} jest dostępny po zastosowaniu wtyczki com.google.firebase.testlab do modułu. Najniższa obsługiwana wersja wtyczki Androida do obsługi Gradle to 8.2.0-alfa01.

    Kotlin

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

    Odlotowy

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

    Aby uruchomić testy za pomocą skonfigurowanych przez Ciebie urządzeń w Laboratorium zarządzanych przez Gradle, użyj tego polecenia. device-name to nazwa urządzenia skonfigurowanego w skrypcie kompilacji Gradle, np. ftlDevice, a BuildVariant to wariant kompilacji aplikacji, którą chcesz przetestować. Pamiętaj, że Gradle nie uruchamia testów równolegle ani nie obsługuje innych konfiguracji interfejsu wiersza poleceń Google Cloud dla urządzeń w Laboratorium.

    Windows:

    gradlew device-nameBuildVariantAndroidTest

    W systemie Linux lub macOS:

    ./gradlew device-nameBuildVariantAndroidTest

    Dane wyjściowe testowe zawierają ścieżkę do pliku HTML, który zawiera raport testowy. Wyniki testu możesz też zaimportować do Android Studio w celu dalszej analizy. Aby to zrobić, w IDE kliknij Uruchom > Historia testów.

    Tworzenie i przeprowadzanie testów na grupie urządzeń

    Aby skalować testy, dodaj wiele urządzeń w Laboratorium Firebase zarządzanych przez Gradle do grupy urządzeń, a następnie uruchom testy na wszystkich urządzeniach za pomocą jednego polecenia. Załóżmy, że masz wiele urządzeń skonfigurowanych w ten sposób:

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

    Aby dodać je do grupy urządzeń o nazwie samsungGalaxy, użyj bloku groups {}:

    firebaseTestLab {
  managedDevices {...}
}

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

    Aby przeprowadzić testy na wszystkich urządzeniach w grupie urządzeń, użyj tego polecenia:

    Windows:

    gradlew group-nameGroupBuildVariantAndroidTest

    W systemie Linux lub macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest

    Optymalizowanie testów dzięki inteligentnemu fragmentowaniu

    Testowanie na urządzeniach z Laboratorium zarządzanych przez Gradle obsługuje teraz inteligentne fragmentowanie. Inteligentne fragmentowanie automatycznie rozdziela testy między fragmenty, tak aby każdy fragment działał mniej więcej w tym samym czasie, co zmniejsza ręczne przydzielanie i ogólny czas trwania testu. Inteligentne fragmentowanie wykorzystuje historię testów lub informacje o czasie trwania poprzednich testów, aby rozłożyć testy w optymalny sposób. Pamiętaj, że aby korzystać z inteligentnego fragmentowania, potrzebujesz wtyczki Gradle w wersji 0.0.1-alfa05 dla Laboratorium Firebase.

    Aby włączyć inteligentne fragmentowanie, określ czas trwania testów w każdym fragmencie. Ustaw czas trwania fragmentu docelowego na co najmniej 5 minut krócej niż w przypadku ustawienia timeoutMinutes, aby uniknąć sytuacji, w której fragmenty są anulowane przed zakończeniem testów.

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

    Aby dowiedzieć się więcej, poczytaj o nowych opcjach DSL.

    Zaktualizowano DSL dla urządzeń w Laboratorium Firebase zarządzanych przez Gradle

    Istnieje więcej opcji DSL, które możesz skonfigurować, aby ułatwić sobie dostosowanie uruchomień testowych lub przeprowadzenie migracji z innych rozwiązań, których być może już używasz. Niektóre z nich znajdziesz w opisie poniżej.

    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
    }
  }
}