Android Studio Iguana | 2023.2.1

Android Studio est l'IDE officiel pour le développement Android. Il inclut tout ce dont vous avez besoin pour compiler des applications Android.

Cette page présente les nouvelles fonctionnalités et améliorations de la dernière version stable d'Android Studio Iguana. Vous pouvez la télécharger ici ou effectuer la mise à jour dans Android Studio en cliquant sur Help > Check for updates (Aide > Rechercher les mises à jour) ou dans Android Studio > Check for updates sous macOS.

Pour voir les corrections apportées à cette version d'Android Studio, consultez les problèmes résolus.

Pour afficher les notes de version d'anciennes versions d'Android Studio, consultez la page Versions précédentes.

Pour un accès anticipé aux fonctionnalités et améliorations à venir, consultez les versions Preview d'Android Studio.

Si vous rencontrez des problèmes dans Android Studio, consultez les pages Problèmes connus ou Résoudre des problèmes.

Compatibilité entre le plug-in Android Gradle et Android Studio

Le système de compilation Android Studio est basé sur Gradle, et le plug-in Android Gradle (AGP) ajoute plusieurs fonctionnalités spécifiques à la compilation d'applications Android. Le tableau suivant indique la version de l'AGP requise pour chaque version d'Android Studio.

Version d'Android Studio Version de l'AGP requise
Jellyfish | 2023.3.1 3,2 à 8,4
Iguana | 2023.2.1 3.2-8.3
Hedgehog | 2023.1.1 3.2-8.2
Giraffe | 2022.3.1 3.2-8.1
Flamingo | 2022.2.1 3.2-8.0
Electric Eel | 2022.1.1 3.2-7.4

Anciennes versions

Version d'Android Studio Version de l'AGP requise
Dolphin | 2021.3.1 3.2-7.3
Chipmunk | 2021.2.1 3.2-7.2
Bumblebee | 2021.1.1 3.2-7.1
Arctic Fox | 2020.3.1 3.1-7.0

Pour en savoir plus sur les nouveautés du plug-in d'Android Gradle, consultez les notes de version du plug-in d'Android Gradle.

Versions minimales des outils pour le niveau d'API Android

Il existe des versions minimales d'Android Studio et d'AGP compatibles avec un niveau d'API spécifique. L'utilisation de versions antérieures d'Android Studio ou d'AGP à celles requises par les éléments targetSdk ou compileSdk de votre projet pourrait entraîner des problèmes inattendus. Nous vous recommandons d'utiliser la dernière version preview d'Android Studio et d'AGP pour travailler sur des projets qui ciblent les versions preview de l'OS Android. Vous pouvez installer des versions preview d'Android Studio en plus d'une version stable.

Les versions minimales d'Android Studio et d'AGP sont les suivantes :

Niveau d'API Version minimale d'Android Studio Version minimale d'AGP
Aperçu de VanillaIceCream Jellyfish | 2023.3.1 8,4
34 Hedgehog | 2023.1.1 8.1.1
33 Flamingo | 2022.2.1 7,2

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

Versions de correctif

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

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

Cette mise à jour mineure inclut ces corrections de bugs.

Intégration du système de contrôle des versions dans les insights sur la qualité des applications

Grâce aux insights sur la qualité des applications, vous pouvez désormais passer d'une trace de la pile Crashlytics au code correspondant au moment où le plantage s'est produit. AGP associe les données de hachage du commit Git aux rapports d'erreur, ce qui permet à Android Studio d'accéder à votre code et de vous montrer comment il se trouvait dans la version où le problème est survenu. Lorsque vous consultez un rapport d'erreur dans App Quality Insights (Insights sur la qualité des applications), vous pouvez choisir d'accéder à la ligne de code de votre règlement Git actuel ou d'afficher les différences entre le règlement actuel et la version de votre codebase qui a généré le plantage.

Pour intégrer votre système de contrôle des versions aux insights sur la qualité des applications, vous devez disposer de la configuration minimale suivante:

Pour utiliser l'intégration du contrôle des versions pour un type de compilation débogable, activez l'option vcsInfo dans le fichier de compilation au niveau du module. Pour les versions (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 créez votre application et la publiez sur Google Play, les rapports d'erreur incluent les données nécessaires pour que l'IDE soit associé aux versions précédentes de votre application à partir de la trace de la pile.

Afficher les variantes de plantage Crashlytics dans les insights sur la qualité des applications

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

Vérification de l'interface utilisateur de 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 de Compose. Cette fonctionnalité est semblable à l'intégration des fonctions d'analyse lint visuelles et aux vérifications d'accessibilité pour les vues. Lorsque vous activez le mode de vérification de l'interface utilisateur de 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, tels que 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 de Compose et envoyez vos commentaires:

Cliquez sur le bouton "Mode de contrôle" de l'interface utilisateur de Compose pour activer la vérification.

Problèmes connus liés au mode de vérification de l'interface utilisateur:

  • Le problème sélectionné dans le panneau risque de ne plus être sélectionné
  • L'option"Supprimer la règle" ne fonctionne pas.
Mode de vérification de l'interface utilisateur de Compose activé avec les 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. Nous nous efforçons constamment d'améliorer les performances des aperçus. C'est pourquoi nous réduisons délibérément la qualité d'affichage de tout aperçu qui n'est plus visible afin d'économiser la mémoire utilisée.

Cette fonctionnalité est développée dans le but d'améliorer la facilité d'utilisation des aperçus, car ils peuvent gérer davantage d'aperçus en même temps dans un fichier. Essayez-la dès aujourd'hui et envoyez vos commentaires.

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.

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 l'assistant de nouveau module (File > New > New Module (Fichier > Nouveau > Nouveau module).

Ce modèle configure votre projet pour qu'il soit compatible avec les profils de référence. Il utilise le nouveau plug-in Baseline Profiles Gradle, qui automatise le processus de configuration de votre projet de la manière requise avec une 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 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épliage 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 de l'interface utilisateur a lieu à 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
  • Android Emulator 33.1.10 ou version ultérieure
  • Appareil virtuel Android exécutant le niveau d'API 24 ou supérieur

Configurer votre projet pour l'API Espresso Device

Pour configurer votre projet afin qu'il soit compatible avec l'API Espresso Device, procédez comme suit:

  1. Pour permettre la transmission des commandes de test à l'appareil de test, ajoutez les autorisations INTERNET et ACCESS_NETWORK_STATE 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 fichier gradle.properties:

      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.5.1")
      }

    Groovy

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

Tester les modifications de configuration courantes

L'API Espresso Device propose plusieurs orientations d'écran et états de pliable que vous pouvez utiliser pour simuler des changements de configuration d'appareil.

Tester la rotation de l'écran

Voici un exemple de test de ce qu'il advient de 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 en 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 en mode paysage pendant l'exécution du test:

      @Test
      fun myRotationTest() {
        ...
        // Sets the device to landscape orientation during test execution.
        onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
        ...
      }
  3. Après la rotation de l'écran, 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épliage de l'écran

Voici un exemple de test du comportement de votre application si elle est installée sur un appareil pliable et que l'écran se déplie:

  1. Commencez par effectuer un test avec l'appareil plié en appelant onDevice().setClosedMode(). Assurez-vous que la mise en page de votre application s'adapte à la largeur de l'écran de format compact:

      @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 agrandie:

      @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 lanceur de test ignore automatiquement l'exécution des tests sur les appareils non 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 des appareils compatibles avec le déploiement dans une configuration plate, ajoutez le code @RequiresDeviceMode suivant à votre test:

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