Cette page recense les problèmes connus liés à Android Studio Plug-in Koala et Android Gradle 8.5.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.
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 la fonction L'outil d'inspection de la mise en page 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 :
- Ouvrez la fenêtre Paramètres en cliquant sur Fichier > Paramètres.
- Accédez à Apparence et comportement > Apparence.
- Sélectionnez Utiliser une police personnalisée.
- Augmentez la taille de la police.
- Dans la fenêtre Paramètres, accédez à Éditeur > Police.
- Augmentez la taille de la police.
- 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 :
Cette solution ne désactive les modes de saisie que pour Android Studio, et non pour toute autre application que vous pourriez exécuter. Notez que si vous redémarrez le daemon pendant qu'Android Studio est en cours d'exécution (par exemple, en exécutant$ XMODIFIERS= ./bin/studio.sh
ibus-daemon -rd
), vous désactivez efficacement les modes de saisie pour tous d'autres applications et peut faire planter la JVM d'Android Studio l'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 :
- Commencez par essayer d'installer la dernière version de HAXM à partir de SDK Manager.
- Sous macOS, accédez à Préférences système > Sécurité et confidentialité.
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
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é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.
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 :
- 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.
- 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.
- 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 estUP-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é.