Android Studio Hedgehog | 2023.1.1 (noviembre de 2023)

Las siguientes son funciones nuevas de Android Studio Hedgehog.

Actualización de la plataforma IntelliJ IDEA 2023.1

Android Studio Hedgehog incluye las actualizaciones de IntelliJ IDEA 2023.1, que mejoran la experiencia del IDE de Studio. Para obtener detalles sobre los cambios, consulta las notas de la versión de IntelliJ IDEA 2023.1.

Analiza Android vitals en App Quality Insights

App Quality Insights ahora incluyen datos de Android vitals para que puedas acceder, con mayor facilidad, a las métricas principales que recopila Google Play y mejorar la experiencia del usuario. Usa Android vitals para solucionar problemas relacionados con la estabilidad de tu app y mejorar su calidad en Google Play.

Desde la ventana de herramientas App Quality Insights, puedes ver los problemas de Android vitals, filtrarlos y pasar del seguimiento de pila para codificarlos. Para comenzar, sigue estos pasos:

  1. Accede a tu cuenta de desarrollador en Android Studio con el ícono de perfil que está al final de la barra de herramientas.
  2. Para abrir App Quality Insights, haz clic en la ventana de herramientas de Android Studio o en View > Tool Windows > App Quality Insights.
  3. Haz clic en la pestaña Android vitals en App Quality Insights.

Diferentes valores entre Android vitals y Crashlytics

Ten en cuenta que Android vitals y Crashlytics pueden informar valores diferentes para la cantidad de usuarios y eventos asociados con la misma falla. Estas discrepancias se producen porque Play y Crashlytics pueden detectar fallas en diferentes momentos y para diferentes usuarios. A continuación, se incluyen algunos motivos por los que los valores de Play y Crashlytics pueden diferir:

  • Play detecta las fallas que comienzan en el momento del inicio, mientras que Crashlytics detecta las fallas que se producen después de que se inicializa el SDK de Crashlytics.
  • Si un usuario inhabilita los informes de fallas cuando obtiene un teléfono nuevo, esas fallas no se informarán a Play; sin embargo, Crashlytics detecta las fallas, según la propia política de privacidad de la app.

Nuevo generador de perfiles de energía

A partir de Android Studio Hedgehog, el generador de perfiles de energía muestra el consumo de energía en los dispositivos. Puedes ver estos datos nuevos en el monitor de rieles de energía integrado en el dispositivo (ODPM). El ODPM segmenta los datos, según los subsistemas denominados Power Rails. Consulta los rieles de energía perfilables para obtener una lista de los subsistemas compatibles.

El registro del sistema asienta y muestra los datos de consumo de energía. Forma parte del generador de perfiles de CPU. Estos datos te ayudan a correlacionar, visualmente, el consumo de energía del dispositivo con las acciones que tienen lugar en tu app. El generador de perfiles de energía permite visualizar estos datos.

El nuevo generador de perfiles de energía

Para consultar los datos del nuevo generador de perfiles de energía, realiza un registro del sistema en un dispositivo Pixel 6 o versiones posteriores:

  1. Selecciona View > Tool Windows > Profiler.
  2. Haz clic en cualquier parte del cronograma de CPU para abrir el generador de perfiles de CPU y comenzar un registro del sistema.

El nuevo App Links Assistant proporciona una descripción general completa de los vínculos directos que se configuran en tu app. Assistant muestra todos los vínculos directos existentes en el archivo AndroidManifest.xml de la app, valida si la configuración de esos vínculos directos es correcta y proporciona una forma rápida de corregir, automáticamente, los errores de configuración.

Para abrir App Links Assistant, ve a Tools > App Links Assistant en Android Studio. Para obtener más información sobre los vínculos de apps, consulta Cómo agregar Android App Links.

Actualización de la combinación de teclas para el modo manual en Ediciones en vivo

Ediciones en vivo en Android Studio Hedgehog incluye una nueva combinación de teclas para el modo manual (Push Manually): Control + \ (Comando + \ para macOS). El modo manual es útil en situaciones en las que deseas tener un control preciso sobre los momentos en los que se implementan las actualizaciones en la aplicación en ejecución. Por ejemplo, si realizas un cambio a gran escala en un archivo y no quieres que ningún estado intermedio se refleje en el dispositivo. Puedes elegir entre Push Manually y Push Manually on Save en la configuración de Ediciones en vivo o a través del indicador de su IU. Para obtener más información, consulta el clip de video sobre ediciones en vivo para Jetpack Compose.

Plantillas de vista previa múltiple de Compose

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ introduce nuevas plantillas de la API de Multipreview: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark y @PreviewDynamicColors, de modo que, con una sola anotación, puedas obtener una vista previa de la IU de Compose en situaciones frecuentes.

En Android Studio Hedgehog, se introdujo un nuevo modo Gallery en la vista previa de Compose, que te permite enfocarte en una vista previa a la vez y ahorrar recursos en la renderización. Te recomendamos que uses el modo Gallery cuando necesites iterar en la IU de tu app y cambiar a otros modos, como Grid o List, en los casos en los que necesites ver variantes de la IU.

Información sobre el estado de Compose en el depurador

Cuando partes de la IU de Compose se recomponen de forma inesperada, con frecuencia, es difícil comprender el motivo. Ahora, cuando se establece un punto de interrupción en una función de componibilidad, el depurador enumera los parámetros del elemento componible y su estado, de modo que puedas identificar, con mayor facilidad, los cambios que podrían haber causado la recomposición. Por ejemplo, cuando pausas en un elemento componible, el depurador puede indicarte exactamente qué parámetros tienen el estado "Changed" o permanecieron "Unchanged", para que puedas investigar, de manera más eficiente, la causa de la recomposición.

Duplicación de dispositivos

Ahora puedes duplicar tu dispositivo físico en la ventana Running Devices de Android Studio. Si transmites la pantalla del dispositivo directamente a Android Studio, puedes ejecutar acciones comunes, como iniciar apps e interactuar con ellas, rotar la pantalla, plegar y desplegar el teléfono, cambiar el volumen y mucho más desde el mismo IDE de Studio.

La duplicación de dispositivos siempre está disponible cuando hay dispositivos conectados a la computadora con la depuración inalámbrica o el USB habilitados. Puedes iniciar y detener la duplicación con la ventana Running Devices o Device Manager (View > Tool Windows > Device Manager). También puedes personalizar el momento en que se activa la duplicación de dispositivos (Settings > Tools > Device Mirroring).

IU de Running Devices

Errores conocidos

Es posible que algunos dispositivos no sean capaces de codificar a una tasa de bits suficiente para admitir la duplicación de dispositivos. En estas situaciones, es posible que veas un error en la ventana Running Devices, así como registros similares a los que se muestran a continuación.

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

Aviso de Privacidad

Según la configuración de la duplicación de dispositivos, Android Studio puede iniciar, automáticamente, esta función para cualquier dispositivo conectado y vinculado. Esto puede dar lugar a la divulgación de información de los dispositivos conectados con el comando adb tcpip, ya que la información y los comandos de duplicación se pasan a través de un canal no encriptado. Además, Android Studio usa un canal no encriptado para comunicarse con el servidor de adb, por lo que otros usuarios de tu máquina anfitrión pueden interceptar la información de duplicación.

Reenvío de entradas de hardware

Ahora puedes habilitar el reenvío transparente de las entradas de hardware de tu estación de trabajo, como el mouse y el teclado, a un dispositivo físico y virtual conectado. Para habilitar el reenvío transparente, haz clic en Hardware input para el dispositivo de destino en la ventana Running Devices.

Administra dispositivos directamente desde la ventana Running Devices

Ahora puedes iniciar un dispositivo virtual de Android (AVD) o comenzar a duplicar un dispositivo físico directamente desde la ventana Running Devices si haces clic en el ícono + y seleccionas un dispositivo. Para detener el AVD o la duplicación de un dispositivo físico, cierra la pestaña del dispositivo.

Menú desplegable de dispositivos en Running Devices

Inspector de diseño incorporado

A partir de Android Studio Hedgehog Canary 2, puedes ejecutar el Inspector de diseño directamente en la ventana de herramientas Running Devices. Esta función experimental mejora conserva el espacio de la pantalla y ayuda a organizar el flujo de trabajo de depuración de la IU en una sola ventana de herramientas. En el modo incorporado, puedes mostrar una jerarquía de vistas, inspeccionar las propiedades de cada vista y acceder a otras funciones habituales del Inspector de diseño. Para acceder al conjunto completo de opciones, debes ejecutar el Inspector de diseño en una ventana independiente (File > Settings > Experimental > Layout Inspector en Windows o Android Studio > Settings > Experimental > Layout Inspector en macOS).

El Inspector de diseño incorporado tiene la limitación de que el modo 3D solo está disponible en instantáneas.

Para ayudarnos a mejorar el Inspector de diseño incorporado, envíanos comentarios.

Nuevas mejoras en la IU

La nueva IU de Android Studio le brinda una apariencia más moderna y simple al IDE de Studio. Tomamos en cuenta tus comentarios hasta ahora y solucionamos los problemas relacionados con las siguientes funciones de Android Studio Hedgehog:

  • Modo compacto
  • Compatibilidad con la división horizontal o vertical
  • Pestañas Project para macOS
  • Correcciones al modo sin distracciones
  • Configuración avanzada para mostrar siempre las acciones de la ventana de herramientas

Actualizaciones del Asistente de actualización del SDK

El Asistente de actualización del SDK proporciona un flujo del asistente paso a paso para ayudarte con las actualizaciones de targetSdkVersion. Las actualizaciones del Asistente de actualización del SDK en Android Studio Hedgehog son las siguientes:

  • Consulta los cambios rotundos de la actualización a Android 14.
  • Se agregaron filtros de relevancia para que se quiten algunos pasos innecesarios.
  • Para ciertos cambios, señala exactamente en qué parte del código se deben realizar los cambios.

Inhabilita la optimización de compilación solo para el nivel de API objetivo

Ahora puedes inhabilitar la optimización del IDE para el nivel de API del dispositivo de destino. De forma predeterminada, Android Studio reduce el tiempo de compilación general a través de la adaptación del proceso de conversión a dex para el nivel de API del dispositivo de destino en el que realizas la implementación. Para desactivar esta función, ve a File > Settings > Experimental (Android Studio > Settings > Experimental en macOS) y desmarca Optimize build for target device API level only. Ten en cuenta que desactivar esta optimización de compilación puede aumentar el tiempo de compilación.

[Solo para Windows] Minimiza el impacto del software antivirus en la velocidad de compilación

Build Analyzer te informa si el software antivirus puede estar afectando el rendimiento de la compilación, lo que puede suceder si un software antivirus, como Windows Defender, realiza un escaneo en tiempo real de los directorios que usa Gradle. Build Analyzer recomienda una lista de directorios para excluir del escaneo activo y, si es posible, ofrece un vínculo para agregarlos a la lista de exclusiones de carpetas de Windows Defender.

Ya no se admiten los proyectos de la herramienta de desarrollo para Android de Eclipse

Android Studio Hedgehog y las versiones posteriores no admiten la importación de proyectos ADT de Eclipse. Podrás abrir estos proyectos, pero ya no se reconocerán como proyectos de Android. Si necesitas importar este tipo de proyecto, puedes usar una versión anterior de Android Studio. Si no puedes importar tu proyecto en una versión determinada de Android Studio, puedes probar con una versión anterior. Una vez que el proyecto se convierta en un proyecto de Android con una versión anterior de Android Studio, podrás usar el Asistente de actualización del AGP para trabajar en ese proyecto con la versión más reciente de Android Studio.

Usa dispositivos de Firebase Test Lab con dispositivos administrados por Gradle

Si usas AGP 8.2.0-alpha03 o una versión posterior, puedes ejecutar tus pruebas de instrumentación automatizadas a gran escala en dispositivos de Firebase Test Lab cuando usas dispositivos administrados por Gradle. Test Lab te permite ejecutar las pruebas simultáneamente en una amplia variedad de dispositivos Android, tanto físicos como virtuales. Estas pruebas se ejecutan en centros de datos remotos de Google. Gracias a la compatibilidad con los dispositivos administrados por Gradle (GMD), el sistema de compilación ahora puede administrar, por completo, la ejecución de pruebas en estos dispositivos de Test Lab, según la configuración de los archivos Gradle de tu proyecto.

Comienza a usar dispositivos de Firebase Test Lab administrados por Gradle

En los siguientes pasos, se describe cómo comenzar a usar dispositivos de Firebase Test Lab con GMD. Ten en cuenta que estos pasos usan gcloud CLI para proporcionar credenciales de usuario, que podrían no aplicarse a todos los entornos de desarrollo. Para obtener más información sobre qué proceso de autenticación usar para tus necesidades, consulta Cómo funcionan las credenciales predeterminadas de la aplicación.

  1. Para crear un proyecto de Firebase, ve a Firebase console. Haz clic en Add project y sigue las indicaciones que aparecen en pantalla para crear un proyecto. Recuerda tu ID del proyecto.

  2. Para instalar Google Cloud CLI, sigue los pasos que se indican en la página sobre cómo instalar gcloud CLI.
  3. Configura tu entorno local.
    1. Vincula a tu proyecto de Firebase en gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. Autoriza el uso de tus credenciales de usuario para el acceso a la API. Te recomendamos que la autorices pasando un archivo JSON de cuenta de servicio a Gradle con la DSL en la secuencia de comandos de compilación a nivel de módulo:

      Kotlin

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

      Groovy

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

      Como alternativa, puedes autorizarlo de forma manual con el siguiente comando de la terminal:

        gcloud auth application-default login

    3. Opcional: Agrega tu proyecto de Firebase como el proyecto de cuota. Este paso solo es necesario si superas la cuota sin costo de Test Lab. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. Habilita las APIs obligatorias.

    En la página Biblioteca de APIs de Google Developers Console, habilita la API de Cloud Testing y la API de Cloud Tool Results. Para ello, escribe estos nombres de API en el cuadro de búsqueda en la parte superior de la consola y, luego, haz clic en Habilitar API en la página de descripción general de cada API.

  5. Configura tu proyecto de Android.

    1. Agrega el complemento de Firebase Test Lab a la secuencia de comandos de compilación de nivel superior:

      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. Habilita tipos de dispositivos personalizados en el archivo gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true

    3. Agrega el complemento de Firebase Test Lab a la secuencia de comandos de compilación a nivel de módulo:

      Kotlin

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

      Groovy

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

    Crea y ejecuta pruebas en un dispositivo de Firebase Test Lab administrado por Gradle

    Puedes especificar un dispositivo de Firebase Test Lab para que Gradle pruebe tu app en la secuencia de comandos de compilación a nivel de módulo. En la siguiente muestra de código, se crea un Pixel 3 que ejecuta el nivel de API 30 como un dispositivo de Test Lab administrado por Gradle, llamado ftlDevice. El bloque firebaseTestLab {} está disponible cuando aplicas el complemento com.google.firebase.testlab a tu módulo. La versión mínima del complemento de Android para Gradle compatible es 8.2.0-alpha01.

    Kotlin

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

    Groovy

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

    Para que los dispositivos de Test Lab administrados por Gradle que configuraste ejecuten tus pruebas, usa el siguiente comando. device-name es el nombre del dispositivo que configuraste en la secuencia de comandos de compilación de Gradle, como ftlDevice, y BuildVariant es la variante de compilación de la app que quieres probar. Ten en cuenta que Gradle no ejecuta pruebas de manera simultánea ni admite otros parámetros de configuración de Google Cloud CLI para dispositivos de Test Lab.

    En Windows:

    gradlew device-nameBuildVariantAndroidTest

    En Linux o macOS:

    ./gradlew device-nameBuildVariantAndroidTest

    El resultado de la prueba incluye una ruta de acceso a un archivo HTML con el informe de la prueba. También puedes importar los resultados de la prueba a Android Studio para analizarlos en detalle. Para ello, haz clic en Run > Test History en el IDE.

    Crea y ejecuta pruebas en un grupo de dispositivos

    Para escalar tus pruebas, agrega varios dispositivos de Firebase Test Lab administrados por Gradle a un grupo de dispositivos y, luego, realiza pruebas en todos ellos con un solo comando. Supongamos que tienes varios dispositivos configurados de la siguiente manera:

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

    Para agregarlos a un grupo de dispositivos denominados samsungGalaxy, usa el bloque 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"])
        }
      }
    }
  }
}

    Para ejecutar pruebas en todos los dispositivos del grupo de dispositivos, usa el siguiente comando:

    En Windows:

    gradlew group-nameGroupBuildVariantAndroidTest

    En Linux o macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest

    Optimiza las ejecuciones de pruebas con la fragmentación inteligente

    Las pruebas de dispositivos de Test Lab administrados por Gradle ahora admiten la fragmentación inteligente. La fragmentación inteligente distribuye, en forma automática, tus pruebas entre fragmentos de manera que cada uno se ejecute aproximadamente por el mismo tiempo, lo que reduce los esfuerzos de asignación manual y la duración general de la ejecución de prueba. La fragmentación inteligente usa tu historial de pruebas o la información sobre cuánto tiempo tardaron en ejecutarse tus pruebas, para distribuirlas de manera óptima. Ten en cuenta que necesitas la versión 0.0.1-alpha05 del complemento de Gradle para que Firebase Test Lab use la fragmentación inteligente.

    Para habilitar la fragmentación inteligente, especifica el tiempo que deberían tardar las pruebas dentro de cada fragmento. Debes establecer la duración objetivo de los fragmentos en, al menos, cinco minutos menos que timeoutMinutes para evitar la situación en la que se cancelen los fragmentos antes de que puedan finalizar las pruebas.

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

    Para obtener más información, lee sobre las nuevas opciones de DSL.

    Actualización de DSL para dispositivos de Firebase Test Lab administrados por Gradle

    Hay más opciones de DSL que puedes configurar para personalizar las ejecuciones de prueba o migrar desde otras soluciones que quizás ya estés usando. Consulta algunas de estas opciones, como se describe en el siguiente fragmento de código.

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