Android Studio Iguana | 2023.2.1 (févr. 2024)

Voici les nouvelles fonctionnalités d'Android Studio Iguana.

Versions de correctif

Voici une liste des versions de correctif dans Android Studio Iguana et dans le plug-in Android Gradle 8.3.

Android Studio Iguana | Correctif 2 de la version 2023.2.1 et AGP 8.3.2 (avril 2024)

Cette mise à jour mineure inclut ces corrections de bugs.

Android Studio Iguana | Correctif 1 de la version 2023.2.1 et AGP 8.3.1 (mars 2024)

Cette mise à jour mineure inclut ces corrections de bugs.

Mise à jour de la plate-forme IntelliJ IDEA 2023.2

Android Studio Iguana inclut les mises à jour d'IntelliJ IDEA 2023.2, qui améliorent l'expérience IDE de Studio. Pour en savoir plus sur les modifications, consultez les notes de version d'IntelliJ IDEA 2023.2.

Intégration du système de contrôle des versions dans App Quality Insights

App Quality Insights vous permet désormais de passer d'une trace de la pile Crashlytics au code concerné, au moment où le plantage s'est produit. AGP associe les données de hachage de commit Git aux rapports de plantage, ce qui permet à Android Studio d'accéder à votre code et d'afficher la version dans laquelle le problème s'est produit. Lorsque vous consultez un rapport de plantage dans App Quality Insights, vous pouvez choisir d'accéder à la ligne de code dans votre extraction Git actuelle ou d'afficher une différence entre l'extraction actuelle et la version de votre base de code qui a généré le plantage.

Pour intégrer votre système de contrôle des versions à App Quality Insights, vous devez respecter les exigences minimales suivantes :

Pour utiliser l'intégration du contrôle des versions pour un type de compilation débogable, activez l'indicateur vcsInfo dans le fichier de compilation au niveau du module. Pour les compilations de version (non débogables), l'indicateur est activé par défaut.

Kotlin

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

Groovy

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

Désormais, lorsque vous compilez votre application et la publiez sur Google Play, les rapports d'erreur incluent les données nécessaires à l'IDE pour établir un lien vers les versions précédentes de votre application à partir de la trace de la pile.

Afficher les variantes de plantage Crashlytics dans App Quality Insights

Pour vous aider à analyser les causes profondes d'un plantage, vous pouvez désormais utiliser App Quality Insights pour afficher les événements par variantes de problème, ou groupes d'événements qui partagent des traces de pile similaires. Pour afficher les événements dans chaque variante d'un rapport de plantage, sélectionnez une variante dans le menu déroulant. Pour agréger les informations de toutes les variantes, sélectionnez Tout.

Vérification de l'interface utilisateur Compose

Pour aider les développeurs à créer des interfaces utilisateur plus adaptatives et accessibles dans Jetpack Compose, Android Studio Iguana Canary 5 a introduit un nouveau mode de vérification de l'interface utilisateur dans l'aperçu Compose. Cette fonctionnalité fonctionne de la même manière que les intégrations de linting visuel et de vérification de l'accessibilité pour les vues. Lorsque vous activez le mode de vérification de l'interface utilisateur Compose, Android Studio audite automatiquement votre interface utilisateur Compose et recherche les problèmes d'adaptation et d'accessibilité sur différentes tailles d'écran, comme le texte étiré sur les grands écrans ou le faible contraste des couleurs. Le mode met en évidence les problèmes détectés dans différentes configurations d'aperçu et les répertorie dans le panneau des problèmes.

Essayez cette fonctionnalité dès aujourd'hui en cliquant sur le bouton de vérification de l'interface utilisateur dans l'aperçu Compose et envoyez vos commentaires :

Cliquez sur le bouton du mode de vérification de l’interface utilisateur Compose pour activer la vérification.

Problèmes connus du mode de vérification de l'interface utilisateur :

  • Le problème sélectionné dans le panneau des problèmes peut perdre le focus.
  • La règle de suppression ne fonctionne pas.
Mode de vérification de l'interface utilisateur Compose activé avec des détails dans le panneau des problèmes.

Rendu progressif pour l'aperçu Compose

Android Studio Iguana Canary 3 introduit le rendu progressif dans l'aperçu Compose. Dans le cadre d'un effort continu visant à améliorer les performances des aperçus, nous réduisons désormais volontairement la qualité de rendu de tout aperçu qui n'est pas visible afin d'économiser la mémoire utilisée.

Cette fonctionnalité a pour objectif d'améliorer l'utilisabilité des aperçus en permettant de gérer davantage d'aperçus en même temps dans un fichier. Essayez la dès aujourd'hui et envoyez-nous vos commentaires.

Assistant du module de profils de référence

À partir d'Android Studio Iguana, vous pouvez générer des profils de référence pour votre application à l'aide du modèle Baseline Profile Generator (Générateur de profils de référence) dans le nouvel assistant de module (File > New > New Module [Fichier > Nouveau > Nouveau module]).

Ce modèle configure votre projet afin qu'il puisse prendre en charge les profils de référence. Il utilise le nouveau plug-in Gradle pour les profils de référence, qui automatise le processus de configuration de votre projet de la manière requise avec une seule tâche Gradle.

Le modèle crée également une configuration d'exécution qui vous permet de générer un profil de référence en un seul clic à partir de la liste déroulante Select Run/Debug Configuration (Sélectionner la configuration d'exécution/de débogage).

Tester les modifications de configuration avec l'API Espresso Device

Utilisez l'API Espresso Device pour tester votre application lorsque l'appareil subit des modifications de configuration courantes, telles que la rotation et le déploiement de l'écran. L'API Espresso Device vous permet de simuler ces modifications de configuration sur un appareil virtuel et d'exécuter vos tests de manière synchrone. Ainsi, une seule action ou assertion d'interface utilisateur se produit à la fois, et les résultats de vos tests sont plus fiables. Découvrez comment écrire des tests d'interface utilisateur avec Espresso.

Pour utiliser l'API Espresso Device, vous avez besoin des éléments suivants :

  • Android Studio Iguana ou version ultérieure
  • Plug-in Android Gradle 8.3 ou version ultérieure
  • Émulateur Android 33.1.10 ou version ultérieure
  • Appareil virtuel Android exécutant le niveau d'API 24 ou version ultérieure

Configurer votre projet pour l'API Espresso Device

Pour configurer votre projet afin qu'il prenne en charge l'API Espresso Device, procédez comme suit :

  1. Pour que le test transmette des commandes à l'appareil de test, ajoutez les INTERNET et ACCESS_NETWORK_STATE autorisations au fichier manifeste dans l'ensemble de sources androidTest :

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

  2. Activez l'indicateur expérimental enableEmulatorControl dans le gradle.properties fichier :

      android.experimental.androidTest.enableEmulatorControl=true

  3. Activez l'option emulatorControl dans le script de compilation au niveau du module :

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. Dans le script de compilation au niveau du module, importez la bibliothèque Espresso Device dans votre projet :

    Kotlin

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

    Groovy

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

Tester les modifications de configuration courantes

L'API Espresso Device comporte plusieurs états d'orientation de l'écran et de pliage que vous pouvez utiliser pour simuler des modifications de configuration de l'appareil.

Tester la rotation de l'écran

Voici un exemple de test de ce qui se passe dans votre application lorsque l'écran de l'appareil pivote :

  1. Tout d'abord, pour un état de départ cohérent, définissez l'appareil sur le mode Portrait :

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

  2. Créez un test qui définit l'appareil sur l'orientation Paysage lors de l'exécution du test :

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

  3. Une fois l'écran pivoté, vérifiez que l'interface utilisateur s'adapte à la nouvelle mise en page comme prévu :

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

Tester le déploiement de l'écran

Voici un exemple de test de ce qui se passe dans votre application si elle se trouve sur un appareil pliable et que l'écran se déplie :

  1. Commencez par tester l'appareil en mode plié en appelant onDevice().setClosedMode(). Assurez-vous que la mise en page de votre application s'adapte à la largeur compacte de l'écran :

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

  2. Pour passer à un état entièrement déplié, appelez onDevice().setFlatMode(). Vérifiez que la mise en page de l'application s'adapte à la classe de taille étendue :

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

Spécifier les appareils dont vos tests ont besoin

Si vous exécutez un test qui effectue des actions de pliage sur un appareil qui n'est pas pliable, le test échoue généralement. Pour n'exécuter que les tests pertinents pour l'appareil en cours d'exécution, utilisez l'annotation @RequiresDeviceMode. Le testeur ignore automatiquement l'exécution des tests sur les appareils qui ne sont pas compatibles avec la configuration testée. Vous pouvez ajouter la règle d'exigence de l'appareil à chaque test ou à une classe de test entière.

Par exemple, pour spécifier qu'un test ne doit être exécuté que sur les appareils qui prennent en charge le déploiement dans une configuration à plat, ajoutez le code @RequiresDeviceMode suivant à votre test :

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