Android Studio Hedgehog | 1.1.2023 (novembre 2023)

Di seguito sono riportate le nuove funzionalità di Android Studio Hedgehog.

Aggiornamento della piattaforma IntelliJ IDEA 2023.1

Android Studio Hedgehog include gli aggiornamenti IntelliJ IDEA 2023.1, che migliorano l'esperienza dell'IDE di Studio. Per maggiori dettagli sulle modifiche, consulta le note di rilascio di IntelliJ IDEA 2023.1.

Analizzare Android vitals nella sezione Approfondimenti sulla qualità delle app

Approfondimenti sulla qualità delle app ora include dati di Android vitals, per consentirti di accedere più facilmente alle metriche principali raccolte da Google Play e migliorare l'esperienza utente. Utilizza Android vitals per risolvere problemi relativi alla stabilità dell'app e migliorare la qualità della tua app su Google Play.

Puoi visualizzare i problemi di Android vitals, filtrarli, passare dall'analisi dello stack alla programmazione direttamente dalla finestra dello strumento Approfondimenti sulla qualità delle app. Per iniziare, segui questi passaggi:

  1. Accedi al tuo account sviluppatore in Android Studio utilizzando l'icona del profilo alla fine della barra degli strumenti.
  2. Apri Approfondimenti sulla qualità delle app facendo clic sulla finestra degli strumenti in Android Studio oppure su Visualizza > Finestre degli strumenti > Statistiche sulla qualità delle app.
  3. Fai clic sulla scheda Android vitals in Approfondimenti sulla qualità delle app.

Numeri diversi tra Android vitals e Crashlytics

Tieni presente che Android vitals e Crashlytics potrebbero segnalare valori diversi per il numero di utenti ed eventi associati allo stesso arresto anomalo. Queste discrepanze si verificano perché Play e Crashlytics possono rilevare gli arresti anomali in momenti diversi e per utenti diversi. Ecco un paio di motivi per cui i conteggi di Play e Crashlytics potrebbero essere diversi:

  • Play rileva gli arresti anomali a partire dal momento dell'avvio, mentre Crashlytics intercetta gli arresti anomali che si verificano dopo l'inizializzazione dell'SDK di Crashlytics.
  • Se un utente disattiva i report sugli arresti anomali quando acquista un nuovo telefono, questi arresti anomali non vengono segnalati a Play; tuttavia, Crashlytics rileva gli arresti anomali in base alle norme sulla privacy dell'app.

Nuovo Power Profiler

A partire da Android Studio Hedgehog, Power Profiler mostra il consumo energetico sui dispositivi. Puoi visualizzare questi nuovi dati nel monitoraggio dei sistemi di alimentazione del dispositivo (ODPM) sul dispositivo. L'ODPM segmenta i dati in base a sottosistemi chiamati Power Rails. Vedi Sistemi di alimentazione profilabili per un elenco dei sottosistemi supportati.

System Trace registra e visualizza i dati sul consumo energetico. Fa parte del profiler CPU. Questi dati consentono di correlare visivamente il consumo energetico del dispositivo con le azioni che si verificano nella tua app. Power Profiler consente di visualizzare questi dati.

Il nuovo Power Profiler

Per visualizzare i dati dal nuovo Power Profiler, esegui una traccia del sistema su un dispositivo Pixel 6 o versioni successive:

  1. Seleziona Visualizza > Finestre degli strumenti > Profiler.
  2. Fai clic in un punto qualsiasi della sequenza temporale della CPU per aprire Profiler CPU e avviare una traccia di sistema.

Il nuovo Assistente link app fornisce una panoramica completa dei link diretti configurati nella tua app. L'assistente visualizza tutti i link diretti esistenti nel file AndroidManifest.xml dell'app, verifica se la configurazione di questi link diretti è corretta e fornisce un modo rapido per correggere automaticamente le configurazioni errate.

Per aprire l'Assistente link alle app, seleziona Strumenti > Assistente link app in Android Studio. Per maggiori informazioni sui link dell'app, consulta la pagina Aggiungere link per app Android.

Scorciatoia per la modalità manuale aggiornata con la modifica dal vivo

Live Edit in Android Studio Hedgehog include una nuova scorciatoia per la modalità manuale (Push manuale): Ctrl+\ (Comando+\ per macOS). La modalità manuale è utile nelle situazioni in cui vuoi avere un controllo preciso sul deployment degli aggiornamenti nell'applicazione in esecuzione. Ad esempio, se stai apportando una modifica su larga scala a un file e non vuoi che lo stato intermedio si rifletta sul dispositivo. Puoi scegliere tra Invia manualmente e Invia manualmente al momento del salvataggio nelle impostazioni di Modifica dal vivo o utilizzando l'indicatore dell'interfaccia utente della modifica dal vivo. Per ulteriori informazioni, guarda il video clip in Live Edit per Jetpack Compose.

Crea modelli di anteprima multipla

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ introduce i nuovi modelli dell'API Multipreview: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark e @PreviewDynamicColors, in modo che con una singola annotazione sia possibile visualizzare l'anteprima della UI di Compose negli scenari comuni.

In Android Studio Hedgehog, nell'anteprima di Scrivi è stata introdotta una nuova modalità Galleria, che ti consente di concentrarti su un'anteprima alla volta e risparmiare risorse sul rendering. Ti consigliamo di utilizzare la modalità Galleria quando devi eseguire l'iterazione dell'interfaccia utente della tua app e passare ad altre modalità, ad esempio Griglia o Elenco, quando hai bisogno di vedere varianti dell'interfaccia utente.

Scrivi informazioni sullo stato nel debugger

Quando alcune parti dell'interfaccia utente di Compose si ricompongono inaspettatamente, a volte è difficile comprenderne il motivo. Ora, quando imposti un punto di interruzione su una funzione componibile, il debugger elenca i parametri del componibile e il relativo stato, per consentirti di identificare più facilmente le modifiche che potrebbero aver causato la ricomposizione. Ad esempio, quando ti fermi su un componibile, il debugger può indicare esattamente quali parametri hanno "Modificato" o sono rimasti "Invariati", in modo da poter esaminare in modo più efficiente la causa della ricomposizione.

Mirroring dispositivo

Ora puoi eseguire il mirroring del tuo dispositivo fisico nella finestra Dispositivi in esecuzione in Android Studio. Grazie allo streaming del display del tuo dispositivo direttamente su Android Studio, puoi eseguire azioni comuni come avviare le app e interagire con esse, ruotare lo schermo, piegare e aprire lo smartphone, regolare il volume e altro ancora direttamente dall'IDE di Studio.

Il mirroring del dispositivo è sempre disponibile quando al computer sono collegati dispositivi su cui è abilitato il debug USB o wireless. Puoi avviare e interrompere il mirroring utilizzando la finestra Dispositivi in esecuzione o la Gestione dispositivi (Visualizza > Finestre degli strumenti > Gestione dispositivi). Puoi anche personalizzare l'attivazione del mirroring del dispositivo nelle relative impostazioni (Impostazioni > Strumenti > Mirroring dispositivo).

UI dispositivi in esecuzione

Problemi noti

Alcuni dispositivi potrebbero non essere in grado di eseguire la codifica con una velocità in bit sufficiente a supportare il mirroring del dispositivo. In questi casi, potresti visualizzare un errore nella finestra Dispositivi in esecuzione e nei log simili a quanto illustrato di seguito.

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

Informativa sulla privacy

In base alle impostazioni di mirroring del dispositivo, Android Studio può avviare automaticamente il mirroring del dispositivo per qualsiasi dispositivo connesso e accoppiato. Ciò potrebbe comportare la divulgazione di informazioni per i dispositivi connessi con il comando adb tcpip, in quanto le informazioni e i comandi di mirroring vengono passati su un canale non criptato. Inoltre, Android Studio utilizza un canale non criptato per comunicare con l'adb server, in modo che le informazioni del mirroring possano essere intercettate da altri utenti sulla macchina host.

Inoltro input hardware

Ora puoi abilitare l'inoltro trasparente degli ingressi hardware della workstation, come mouse e tastiera, a un dispositivo fisico e virtuale connesso. Per abilitare l'inoltro trasparente, fai clic su Input hardware in corrispondenza del dispositivo di destinazione nella finestra Dispositivi in esecuzione.

Gestisci i dispositivi direttamente dalla finestra Dispositivi in esecuzione

Ora puoi avviare un dispositivo virtuale Android (AVD) o avviare il mirroring di un dispositivo fisico direttamente dalla finestra Dispositivi in esecuzione facendo clic sull'icona + e selezionando un dispositivo. Per interrompere la modalità AVD o il mirroring di un dispositivo fisico, chiudi la scheda del dispositivo.

Menu a discesa Dispositivo dalla sezione Dispositivi in esecuzione

Controllo layout incorporato

A partire da Android Studio Hedgehog Canary 2, puoi eseguire lo strumento Layout Inspector direttamente nella finestra dello strumento Dispositivi in esecuzione. Questa funzionalità sperimentale consente di risparmiare spazio sullo schermo e di organizzare il flusso di lavoro di debug dell'interfaccia utente in un'unica finestra degli strumenti. Nella modalità incorporata puoi mostrare una gerarchia delle viste, esaminare le proprietà di ogni vista e accedere ad altre funzionalità comuni di Layout Inspector. Per accedere al set completo di opzioni, devi eseguire comunque Controllo layout in una finestra separata (File > Impostazioni > Sperimentale > Controllo layout su Windows o Android Studio > Impostazioni > Sperimentale > Controllo layout su macOS).

Un limite di Layout Inspector incorporato è che la modalità 3D è disponibile solo negli snapshot.

Per aiutarci a migliorare l'oggetto Layout Inspector incorporato, inviaci il tuo feedback.

Nuovi miglioramenti all'interfaccia utente

La nuova UI di Android Studio conferisce un aspetto più moderno e lineare all'IDE Studio. Finora abbiamo ascoltato il tuo feedback e abbiamo risolto i problemi relativi alle seguenti funzionalità di Android Studio Hedgehog:

  • Modalità compatta
  • Supporto per la suddivisione verticale o orizzontale
  • Schede dei progetti per macOS
  • Correzioni alla modalità senza distrazioni
  • Impostazioni avanzate per mostrare sempre le azioni nella finestra degli strumenti

Aggiornamenti dell'Assistente con upgrade dell'SDK

L'Assistente per l'upgrade dell'SDK fornisce un flusso della procedura guidata passo passo per aiutarti con gli upgrade di targetSdkVersion. Di seguito sono riportati gli aggiornamenti di SDK Upgrade Assistant in Android Studio Hedgehog:

  • Scopri le modifiche che interessano l'upgrade ad Android 14
  • Sono stati aggiunti filtri di pertinenza per rimuovere alcuni passaggi non necessari
  • Per determinate modifiche, individua esattamente il punto in cui devono essere apportate le modifiche

Disabilita l'ottimizzazione della build solo per il livello API target

Ora puoi disabilitare l'ottimizzazione IDE per il livello API del dispositivo di destinazione. Per impostazione predefinita, Android Studio riduce il tempo complessivo di creazione personalizzando il processo di dexing in base al livello API del dispositivo di destinazione su cui stai eseguendo il deployment. Per disattivare questa funzionalità, vai a File > Impostazioni > Sperimentale (Android Studio > Impostazioni > Sperimentale su macOS) e deseleziona Ottimizza build solo per livello API del dispositivo di destinazione. Tieni presente che la disattivazione dell'ottimizzazione della build potrebbe aumentare il tempo di creazione.

[Solo Windows] Ridurre al minimo l'impatto del software antivirus sulla velocità di compilazione

Analizzatore build ti informa se il software antivirus potrebbe influire sulle prestazioni della build. Questo può accadere se un software antivirus, come Windows Defender, esegue una scansione in tempo reale delle directory utilizzate da Gradle. Build Analyzer consiglia un elenco di directory da escludere dalla scansione attiva e, se possibile, offre un link per aggiungerle all'elenco di esclusione delle cartelle di Windows Defender.

I progetti dello strumento di sviluppo Android di Eclipse non sono più supportati

Android Studio Hedgehog e versioni successive non supportano l'importazione dei progetti Eclipse ADT. Puoi comunque aprirli, ma non sono più riconosciuti come progetti Android. Se devi importare questo tipo di progetto, puoi utilizzare una versione precedente di Android Studio. Se una determinata versione di Android Studio non riesce a importare il progetto, puoi provare con una versione precedente. Dopo aver convertito il progetto in un progetto Android utilizzando una versione precedente di Android Studio, puoi utilizzare AGP Upgrade Assistant per lavorare al progetto utilizzando la versione più recente di Android Studio.

Utilizzare i dispositivi Firebase Test Lab con dispositivi gestiti da Gradle

Se utilizzi AGP 8.2.0-alpha03 o versioni successive, puoi eseguire i test automatizzati su larga scala sui dispositivi Firebase Test Lab quando utilizzi i dispositivi gestiti da Gradle. Test Lab ti consente di eseguire i test contemporaneamente su un'ampia gamma di dispositivi Android, sia fisici che virtuali. Questi test vengono eseguiti in data center Google remoti. Con il supporto dei dispositivi gestiti da Gradle (GMD), il sistema di compilazione ora può gestire completamente i test in esecuzione su questi dispositivi Test Lab in base alle configurazioni nei file Gradle del tuo progetto.

Inizia a utilizzare i dispositivi Firebase Test Lab gestiti da Gradle

I passaggi seguenti descrivono come iniziare a utilizzare i dispositivi Firebase Test Lab con GMD. Tieni presente che questi passaggi utilizzano gcloud CLI per fornire le credenziali utente, che potrebbero non essere applicabili a tutti gli ambienti di sviluppo. Per saperne di più su quale processo di autenticazione utilizzare per le tue esigenze, consulta Come funzionano le credenziali predefinite dell'applicazione.

  1. Per creare un progetto Firebase, vai alla console di Firebase. Fai clic su Aggiungi progetto e segui le istruzioni sullo schermo per creare un progetto. Ricorda l'ID progetto.

  2. Per installare Google Cloud CLI, segui i passaggi descritti in Installare gcloud CLI.
  3. Configura il tuo ambiente locale.
    1. Collega il tuo progetto Firebase in gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. Autorizza l'uso delle tue credenziali utente per l'accesso all'API. Ti consigliamo di concedere l'autorizzazione passando un file JSON dell'account di servizio a Gradle utilizzando la DSL nello script di build a livello di modulo:

      Kotlin

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

      trendy

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

      In alternativa, puoi autorizzarla manualmente utilizzando il seguente comando del terminale:

        gcloud auth application-default login

    3. (Facoltativo) Aggiungi il progetto Firebase come progetto della quota. Questo passaggio è necessario solo se superi la quota senza costi per Test Lab. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. Abilita le API richieste.

    Nella pagina della libreria API di Google Developers Console, abilita l'API Cloud Testing e l'API Cloud Tool Results digitando i nomi delle API nella casella di ricerca nella parte superiore della console e facendo clic su Abilita API nella pagina Panoramica di ogni API.

  5. Configura il tuo progetto Android.

    1. Aggiungi il plug-in Firebase Test Lab allo script di build di primo livello:

      Kotlin

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

      trendy

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

    2. Attiva tipi di dispositivi personalizzati nel file gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true

    3. Aggiungi il plug-in Firebase Test Lab nello script di compilazione a livello di modulo:

      Kotlin

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

      trendy

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

    Creare ed eseguire test su un dispositivo Firebase Test Lab gestito da Gradle

    Puoi specificare un dispositivo Firebase Test Lab da far utilizzare a Gradle per testare la tua app nello script di build a livello di modulo. Il seguente esempio di codice crea un Pixel 3 con livello API 30 come dispositivo Test Lab gestito da Gradle chiamato ftlDevice. Il blocco firebaseTestLab {} è disponibile quando applichi il plug-in com.google.firebase.testlab al modulo. La versione minima supportata del plug-in Android per Gradle è 8.2.0-alpha01.

    Kotlin

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

    trendy

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

    Per eseguire i test con i dispositivi Test Lab gestiti da Gradle che hai configurato, utilizza il seguente comando. device-name è il nome del dispositivo configurato nello script di build Gradle, ad esempio ftlDevice, e BuildVariant è la variante build dell'app che vuoi testare. Tieni presente che Gradle non esegue test in parallelo né supporta altre configurazioni di Google Cloud CLI per i dispositivi Test Lab.

    Su Windows:

    gradlew device-nameBuildVariantAndroidTest

    In Linux o macOS:

    ./gradlew device-nameBuildVariantAndroidTest

    L'output del test include un percorso a un file HTML contenente il report del test. Puoi anche importare i risultati dei test in Android Studio per ulteriori analisi facendo clic su Esegui > Cronologia dei test nell'IDE.

    Crea ed esegui test su un gruppo di dispositivi

    Per scalare i test, aggiungi più dispositivi Firebase Test Lab gestiti da Gradle a un gruppo di dispositivi ed esegui i test su tutti con un unico comando. Supponiamo che tu abbia più dispositivi configurati come segue:

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

    Per aggiungerli a un gruppo di dispositivi chiamato samsungGalaxy, utilizza il blocco 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"])
        }
      }
    }
  }
}

    Per eseguire test su tutti i dispositivi nel gruppo, usa il seguente comando:

    Su Windows:

    gradlew group-nameGroupBuildVariantAndroidTest

    In Linux o macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest

    Ottimizza le esecuzioni dei test con lo sharding intelligente

    I test su dispositivi Test Lab gestiti da Gradle supportano ora lo sharding intelligente. Lo sharding intelligente distribuisce automaticamente i test tra gli shard in modo che ciascuno shard venga eseguito all'incirca nello stesso tempo, riducendo gli sforzi di allocazione manuale e la durata complessiva dell'esecuzione dei test. Lo sharding intelligente utilizza la cronologia dei test o le informazioni sul tempo necessario per l'esecuzione dei test in precedenza, al fine di distribuire i test in modo ottimale. Tieni presente che è necessaria la versione 0.0.1-alpha05 del plug-in Gradle affinché Firebase Test Lab possa utilizzare lo sharding intelligente.

    Per abilitare lo sharding intelligente, specifica la quantità di tempo necessaria per i test all'interno di ogni shard. Dovresti impostare la durata del tempo shard target su almeno cinque minuti in meno rispetto a timeoutMinutes per evitare la situazione in cui gli shard vengano annullati prima che i test possano terminare.

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

    Per ulteriori informazioni, scopri le nuove opzioni DSL.

    DSL aggiornata per dispositivi Firebase Test Lab gestiti da Gradle

    Puoi configurare altre opzioni DSL per personalizzare le esecuzioni di test o per eseguire la migrazione da altre soluzioni che potresti già utilizzare. Visualizza alcune di queste opzioni come descritto nello snippet di codice che segue.

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