Problèmes connus concernant Android Studio et le plug-in Android Gradle

Cette page recense les problèmes connus liés à Android Studio Ladybug et au plug-in Android Gradle 8.7.0. Si vous rencontrez un problème qui n'est pas encore mentionné ici, veuillez signaler un bug.

Mise à niveau vers la version preview : chaque version d'Android Studio et du plug-in Android Gradle vise à améliorer la stabilité et les performances, et à ajouter de nouvelles fonctionnalités. Pour profiter des avantages des versions à venir, téléchargez et installez la version preview d'Android Studio.

Problèmes connus concernant Android Studio

Cette section décrit les problèmes connus de la dernière version stable d'Android Studio.

"Apply Changes & Restart Activity" (Appliquer les modifications et redémarrer l'activité) ne redémarre pas l'activité sur les appareils ou les émulateurs avec le niveau d'API 35

Lorsque vous déployez des modifications de code sur un appareil utilisant l'API 35 avec "Apply Changes & Restart Activity" (Appliquer les modifications et redémarrer l'activité), l'application ne redémarre pas, et vous ne verrez pas l'effet des modifications. Si vous réexécutez l'application, vous verrez l'effet des modifications du code. Notre équipe étudie actuellement ce problème.

Fenêtre Firebase Assistant affichant un message d'erreur

Si la fenêtre Firebase Assistant [Tools > Firebase (Outils > Firebase) depuis le menu principal] affiche un message d'erreur, invalidez les caches et redémarrez Android Studio pour corriger l'erreur.

Impossible d'isoler une vue à l'aide de l'outil d'inspection de la mise en page

La possibilité d'isoler une vue à l'aide de l'outil d'inspection de la mise en page intégré est temporairement indisponible. Nous nous efforçons de résoudre ce problème dans une prochaine version.

Impossible d'inspecter tous les nœuds Compose à l'aide de l'outil d'inspection de la mise en page

Si vous constatez que tous les nœuds Compose ne peuvent pas être inspectés lorsque vous utilisez l'outil d'inspection de la mise en page, cela est probablement dû à un bug qui a été corrigé dans la version 1.5.0-alpha04 de Compose. Si vous rencontrez ce problème, veillez à effectuer la mise à niveau vers la version 1.5.0-alpha04 ou ultérieure de Compose.

Erreur lors de l'affichage de l'aperçu de Compose

À partir d'Android Studio Chipmunk, si java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner ou java.lang.ClassNotFoundException: androidx.savedstate.R$id s'affiche dans le panneau des problèmes, veillez à inclure une dépendance debugImplementation à androidx.lifecycle:lifecycle-viewmodel-savedstate dans votre module.

Si java.lang.NoSuchFieldError: view_tree_lifecycle_owner s'affiche dans le panneau des problèmes, veillez à inclure une dépendance debugImplementation à androidx.lifecycle:lifecycle-runtime dans votre module.

Si java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer ou java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener s'affiche dans le panneau des problèmes, veillez à inclure une dépendance debugImplementation à androidx.customview:customview-poolingcontainer dans votre module.

Erreur lors de l'utilisation de mots de passe différents pour la clé et le keystore

À partir de la version 4.2, Android Studio s'exécute maintenant sur JDK 11. Cette modification entraîne un changement de comportement sous-jacent lié aux clés de signature.

Lorsque vous accédez à Build > Generate Signed Bundle / APK (Compiler > Générer un bundle/APK signé) et que vous essayez de configurer la signature d'application pour un app bundle ou un APK, la saisie de mots de passe différents pour la clé et le keystore peut entraîner l'erreur suivante :

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

Pour contourner ce problème, saisissez le même mot de passe pour la clé et le keystore.

Android Studio ne démarre pas après l'installation de la version 4.2

Studio essaie d'importer les .vmoptions précédentes et de les nettoyer pour qu'elles fonctionnent avec le récupérateur de mémoire utilisé par JDK 11. Si ce processus échoue, l'IDE peut ne pas démarrer pour certains utilisateurs qui ont défini des options de VM personnalisées dans le fichier .vmoptions.

Pour contourner ce problème, nous vous recommandons de mettre en commentaire les options personnalisées dans .vmoptions (en utilisant le caractère "#"). Le fichier .vmoptions se trouve aux emplacements suivants :

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

Si Studio ne démarre toujours pas après cette solution, consultez Studio ne démarre pas après la mise à niveau ci-dessous.

Plantage des applications utilisant l'outil d'inspection de bases de données sur l'émulateur Android 11

Les applications qui utilisent l'outil d'inspection de bases de données peuvent planter lorsqu'elles sont exécutées sur l'émulateur Android 11, et une erreur semblable à la suivante peut s'afficher dans logcat :

 Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

Pour résoudre ce problème, mettez à niveau votre émulateur Android 11 vers la version 9 ou une version ultérieure en accédant à Tools > SDK Manager (Outils > SDK Manager). Dans l'onglet SDK Platforms (Plates-formes SDK), cochez la case Show Package Details (Afficher les détails du package), puis sélectionnez la révision 9 ou ultérieure de l'émulateur Android 11.

Studio ne démarre pas après la mise à niveau

Si Studio ne démarre pas après une mise à niveau, le problème peut être dû à une configuration Android Studio non valide importée à partir d'une version précédente d'Android Studio ou à un plug-in incompatible. Pour contourner ce problème, essayez de supprimer (ou de renommer à des fins de sauvegarde) le répertoire ci-dessous, en fonction de la version et du système d'exploitation d'Android Studio, puis redémarrez Android Studio. Cette action rétablit les paramètres par défaut d'Android Studio, en supprimant tous les plug-ins tiers.

Pour Android Studio 4.1 et versions ultérieures :

  • Windows : %APPDATA%\Google\AndroidStudio<version>
    Exemple : C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1

  • macOS : ~/Library/Application Support/Google/AndroidStudio<version>
    Exemple : ~/Library/Application Support/Google/AndroidStudio4.1

  • Linux : ~/.config/Google/AndroidStudio<version> et ~/.local/share/Google/AndroidStudio<version>
    Exemple : ~/.config/Google/AndroidStudio4.1 et ~/.local/share/Google/AndroidStudio4.1

Pour Android Studio 4.0 et versions antérieures :

  • Windows : %HOMEPATH%\.AndroidStudio<version>\config
    Exemple : C:\Users\your_user_name\.AndroidStudio3.6\config

  • macOS : ~/Library/Preferences/AndroidStudio<version>
    Exemple : ~/Library/Preferences/AndroidStudio3.6

  • Linux : ~/.AndroidStudio<version>/config
    Exemple : ~/.AndroidStudio3.6/config

Notez que le répertoire de configuration des versions Canary et Bêta d'Android Studio est le suivant : PreviewX.Y plutôt que X.Y pour <version>. Par exemple, les builds Canary d'Android Studio 4.1 utilisent AndroidStudioPreview4.1 plutôt que le répertoire AndroidStudio4.1, qui est utilisé pour les versions candidates et stables.

Problème de compilation dans les projets multiplateformes Kotlin

Des erreurs de compilation peuvent se produire dans le code MPP de Kotlin en raison de symboles manquants. La mise à niveau de votre plug-in Kotlin vers la version 1.4 devrait résoudre le problème.

Conflits de mappage de clés sous Linux

Sous Linux, certains raccourcis clavier sont en conflit avec les raccourcis clavier Linux par défaut et ceux des gestionnaires de fenêtres courants, tels que KDE et GNOME. Ces raccourcis clavier peuvent ne pas fonctionner comme prévu dans Android Studio.

Vous trouverez plus d'informations sur ce problème (ainsi que des solutions éventuelles) dans l'outil de suivi des bugs d'IntelliJ.

Petit texte d'interface utilisateur sous ChromeOS

Sous ChromeOS, le texte peut être beaucoup plus petit que dans les versions précédentes. Pour contourner ce problème, procédez comme suit :

  1. Ouvrez la fenêtre Paramètres en cliquant sur Fichier > Paramètres.
  2. Accédez à Apparence et comportement > Apparence.
  3. Sélectionnez Utiliser une police personnalisée.
  4. Augmentez la taille de la police.
  5. Dans la fenêtre Paramètres, accédez à Éditeur > Police.
  6. Augmentez la taille de la police.
  7. Cliquez sur OK.

Modification du code

Cette section décrit les problèmes connus liés à l'éditeur de code.

Saisie figée – Problèmes "iBus" sous Linux

Il existe des interactions connues entre le daemon iBus sous Linux et Android Studio. Dans certains scénarios, l'IDE cesse de répondre à la saisie au clavier ou commence à saisir des caractères aléatoires. Ce bug découle d'une synchronisation manquante entre iBus et XLib + AWT, et il a déjà été signalé en amont dans JetBrains et iBus. Trois solutions permettent actuellement de contourner ce problème :

  • Solution 1 : Forcez iBus à passer en mode synchrone. Avant de démarrer Android Studio, exécutez la commande suivante dans la ligne de commande : 
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Solution 2 : Désactivez la saisie iBus dans Android Studio. Pour désactiver la saisie iBus pour Android Studio uniquement, exécutez la commande suivante dans la ligne de commande : 
    $ XMODIFIERS= ./bin/studio.sh
    Cette solution de contournement ne désactive les modes de saisie que pour Android Studio, et non pour les autres applications que vous exécutez. Notez que si vous redémarrez le daemon pendant qu'Android Studio est en cours d'exécution (par exemple, en exécutant ibus-daemon -rd), vous désactivez les modes de saisie pour toutes les autres applications et vous risquez de faire planter la JVM d'Android Studio en raison d'une erreur de segmentation.
  • Solution 3 : Vérifiez les liaisons de raccourci pour vous assurer que le raccourci d'entrée suivant n'est pas défini sur Ctrl+Espace, car il s'agit également du raccourci de saisie de code dans Android Studio. Ubuntu 14.04 (Trusty) fait de Super+Espace le raccourci par défaut, mais les paramètres des versions précédentes peuvent encore être présents. Pour vérifier vos liaisons de raccourci, exécutez ibus-setup sur la ligne de commande afin d'ouvrir la fenêtre des préférences IBus. Sous Raccourcis clavier, cochez Mode de saisie suivant. S'il est défini sur Ctrl+Espace, remplacez-le par Super+Space ou un autre raccourci de votre choix.

Configuration du projet

Cette section décrit les problèmes connus liés à la configuration du projet et à la synchronisation Gradle.

Échec de la synchronisation Gradle : Canal endommagé

Le problème réside dans le fait que le daemon Gradle essaie d'utiliser IPv4 au lieu d'IPv6.

  • Solution 1 : Sous Linux, placez le code suivant dans ~/.profile ou ~/.bash_profile : 
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • Solution 2 : Dans le fichier vmoptions d'Android Studio, remplacez la ligne -Djava.net.preferIPv4Addresses=true par -Djava.net.preferIPv6Addresses=true. Pour plus d'informations, consultez la page concernant le Guide de l'utilisateur de mise en réseau IPv6.

Erreurs "application similaire non authentifiée" de la synchronisation Gradle ou de SDK Manager

La cause première de ces erreurs est l'absence de certificat dans $JAVA_HOME/jre/lib/certificates/cacerts. Pour résoudre ces erreurs, procédez comme suit :

  • Si vous utilisez un proxy, essayez de vous connecter directement. Si la connexion directe fonctionne, vous devrez peut-être utiliser keytool pour ajouter le certificat du serveur proxy au fichier cacerts afin de vous connecter via le proxy.
  • Réinstallez un JDK pris en charge et non modifié. Un problème connu affectant les utilisateurs d'Ubuntu entraîne un /etc/ssl/certs/java/cacerts vide. Pour contourner ce problème, exécutez la commande suivante dans la ligne de commande : 
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Déploiement

Cette section décrit les problèmes connus liés au déploiement de votre application sur un appareil connecté.

[Mac OS uniquement] Les mises à jour incrémentielles ne sont pas appliquées en raison d'un problème de surveillance des fichiers Gradle lié aux projets enregistrés sous /System/Volumes/Data

Le problème Gradle 18149 affecte le plug-in Android Gradle 7.0 ou version ultérieure, car elles requièrent Gradle version 7.0 ou ultérieure. À partir de la version 7.0 de Gradle, la surveillance des fichiers est activée par défaut. Si vous utilisez Mac OS et que votre projet est enregistré sous /System/Volumes/Data, la surveillance des fichiers Gradle ne suit pas correctement les modifications de fichiers. Le système de compilation ne détecte aucune modification de fichier et ne met donc pas à jour l'APK. Dès lors, le code de déploiement incrémentiel ne fonctionne pas, car l'état de l'APK local est le même que sur l'appareil.

Pour contourner ce problème, vous devez déplacer le répertoire de votre projet vers votre répertoire utilisateur, à savoir sous /Users/username. Le système de compilation est alors informé des modifications de fichiers effectuées par Gradle et les modifications incrémentielles sont appliquées.

Android Emulator HAXM sous macOS High Sierra

Android Emulator sous macOS Sierra (10.13) nécessite HAXM 6.2.1 (ou version ultérieure) pour une meilleure compatibilité et stabilité avec macOS. Cependant, macOS 10.13 impose un processus plus complexe pour installer des extensions de noyau telles que HAXM. Vous devez autoriser manuellement l'installation des extensions de noyau comme suit :

  1. Commencez par essayer d'installer la dernière version de HAXM à partir de SDK Manager.
  2. Sous macOS, accédez à Préférences système > Sécurité et confidentialité.

  3. Si vous voyez une alerte indiquant que le chargement du logiciel système du développeur "Applications Intel Corporation" a été bloqué, cliquez sur Allow (Autoriser) :

Pour plus d'informations et obtenir des solutions, consultez cette page Web Apple et le problème 62395878.

Appliquer les modifications

Cette section décrit les problèmes connus liés à l'application des modifications.

Nouveau nom d'application non appliqué

Si vous renommez votre application, puis essayez d'appliquer cette modification, le nouveau nom peut ne pas être reflété. Pour contourner ce problème, cliquez sur Exécuter Icône Exécuter afin de redéployer votre application et d'afficher vos modifications.

Un problème dans Android Runtime provoque une erreur

Si vous utilisez un appareil exécutant Android 8.0 ou 8.1, vous pouvez recevoir des messages "VERIFICATION_ERROR" lorsque vous essayez d'appliquer certains types de modifications (en particulier si vous utilisez Kotlin). Ce message est dû à un problème lié à Android Runtime résolu dans Android 9.0 et versions ultérieures. Bien que le problème entraîne l'échec de l'option Appliquer les modifications, vous pouvez toujours exécuterIcône Exécuter l'application pour voir vos modifications. Toutefois, nous vous recommandons de mettre à jour l'appareil vers Android 9.0 ou version ultérieure.

Débogage et test

Cette section décrit les problèmes connus liés au débogage et au test de votre application.

JUnit teste les ressources manquantes dans classpath lorsqu'il est exécuté à partir d'Android Studio

Si vos modules Java contiennent des dossiers de ressources spécifiques, ces ressources sont introuvables lors de l'exécution des tests à partir de l'IDE. Vous pouvez exécuter des tests en utilisant Gradle à partir de la ligne de commande. L'exécution de la tâche check Gradle à partir de l'IDE fonctionne également. Pour en savoir plus, consultez la page concernant le problème 64887.

Ce problème est dû au fait qu'à partir d'IntelliJ 13, vous n'avez qu'un seul dossier pour "classpath". Le compilateur IntelliJ copie toutes les ressources dans ce dossier de compilation, mais Gradle ne copie pas les ressources.

  • Solution de contournement 1 : Exécutez la tâche check Gradle à partir de l'IDE plutôt que d'exécuter un test unitaire.
  • Solution de contournement 2 : Mettez à jour votre script de compilation pour copier manuellement les ressources dans le dossier de compilation. Pour plus d'informations, consultez le commentaire 13.

Les tests JUnit peuvent compiler le code deux fois

Lors de la création d'un projet, le modèle de configuration JUnit peut être créé en deux étapes "Avant le lancement" : Création et Création basée sur Gradle. Cette configuration est ensuite étendue à toutes les configurations d'exécution JUnit créées.

  • Pour résoudre le problème dans le projet en cours, cliquez sur Run > Edit Configurations (Exécuter > Modifier les configurations), puis modifiez la configuration JUnit par défaut pour n'inclure que l'étape de création basée sur Gradle.
  • Pour corriger le problème pour tous les futurs projets, cliquez sur File > Close Project (Fichier > Fermer le projet). L'écran de bienvenue doit s'afficher. Cliquez ensuite sur Configure > Project Defaults > Run Configurations (Configurer > Paramètres par défaut du projet > Exécuter les configurations) et modifiez la configuration JUnit pour n'inclure que l'étape de création basée sur Gradle.

Certaines configurations d'exécution de test ne fonctionnent pas

Toutes les configurations d'exécution disponibles lorsque vous effectuez un clic droit sur une méthode de test ne sont pas valides. Plus précisément, les configurations suivantes ne sont pas valides :

  • Les configurations d'exécution Gradle (qui portent le logo Gradle) ne fonctionnent pas.
  • Les configurations d'exécution JUnit (accompagnées d'une icône sans le vert d'Android) ne s'appliquent pas aux tests d'instrumentation, qui ne peuvent pas être exécutés sur la JVM locale.
Android Studio mémorise également la configuration d'exécution créée dans un contexte donné (par exemple, un clic droit sur une classe ou une méthode spécifique) et ne propose pas de s'exécuter dans une configuration différente ensuite. Pour résoudre ce problème, cliquez sur Run > Edit Configurations (Exécuter > Modifier les configurations), puis supprimez les configurations créées de manière incorrecte.

Ajouter des points d'arrêt Java lors du débogage du code natif

Lorsque votre application est en pause à un point d'arrêt dans votre code natif, les débogueurs Auto et Dual peuvent ne pas reconnaître immédiatement les nouveaux points d'arrêt Java que vous avez définis. Pour éviter ce problème, ajoutez des points d'arrêt Java avant de démarrer une session de débogage ou lorsque l'application est mise en pause sur un point d'arrêt Java. Pour en savoir plus, consultez le problème 229949.

Quitter le débogueur natif

Lorsque vous utilisez le débogueur Auto ou Dual pour déboguer Java et le code natif, si vous accédez à une fonction nativedepuis votre code Java (par exemple, le débogueur met en pause l'exécution sur une ligne de votre code Java qui appelle une fonction native et vous cliquez sur Accéder à ) et que vous souhaitez revenir à votre code Java, cliquez sur Reprendre le programme (plutôt que Quitter ou Passer ). Le processus de votre application est toujours en pause et vous devez cliquer sur Reprendre le programme dans l'onglet your-module-java pour le réactiver. Pour en savoir plus, consultez le problème 224385.

Le débogueur natif se bloque lors du chargement des bibliothèques

Lors de la première utilisation du débogueur natif après une mise à niveau vers Android Studio 4.2 et versions ultérieures, le débogueur natif peut cesser de répondre au moment du chargement des bibliothèques à partir de l'appareil Android. Ce problème persiste même si vous arrêtez et redémarrez le débogueur. Pour le résoudre, supprimez le cache LLDB sur $USER/.lldb/module-cache/.

Le débogueur natif plante et indique "Le processus de débogage s'est terminé avec le code de sortie 127"

Cette erreur se produit sur les plates-formes Linux lors du démarrage du débogueur natif. Elle indique que l'une des bibliothèques requises par le débogueur natif n'est pas installée sur le système local. Le nom de la bibliothèque manquante peut déjà être indiqué dans le fichier idea.log. Si ce n'est pas le cas, vous pouvez utiliser un terminal pour accéder au répertoire d'installation d'Android Studio et exécuter la ligne de commande bin/lldb/bin/LLDBFrontend --version afin d'identifier les bibliothèques manquantes. En règle générale, la bibliothèque manquante est ncurses5, car certaines distributions Linux récentes ont déjà été mises à niveau vers ncurses6.

Profileurs

Cette section décrit les problèmes connus liés aux profileurs.

Profileur de mémoire natif : profilage non disponible au démarrage de l'application

Le profileur de mémoire natif est actuellement indisponible lors du démarrage de l'application. Cette option sera disponible dans une prochaine version.

Pour contourner ce problème, vous pouvez utiliser le profileur de ligne de commande autonome Perfetto pour capturer des profils de démarrage.

Erreurs de délai avant expiration dans le Profileur de processeur

Il est possible que des messages de type "Échec de l'arrêt de l'enregistrement" s'affichent dans le Profileur de processeur Android Studio lorsque vous sélectionnez les configurations Échantillonnage des méthodes Java ou Traçage des méthodes Java. Il s'agit souvent d'erreurs d'expiration de délai, par exemple, si le message d'erreur suivant s'affiche dans le fichier idea.log :

Wait for ART trace file timed out

Les erreurs de délai avant expiration ont tendance à affecter les méthodes tracées plus que les méthodes échantillonnées et les enregistrements longs plus que les enregistrements courts. Pour contourner ce problème, il peut être utile d'opter pour des enregistrements plus courts afin de voir si l'erreur disparaît.

Si vous rencontrez des problèmes de délai avant expiration avec le profileur, veuillez signaler un bug et indiquer la marque et le modèle de votre ou vos appareils, ainsi que toute entrée pertinente de idea.log et de logcat.

Exception ADB lors du débogage ou du profilage

Lorsque vous utilisez Platform Tools 29.0.3, le débogage natif et les profileurs Android Studio peuvent ne pas fonctionner correctement. Il est possible que les messages "AdbCommandRejectedException" ou "Failed to connect port" s'affichent dans le fichier idea.log lorsque vous sélectionnez Help > Show Log (Aide > Afficher le journal). La mise à niveau de Platform Tools vers la version 29.0.4 ou une version ultérieure permet de résoudre les deux problèmes.

Pour mettre à niveau Platform Tools, procédez comme suit :

  1. Ouvrez SDK Manager à partir d'Android Studio en cliquant sur Tools > SDK Manager (Outils > SDK Manager) ou sur SDK Manager dans la barre d'outils.

  2. Cliquez sur la case à cocher en regard de Android SDK Platform-Tools pour la sélectionner. Une icône de téléchargement doit apparaître dans la colonne de gauche.

  3. Cliquez sur Apply (Appliquer) ou sur OK.

Le plug-in empêche le bon fonctionnement de la fenêtre de sortie de la compilation

Le plug-in CMake simple highlighter empêche l'affichage de contenu dans la fenêtre de sortie de compilation. La compilation s'exécute et l'onglet "Build Output" (Sortie de compilation) s'affiche, mais aucune sortie n'apparaît (problème 204791544).

L'ordre d'installation empêche le lancement

L'installation d'une version plus récente d'Android Studio peut empêcher le lancement de l'ancienne version. Par exemple, si vous commencez par installer la version Canary d'Android Studio, puis que vous essayez d'installer et de lancer la version stable, l'opération peut échouer. Dans ce cas, vous devez vider le cache pour lancer la version stable (plus ancienne). Sous macOS, pour effacer le cache, supprimez le répertoire Library/ApplicationSupport/Google/AndroidStudioversion_number. Sous Windows, utilisez Nettoyage de disque.

Espresso Test Recorder ne fonctionne pas avec Compose

Espresso Test Recorder ne fonctionne pas avec les projets qui incluent Compose. Pour créer des tests d'interface utilisateur pour des projets qui incluent Compose, consultez la section Tester votre mise en page Compose.

Le raccourci Logcat est en conflit avec les dispositions de clavier qui ne sont pas en anglais

Si vous utilisez une disposition de clavier qui n'est pas en anglais, un raccourci clavier Logcat par défaut peut entrer en conflit avec le clavier en question et vous empêcher de saisir certains caractères lorsque vous modifiez du texte dans Android Studio. Pour contourner ce problème, supprimez le raccourci Logcat en conflit ou modifiez les touches qui lui sont associées. Pour modifier les touches de raccourci Logcat dans Android Studio, accédez à Android Studio > Settings > Keymap (Android Studio > Paramètres > Mappage du clavier) et recherchez Logcat dans la liste des mappages de clavier. Pour en savoir plus, consultez le problème 263475910.

Ce problème sera résolu en supprimant le raccourci Logcat dans le correctif 1 d'Android Studio Electric Eel.

Problèmes connus liés au plug-in Android Gradle

Cette section décrit les problèmes connus présents dans la dernière version stable du plug-in Android Gradle.

Les dépendances de la bibliothèque de fonctionnalités dynamiques ne sont pas toutes vérifiées par lint

Lors de l'exécution de lint avec checkDependencies = true à partir d'un module d'application, les dépendances de la bibliothèque de fonctionnalités dynamiques ne sont pas vérifiées, sauf s'il s'agit également de dépendances d'application. (problème 191977888) Pour contourner ce problème, vous pouvez exécuter la tâche lint sur ces bibliothèques.

Fichier de signature nommé avec des caractères de retour chariot

La signature JAR (schéma v1) n'est pas compatible avec les noms de fichiers contenant des caractères de retour chariot (problème 63885809).

La modification des sorties de variantes au moment de la compilation peut ne pas fonctionner

Le fonctionnement de l'API Variant est défectueux avec le nouveau plug-in et ne permet pas de manipuler les sorties des variantes. Elle fonctionne toujours pour les tâches simples, telle que la modification du nom de l'APK pendant la compilation, comme indiqué ci-dessous : 

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

Toutefois, les tâches plus complexes impliquant un accès aux objets outputFile ne fonctionnent plus. En effet, les tâches spécifiques aux variantes ne sont plus créées lors de l'étape de configuration. Le plug-in ne connaît donc pas toutes les sorties en amont, mais les délais de configuration sont également plus courts.

manifestOutputFile n'est plus disponible

La méthode processManifest.manifestOutputFile() n'est plus disponible et l'erreur suivante s'affiche lorsque vous l'appelez :

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task
   ':myapp:processDebugManifest' of type
   com.android.build.gradle.tasks.ProcessManifest.

Au lieu d'appeler manifestOutputFile() pour obtenir le fichier manifeste de chaque variante, vous pouvez appeler processManifest.manifestOutputDirectory() pour renvoyer le chemin du répertoire contenant tous les fichiers manifestes générés. Vous pouvez ensuite localiser un fichier manifeste et lui appliquer votre logique. L'exemple ci-dessous modifie le code de la version de manière dynamique dans le fichier manifeste :

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}

Problèmes liés à la prise en charge d'AGP 7.3.0 pour AIDL et à Kotlin 1.7.x

Lorsqu'AGP 7.3.0 est utilisé avec KAPT dans Kotlin 1.7.x, les ensembles de sources AIDL pour des variantes de compilation spécifiques sont supprimés. Vous pouvez toujours utiliser les autres ensembles de sources AIDL, y compris main/, les types de compilation, les types de produit et les combinaisons de types de produits. Si vous devez utiliser les ensembles de sources AIDL spécifiques à une variante, continuez à utiliser Kotlin 1.6.21.

Problèmes connus corrigés

Cette section décrit les problèmes connus qui ont été résolus dans une version récente. Si vous rencontrez l'un de ces problèmes, vous devez mettre à jour Android Studio vers la dernière version stable ou version preview.

Corrigé dans Android Studio 2021.1.1

  • Sortie lint manquante : Aucune sortie de texte lint n'est présente dans stdout lorsque la tâche lint est UP-TO-DATE (problème 191897708). Corrigé dans AGP 7.1.0-alpha05.
  • Problèmes liés aux tests unitaires d'un projet d'application qui utilise le plug-in Hilt : Le chemin d'accès de la classe de test unitaire contient les classes d'application non instrumentées, ce qui signifie que Hilt n'instrumente pas les classes d'application pour gérer l'injection de dépendances lors de l'exécution de tests unitaires (problème 213534628). Corrigé dans AGP 7.1.1.

Corrigé dans Android Studio 2020.3.1

  • Exceptions lint dans les projets Kotlin : Les projets Kotlin qui définissent checkDependencies = true peuvent rencontrer des erreurs ou des exceptions de pointeur nul (problème 158777858).

Corrigé dans Android Studio 4.2

  • L'IDE se fige sur macOS Big Sur : Android Studio 4.1 peut se figer lorsque vous ouvrez une boîte de dialogue.

Corrigé dans Android Studio 4.1

  • Redémarrer pour appliquer les paramètres de mémoire de la version précédente de l'IDE : après avoir mis à jour Android Studio, vous devez le redémarrer pour appliquer tous les paramètres de mémoire migrés depuis une version antérieure de l'IDE.
  • La classe manifeste avec des chaînes d'autorisation personnalisées n'est plus générée par défaut : vous souhaitez générer cette classe, définissez android.generateManifestClass = true.

Corrigé dans Android Studio 3.6

  • Erreur lors de l'installation de l'APK sur LineageOS : Le déploiement de votre application sur des appareils exécutant certaines versions de LineageOS ou CyanogenMod peut échouer et générer une exception INSTALL_PARSE_FAILED_NOT_APK.

    Sur Android Studio 3.6 Bêta 1 et versions ultérieures, l'IDE traite cette exception en effectuant une installation complète de l'application lorsque vous la déployez sur des appareils LineageOS ou CyanogenMod, ce qui peut entraîner un déploiement plus long.

Corrigé dans Android Studio 3.5.2

  • Style de code XML défectueux : lors de la modification du code XML, l'IDE a appliqué un style de code incorrect après la sélection de Code > Reformater le code dans la barre de menu.

Corrigé dans Android Studio 3.3.1

  • Erreurs de mémoire insuffisante lors de l'analyse de projets basés sur C++ : Lorsque Gradle analyse un projet dont le code C++ est présent à plusieurs emplacements d'un même disque, l'analyse inclut tous les répertoires situés sous le premier répertoire commun. L'analyse d'un grand nombre de répertoires et de fichiers peut entraîner des erreurs de mémoire insuffisante.

    Pour plus d'informations sur ce problème, consultez le bug qui lui est associé.