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 parche 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 al código relevante, en el momento en que se produjo la falla. 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 era en la versión en la que se produjo el problema. Cuando veas un informe de fallas en App Quality Insights, puedes 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 de control de versión 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 vincule a versiones anteriores de tu app desde el seguimiento de pila.

Consulta 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 los eventos por variantes de problemas o grupos de eventos que comparten seguimientos de pila similares. Para ver los 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 Todas.

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 IU en la vista previa de Compose. Esta función funciona de manera similar al análisis con lint visual y a las integraciones de verificaciones de accesibilidad para vistas. Cuando activas el modo de verificación de la IU de Compose, Android Studio audita automáticamente la IU de Compose y busca problemas de adaptabilidad y accesibilidad en diferentes tamaños de pantalla, como texto estirado en pantallas grandes o contraste de colores bajo. El modo destaca los problemas encontrados en diferentes configuraciones de vista previa y los muestra en el panel de problemas.

Para probar esta función hoy mismo, 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:

  • Es posible que el problema seleccionado en el panel de problemas pierda el enfoque.
  • La opción "Ocultar regla" no funciona
Se activó el modo de verificación de la IU de Compose con detalles en el panel de problemas.

Renderización progresiva para la vista previa de Compose

Android Studio Iguana Canary 3 presenta 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 no esté a la vista, disminuimos de forma intencional su calidad de renderización para ahorrar memoria.

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íanos 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 asistente de módulos nuevos (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 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, de modo que solo se produce una acción o aserción de la IU a la vez y los resultados de las pruebas son más confiables. Obtén más información para escribir pruebas de la 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
  • Un dispositivo virtual de Android que ejecute el nivel de API 24 o una versión posterior

Configura 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 permisos INTERNET y ACCESS_NETWORK_STATE al archivo de manifiesto en el conjunto de orígenes androidTest:

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

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

      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 con cambios de configuración comunes

La API de Espresso Device tiene varias orientaciones de pantalla y estados plegables que puedes usar para simular los cambios de configuración del dispositivo.

Prueba la rotación de pantalla

Este es un ejemplo de cómo probar lo que sucede con tu app cuando la pantalla del dispositivo gira:

  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 la pantalla gire, verifica que la IU se adapte al nuevo diseño como se espera:

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

Prueba el despliegue de la pantalla

Este es 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, llama a onDevice().setClosedMode() para probar con el dispositivo en el estado plegado. Asegúrate de que el diseño de tu app se adapte al ancho compacto de la pantalla:

      @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(). Comprueba que el diseño de la app se adapte a la clase de tamaño expandido:

      @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, por lo general, la prueba falla. Para ejecutar solo las pruebas que son relevantes para el dispositivo en ejecución, usa la anotación @RequiresDeviceMode. El ejecutor de pruebas omite automáticamente las pruebas en dispositivos que no admiten la configuración que se está probando. Puedes agregar la regla de requisitos de dispositivo a cada prueba o a toda una clase de prueba.

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

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