Android Studio Iguana | 2023.2.1 (febrero de 2024)

Las siguientes son funciones nuevas de Android Studio Iguana.

Versiones de parches

La siguiente es una lista de las versiones de parches de Android Studio Iguana y el complemento de Android para Gradle 8.3.

Android Studio Iguana | 2023.2.1, parche 2 y AGP 8.3.2 (abril de 2024)

Esta actualización menor incluye estas correcciones de errores.

Android Studio Iguana | 2023.2.1, parche 1 y AGP 8.3.1 (marzo de 2024)

Esta actualización menor incluye estas correcciones de errores.

Actualización de la plataforma IntelliJ IDEA 2023.2

Android Studio Iguana incluye las actualizaciones de IntelliJ IDEA 2023.2, 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.2.

Integración del sistema de control de versiones en App Quality Insights

App Quality Insights ahora te permite navegar desde un seguimiento de pila de Crashlytics hasta el código pertinente, en el momento en que ocurrió el bloqueo. AGP adjunta datos de hash de confirmación de Git a los informes de fallas, lo que ayuda a Android Studio a navegar a tu código y mostrar cómo estaba en la versión en la que ocurrió el problema. Cuando ves un informe de fallas en App Quality Insights, puedes elegir navegar a la línea de código en tu confirmación de Git actual o ver una diferencia entre la confirmación actual y la versión de tu base de código que generó la falla.

Para integrar tu sistema de control de versiones con App Quality Insights, necesitas los siguientes requisitos mínimos:

Para usar la integración del control de versiones para un tipo de compilación depurable, habilita la marca vcsInfo en el archivo de compilación a nivel del módulo. Para las compilaciones de lanzamiento (no depurables), la marca está habilitada de forma predeterminada.

Kotlin

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}

Groovy

android {
  buildTypes {
    debug {
      vcsInfo {
        include true
      }
    }
  }
}

Ahora, cuando compilas tu app y la publicas en Google Play, los informes de fallas incluyen los datos necesarios para que el IDE se vincule a versiones anteriores de tu app desde el seguimiento de pila.

Cómo ver las variantes de fallas de Crashlytics en App Quality Insights

Para ayudarte a analizar las causas raíz de una falla, ahora puedes usar App Quality Insights para ver eventos por variantes de problemas o grupos de eventos que comparten seguimientos de pila similares. Para ver eventos en cada variante de un informe de fallas, selecciona una variante en el menú desplegable. Para agregar información de todas las variantes, selecciona All.

Verificación de la IU de Compose

Para ayudar a los desarrolladores a compilar IUs más adaptables y accesibles en Jetpack Compose, Android Studio Iguana Canary 5 introdujo un nuevo modo de verificación de la IU en la vista previa de Compose. Esta función funciona de manera similar a las integraciones de lint visual y las verificaciones de accesibilidad para las vistas. Cuando activas el modo de verificación de la IU de Compose, Android Studio audita automáticamente tu IU de Compose y verifica si hay problemas de accesibilidad y adaptabilidad en diferentes tamaños de pantalla, como texto estirado en pantallas grandes o contraste de color bajo. El modo destaca los problemas encontrados en diferentes configuraciones de vista previa y los enumera en el panel de problemas.

Para probar esta función hoy, haz clic en el botón de verificación de la IU en la vista previa de Compose y envía tus comentarios:

Haz clic en el botón de modo de verificación de la IU de Compose para activar la verificación.

Problemas conocidos del modo de verificación de la IU:

  • El problema seleccionado en el panel de problemas podría perder el enfoque.
  • "Suppress rule" no funciona.
Modo de verificación de la IU de Compose activado con detalles en el panel de problemas.

Renderización progresiva para la vista previa de Compose

Android Studio Iguana Canary 3 introduce la renderización progresiva en la vista previa de Compose. Como parte de un esfuerzo continuo para mejorar el rendimiento de las vistas previas, ahora, para cualquier vista previa que esté fuera de la vista, disminuimos intencionalmente su calidad de renderización para guardar la memoria utilizada.

Esta función se desarrolló con el objetivo de mejorar aún más la usabilidad de las vistas previas, ya que permite controlar más vistas previas al mismo tiempo en un archivo. Pruébala hoy mismo y envía tus comentarios.

Asistente del módulo de perfiles de Baseline

A partir de Android Studio Iguana, puedes generar perfiles de Baseline para tu app con la plantilla Baseline Profile Generator en el nuevo asistente de módulos (File > New > New Module).

Esta plantilla configura tu proyecto para que pueda admitir perfiles de Baseline. Usa el nuevo complemento de Gradle para perfiles de Baseline, que automatiza el proceso de configuración de tu proyecto de la manera requerida con una tarea de Gradle.

La plantilla también crea una configuración de ejecución que te permite generar un perfil de Baseline con un solo clic desde la lista desplegable Select Run/Debug Configuration.

Cómo realizar pruebas en función de los cambios de configuración con la API de Espresso Device

Usa la API de Espresso Device para probar tu app cuando el dispositivo experimenta cambios de configuración comunes, como la rotación y el despliegue de la pantalla. La API de Espresso Device te permite simular estos cambios de configuración en un dispositivo virtual y ejecuta tus pruebas de forma síncrona, por lo que solo se realiza una acción o aserción de la IU a la vez, y los resultados de la prueba son más confiables. Obtén más información para escribir pruebas de IU con Espresso.

Para usar la API de Espresso Device, necesitas lo siguiente:

  • Android Studio Iguana o versiones posteriores
  • Complemento de Android para Gradle 8.3 o versiones posteriores
  • Android Emulator 33.1.10 o versiones posteriores
  • Dispositivo virtual de Android que ejecuta el nivel de API 24 o versiones posteriores

Cómo configurar tu proyecto para la API de Espresso Device

Para configurar tu proyecto de modo que admita la API de Espresso Device, haz lo siguiente:

  1. Para permitir que la prueba pase comandos al dispositivo de prueba, agrega los INTERNET y ACCESS_NETWORK_STATE permisos al archivo de manifiesto en el androidTest conjunto de orígenes:

      <uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />

  2. Habilita la marca experimental enableEmulatorControl en el gradle.properties archivo:

      android.experimental.androidTest.enableEmulatorControl=true

  3. Habilita la opción emulatorControl en la secuencia de comandos de compilación a nivel del módulo:

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. En la secuencia de comandos de compilación a nivel del módulo, importa la biblioteca de Espresso Device a tu proyecto:

    Kotlin

      dependencies {
    androidTestImplementation("androidx.test.espresso:espresso-device:3.6.1")
  }

    Groovy

      dependencies {
    androidTestImplementation 'androidx.test.espresso:espresso-device:3.6.1'
  }

Cómo realizar pruebas en función de los cambios de configuración comunes

La API de Espresso Device tiene varios estados de orientación de pantalla y plegables que puedes usar para simular cambios en la configuración del dispositivo.

Cómo realizar pruebas en función de la rotación de la pantalla

A continuación, se muestra un ejemplo de cómo probar lo que sucede con tu app cuando gira la pantalla del dispositivo:

  1. Primero, para obtener un estado inicial coherente, configura el dispositivo en modo vertical:

      import androidx.test.espresso.device.action.ScreenOrientation
  import androidx.test.espresso.device.rules.ScreenOrientationRule
  ...
  @get:Rule
  val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)

  2. Crea una prueba que configure el dispositivo en orientación horizontal durante la ejecución de la prueba:

      @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    ...
  }

  3. Después de que gire la pantalla, verifica que la IU se adapte al nuevo diseño según lo previsto:

      @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
  }

Cómo realizar pruebas en función del despliegue de la pantalla

A continuación, se muestra un ejemplo de cómo probar lo que sucede con tu app si está en un dispositivo plegable y la pantalla se despliega:

  1. Primero, prueba con el dispositivo en estado plegado llamando a onDevice().setClosedMode(). Asegúrate de que el diseño de tu app se adapte al ancho de pantalla compacto:

      @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
    composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
    ...
  }

  2. Para realizar la transición a un estado completamente desplegado, llama a onDevice().setFlatMode(). Verifica que el diseño de la app se adapte a la clase de tamaño expandida:

      @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    ...
    onDevice().setFlatMode()
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
  }

Especifica qué dispositivos necesitan tus pruebas

Si ejecutas una prueba que realiza acciones de plegado en un dispositivo que no es plegable, la prueba suele fallar. Para ejecutar solo las pruebas que son pertinentes para el dispositivo en ejecución, usa la anotación @RequiresDeviceMode. El ejecutor de pruebas omite automáticamente la ejecución de pruebas en dispositivos que no admiten la configuración que se está probando. Puedes agregar la regla de requisito del dispositivo a cada prueba o a una clase de prueba completa.

Por ejemplo, para especificar que una prueba solo se debe ejecutar en dispositivos que admitan el despliegue a una configuración plana, agrega el siguiente código @RequiresDeviceMode a tu prueba:

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
  ...
}