Android Studio Hedgehog | 2023.1.1 (November 2023)

Berikut adalah fitur baru di Android Studio Hedgehog.

Update platform IntelliJ IDEA 2023.1

Android Studio Hedgehog menyertakan update IntelliJ IDEA 2023.1, yang meningkatkan pengalaman IDE Studio. Untuk detail tentang perubahan ini, lihat catatan rilis IntelliJ IDEA 2023.1.

Menganalisis Android vitals di App Quality Insights

App Quality Insights kini mencakup data Android vitals, sehingga Anda dapat lebih mudah mengakses metrik inti yang dikumpulkan oleh Google Play dan meningkatkan pengalaman pengguna Anda. Gunakan Android vitals untuk mengatasi masalah terkait stabilitas aplikasi guna membantu meningkatkan kualitas aplikasi Anda di Google Play.

Anda dapat melihat masalah Android vitals, memfilternya, dan beralih dari stack trace ke kode, semuanya dari jendela alat App Quality Insights. Untuk memulai, ikuti langkah-langkah ini:

  1. Login ke akun developer Anda di Android Studio menggunakan ikon profil di ujung toolbar.
  2. Buka App Quality Insights dengan mengklik jendela alat di Android Studio atau mengklik View > Tool Windows > App Quality Insights.
  3. Klik tab Android vitals di App Quality Insights.

Angka yang berbeda antara Android vitals dan Crashlytics

Perhatikan bahwa Android vitals dan Crashlytics dapat melaporkan nilai yang berbeda untuk jumlah pengguna dan peristiwa yang terkait dengan error yang sama. Perbedaan ini terjadi karena Play dan Crashlytics dapat mendeteksi error pada waktu yang berbeda dan untuk pengguna yang berbeda. Berikut beberapa alasan nilai Play dan Crashlytics dapat berbeda:

  • Play mendeteksi error yang terjadi pada waktu booting, sedangkan Crashlytics mendeteksi error yang terjadi setelah Crashlytics SDK melakukan inisialisasi.
  • Jika pengguna memilih tidak melaporkan error saat mereka membeli ponsel baru, error tersebut tidak akan dilaporkan ke Play; tetapi, Crashlytics mendeteksi error berdasarkan kebijakan privasi aplikasi itu sendiri.

Power Profiler baru

Mulai Android Studio Hedgehog, Power Profiler menampilkan konsumsi daya di perangkat. Anda dapat melihat data baru ini di Monitor Power Rail di Perangkat (ODPM). ODPM mengelompokkan data menurut subsistem yang disebut Power Rail. Lihat Power rail yang dapat dibuat profil untuk mengetahui daftar subsistem yang didukung.

Pelacakan Sistem merekam dan menampilkan data konsumsi daya. Alat tersebut merupakan bagian dari CPU profiler. Data ini secara visual membantu Anda memahami korelasi antara konsumsi daya perangkat dengan tindakan yang terjadi di aplikasi Anda. Power Profiler memungkinkan visualisasi data tersebut.

Power Profiler baru

Untuk melihat data dari Power Profiler baru, lakukan pelacakan sistem di perangkat Pixel 6+:

  1. Pilih View > Tool Windows > Profiler.
  2. Klik di mana saja dalam CPU timeline untuk membuka CPU Profiler dan memulai pelacakan sistem.

App Links Assistant baru memberikan ringkasan komprehensif tentang deep link yang disiapkan di aplikasi Anda. Assistant menampilkan semua deep link yang ada dalam file AndroidManifest.xml aplikasi, memvalidasi apakah konfigurasi untuk deep link tersebut benar, dan menyediakan cara cepat untuk memperbaiki kesalahan konfigurasi secara otomatis.

Untuk membuka App Links Assistant, buka Tools > App Links Assistant di Android Studio. Untuk informasi selengkapnya tentang link aplikasi, lihat Menambahkan Link Aplikasi Android.

Pembaruan pintasan mode manual Edit Live

Edit Live di Android Studio Hedgehog menyertakan pintasan baru untuk mode manual (Push Manually): Control+\ (Command+\ untuk macOS). Mode manual sangat membantu jika Anda ingin memiliki kontrol yang akurat terkait kapan update di-deploy ke aplikasi yang sedang berjalan. Misalnya, jika Anda membuat perubahan skala besar dalam file dan tidak ingin status perantara ditampilkan di perangkat. Anda dapat memilih antara Push Manually dan Push Manually on Save di setelan Edit Live atau menggunakan indikator UI Edit Live. Untuk informasi selengkapnya, lihat klip video di Edit Live untuk Jetpack Compose.

Template Multipratinjau Compose

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ memperkenalkan template Multipreview API baru: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark, dan @PreviewDynamicColors, sehingga dengan satu anotasi, Anda dapat melihat pratinjau UI Compose dalam skenario umum.

Di Android Studio Hedgehog, Mode galeri baru telah diperkenalkan di Pratinjau Compose. Dengan mode ini, Anda dapat fokus pada satu pratinjau dalam satu waktu dan menghemat resource saat rendering. Sebaiknya gunakan Mode Galeri saat Anda perlu melakukan iterasi di UI aplikasi dan beralihlah ke mode lain, misalnya Petak atau Daftar, saat Anda perlu melihat varian UI.

Informasi status Compose di debugger

Saat beberapa bagian dari UI Compose melakukan rekomposisi secara tidak terduga, terkadang sulit untuk memahami alasannya. Kini, saat menetapkan titik henti sementara pada fungsi composable, debugger akan mencantumkan parameter composable dan statusnya, sehingga Anda dapat lebih mudah mengidentifikasi perubahan yang mungkin menyebabkan rekomposisi. Misalnya, saat Anda menjeda composable, debugger dapat memberi tahu Anda dengan tepat parameter mana yang telah "Berubah" atau tetap "Tidak berubah", sehingga Anda dapat menyelidiki penyebab rekomposisi secara lebih efisien.

Pencerminan perangkat

Anda kini dapat mencerminkan perangkat fisik di jendela Running Devices di Android Studio. Dengan menstreaming tampilan perangkat langsung ke Android Studio, Anda dapat menjalankan berbagai tindakan umum seperti memulai aplikasi dan berinteraksi dengannya, memutar layar, menutup dan membuka ponsel, mengubah volume, serta lebih banyak lagi langsung dari IDE Studio itu sendiri.

Pencerminan perangkat selalu tersedia saat ada perangkat yang terhubung ke komputer yang mengaktifkan proses debug nirkabel atau USB. Anda dapat memulai dan menghentikan pencerminan menggunakan jendela Running Devices atau Device Manager (View > Tool Windows > Device Manager). Anda juga dapat menyesuaikan kapan pencerminan perangkat diaktifkan di setelannya (Settings > Tools > Device Mirroring).

UI Running Devices

Masalah umum

Beberapa perangkat mungkin tidak dapat melakukan encoding pada kecepatan bit yang memadai untuk mendukung pencerminan perangkat. Dalam situasi ini, Anda mungkin melihat error di jendela Running Devices serta log yang mirip dengan yang ditampilkan di bawah ini.

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

Pemberitahuan privasi

Berdasarkan setelan pencerminan perangkat, Android Studio dapat otomatis memulai pencerminan perangkat untuk perangkat yang terhubung dan disambungkan. Pencerminan ini dapat mengakibatkan terjadinya pengungkapan informasi pada perangkat yang terhubung dengan perintah adb tcpip karena informasi dan perintah pencerminan diteruskan melalui saluran yang tidak dienkripsi. Selain itu, Android Studio menggunakan saluran yang tidak dienkripsi untuk berkomunikasi dengan server adb, sehingga informasi pencerminan dapat dicegat oleh pengguna lain di mesin host Anda.

Penerusan input hardware

Kini Anda dapat mengaktifkan penerusan transparan input hardware workstation, seperti mouse dan keyboard, ke perangkat fisik dan virtual yang terhubung. Untuk mengaktifkan penerusan transparan, klik Hardware input untuk perangkat target di jendela Running Devices.

Mengelola perangkat langsung dari jendela Running Devices

Kini Anda dapat memulai Perangkat Virtual Android (AVD), atau memulai pencerminan perangkat fisik, langsung dari jendela Running Devices dengan mengklik ikon + dan memilih perangkat. Untuk menghentikan AVD atau pencerminan perangkat fisik, tutup tab perangkat.

Menu drop-down perangkat dari Running Devices

Layout Inspector Tersemat

Mulai Android Studio Hedgehog Canary 2, Anda dapat menjalankan Layout Inspector langsung di jendela alat Running Devices. Fitur eksperimental ini mempertahankan area layar dan membantu mengatur alur kerja proses debug UI Anda dalam satu jendela alat. Dalam mode tersemat, Anda dapat menampilkan hierarki tampilan, memeriksa properti setiap tampilan, dan mengakses fitur Layout Inspector umum lainnya. Untuk mengakses rangkaian lengkap opsi, Anda masih perlu menjalankan Layout Inspector di jendela mandiri (File > Settings > Experimental > Layout Inspector di Windows atau Android Studio > Settings > Experimental > Layout Inspector di macOS).

Keterbatasan Layout Inspector tersemat adalah mode 3D hanya tersedia dalam snapshot.

Untuk membantu kami meningkatkan Layout Inspector tersemat, kirimkan masukan kepada kami.

Peningkatan UI baru

UI baru untuk Android Studio menghadirkan tampilan dan nuansa yang lebih modern dan rapi ke IDE Studio. Kami mendengar masukan yang telah Anda berikan dan telah memperbaiki masalah terkait fitur berikut di Android Studio Hedgehog:

  • Mode rapat
  • Dukungan untuk memisahkan secara vertikal atau horizontal
  • Tab project untuk macOS
  • Perbaikan pada mode bebas gangguan
  • Setelan lanjutan untuk selalu menampilkan tindakan jendela alat

Update Asisten Upgrade SDK

Asisten Upgrade SDK menyediakan alur wizard langkah demi langkah untuk membantu Anda melakukan upgrade targetSdkVersion. Berikut ini update untuk Asisten Upgrade SDK di Android Studio Hedgehog:

  • Melihat perubahan yang dapat menyebabkan gangguan pada upgrade ke Android 14
  • Penambahan filter relevansi sehingga beberapa langkah yang tidak diperlukan dihapus
  • Untuk perubahan tertentu, menentukan secara tepat pada bagian kode mana perubahan perlu dilakukan

Menonaktifkan pengoptimalan build hanya untuk level API target

Kini Anda dapat menonaktifkan pengoptimalan IDE untuk level API perangkat target. Secara default, Android Studio mengurangi waktu build keseluruhan dengan menyesuaikan proses dexing untuk level API perangkat target yang menjadi tujuan deployment. Untuk menonaktifkan fitur ini, buka File > Settings > Experimental (Android Studio > Settings > Experimental di macOS), lalu hapus centang pada Optimize build for target device API level only. Perhatikan bahwa dengan menonaktifkan pengoptimalan build tersebut, waktu build dapat menjadi lebih lama.

[Khusus Windows] Meminimalkan dampak software antivirus pada kecepatan build

Build Analyzer memberi tahu Anda jika software antivirus mungkin memengaruhi performa build. Hal ini dapat terjadi jika software antivirus, seperti Windows Defender, melakukan pemindaian real-time pada direktori yang digunakan oleh Gradle. Build Analyzer merekomendasikan daftar direktori yang sebaiknya dikecualikan dari pemindaian aktif dan, jika memungkinkan, akan menawarkan link untuk menambahkannya ke daftar pengecualian folder Windows Defender.

Project Android Development Tool Eclipse tidak lagi didukung

Android Studio Hedgehog dan yang lebih baru tidak mendukung pengimporan project ADT Eclipse. Anda masih dapat membuka project tersebut, tetapi project tersebut tidak lagi dikenali sebagai project Android. Jika perlu mengimpor jenis project ini, Anda dapat menggunakan versi Android Studio yang lebih lama. Jika versi Android Studio tertentu tidak dapat mengimpor project, Anda dapat mencoba versi yang lebih lama. Setelah project dikonversi menjadi project Android menggunakan versi Android Studio yang lebih lama, Anda dapat menggunakan Upgrade Assistant AGP untuk mengerjakan project tersebut menggunakan versi Android Studio terbaru.

Menggunakan perangkat Firebase Test Lab dengan perangkat yang dikelola Gradle

Jika menggunakan AGP 8.2.0-alpha03 atau yang lebih baru, Anda dapat menjalankan pengujian berinstrumen otomatis dalam skala besar di perangkat Firebase Test Lab saat menggunakan perangkat yang dikelola Gradle. Dengan Test Lab, Anda dapat menjalankan pengujian secara bersamaan di berbagai perangkat Android, baik fisik maupun virtual. Pengujian ini berjalan di pusat data Google jarak jauh. Dengan dukungan dari perangkat yang dikelola Gradle (GMD), sistem build kini dapat sepenuhnya mengelola pengujian yang dijalankan terhadap perangkat Test Lab tersebut berdasarkan konfigurasi dalam file Gradle project Anda.

Mulai menggunakan perangkat Firebase Test Lab yang dikelola Gradle

Langkah-langkah berikut menjelaskan cara untuk mulai menggunakan perangkat Firebase Test Lab dengan GMD. Perhatikan bahwa langkah-langkah ini menggunakan gcloud CLI untuk memberikan kredensial pengguna, yang mungkin tidak berlaku di semua lingkungan pengembangan. Untuk informasi selengkapnya tentang proses autentikasi yang digunakan sesuai kebutuhan Anda, lihat Cara kerja Kredensial Default Aplikasi.

  1. Untuk membuat project Firebase, buka Firebase console. Klik Add project dan ikuti petunjuk di layar untuk membuat project. Ingat project ID Anda.

  2. Untuk menginstal Google Cloud CLI, ikuti langkah-langkah di bagian Menginstal gcloud CLI.
  3. Konfigurasi lingkungan lokal Anda.
    1. Tautkan ke project Firebase Anda di gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. Izinkan penggunaan kredensial pengguna untuk akses API. Saran dari kami memberi otorisasi dengan meneruskan file JSON akun layanan ke Gradle menggunakan DSL dalam skrip build level modul:

      Kotlin

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

      Groovy

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

      Atau, Anda dapat memberi otorisasi secara manual dengan menggunakan terminal berikut berikut:

        gcloud auth application-default login

    3. Opsional: Tambahkan project Firebase Anda sebagai project kuota. Langkah ini hanya diperlukan jika Anda melebihi kuota gratis untuk Test Lab. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. Aktifkan API yang diperlukan.

    Di kolom Halaman Library API Google Developers Console, aktifkan Cloud Testing API dan Cloud Tool Results API dengan mengetikkan nama API ini ke dalam kotak penelusuran di bagian atas konsol, dan lalu klik Enable API di halaman ringkasan untuk setiap API.

  5. Konfigurasi project Android Anda.

    1. Tambahkan plugin Firebase Test Lab di skrip build level atas:

      Kotlin

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

      Groovy

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

    2. Aktifkan jenis perangkat kustom di file gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true

    3. Tambahkan plugin Firebase Test Lab dalam skrip build level modul:

      Kotlin

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

      Groovy

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

    Membuat dan menjalankan pengujian di perangkat Firebase Test Lab yang dikelola Gradle

    Anda dapat menentukan perangkat Firebase Test Lab untuk Gradle yang akan digunakan untuk menguji aplikasi dalam skrip build level modul. Contoh kode berikut membuat Pixel 3 yang menjalankan level API 30 sebagai perangkat Test Lab yang dikelola Gradle dan disebut ftlDevice. Blok firebaseTestLab {} tersedia saat Anda menerapkan plugin com.google.firebase.testlab ke modul. Versi minimum Plugin Android Gradle yang didukung adalah 8.2.0-alpha01.

    Kotlin

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

    Groovy

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

    Untuk menjalankan pengujian menggunakan perangkat Test Lab yang dikelola Gradle yang telah Anda konfigurasi, gunakan perintah berikut. device-name adalah nama perangkat yang Anda konfigurasi dalam skrip build Gradle, seperti ftlDevice, dan BuildVariant adalah varian build aplikasi yang ingin Anda uji. Perhatikan bahwa Gradle tidak menjalankan pengujian secara paralel atau mendukung konfigurasi Google Cloud CLI lainnya untuk perangkat Test Lab.

    Di Windows:

    gradlew device-nameBuildVariantAndroidTest

    Di Linux atau macOS:

    ./gradlew device-nameBuildVariantAndroidTest

    Output pengujian mencakup jalur ke file HTML yang memiliki laporan pengujian. Anda juga dapat mengimpor hasil pengujian ke Android Studio untuk analisis lebih lanjut dengan mengklik Run > Test History di IDE.

    Membuat dan menjalankan pengujian di grup perangkat

    Untuk menskalakan pengujian, tambahkan beberapa perangkat Firebase Test Lab yang dikelola Gradle ke grup perangkat, lalu jalankan pengujian pada semua perangkat dengan satu perintah. Misalnya Anda memiliki beberapa perangkat yang disiapkan sebagai berikut:

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

    Untuk menambahkannya ke grup perangkat yang disebut samsungGalaxy, gunakan blok 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"])
        }
      }
    }
  }
}

    Untuk menjalankan pengujian pada semua perangkat di grup perangkat, gunakan perintah berikut:

    Di Windows:

    gradlew group-nameGroupBuildVariantAndroidTest

    Di Linux atau macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest

    Mengoptimalkan pengujian dengan sharding cerdas

    Kini pengujian pada perangkat Test Lab yang dikelola Gradle mendukung sharding cerdas. Sharding cerdas mendistribusikan pengujian Anda ke seluruh shard secara otomatis sehingga setiap shard berjalan kurang lebih dalam waktu yang sama. Dengan begitu, upaya alokasi manual dan durasi pengujian secara keseluruhan dapat dikurangi. Sharding cerdas menggunakan histori pengujian Anda, atau informasi tentang berapa lama pengujian Anda telah berjalan sebelumnya, untuk mendistribusikan pengujian secara optimal. Perhatikan bahwa Anda memerlukan plugin Gradle versi 0.0.1-alpha05 agar Firebase Test Lab dapat menggunakan sharding cerdas.

    Untuk mengaktifkan sharding cerdas, tentukan jumlah waktu yang diperlukan pengujian dalam setiap shard. Anda harus menetapkan durasi waktu shard target menjadi setidaknya lima menit lebih cepat dari timeoutMinutes untuk menghindari situasi ketika shard dibatalkan sebelum pengujian dapat selesai.

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

    Untuk mempelajari lebih lanjut, baca tentang opsi DSL baru.

    DSL yang diperbarui untuk perangkat Firebase Test Lab yang dikelola Gradle

    Ada lebih banyak opsi DSL yang dapat Anda konfigurasi untuk membantu menyesuaikan pengujian yang dijalankan atau bermigrasi dari solusi lain yang mungkin sudah Anda gunakan. Lihat beberapa opsi ini seperti yang dijelaskan dalam cuplikan kode berikut.

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