Cette page fournit une aide au dépannage et des réponses aux questions fréquemment posées sur l'utilisation de Crashlytics. Si vous ne trouvez pas ce que vous cherchez ou si vous avez besoin d'aide supplémentaire, contactez l'assistance Firebase .
Dépannage général/FAQ
Vous remarquerez peut-être deux formats différents pour les problèmes répertoriés dans votre tableau Problèmes dans la console Firebase. Et vous remarquerez peut-être également une fonctionnalité appelée « variantes » dans certains de vos problèmes. Voici pourquoi!
Début 2023, nous avons déployé un moteur d'analyse amélioré pour regrouper les événements ainsi qu'une conception mise à jour et des fonctionnalités avancées pour les nouveaux numéros (comme les variantes !). Consultez notre récent article de blog pour tous les détails, mais vous pouvez lire ci-dessous pour les faits saillants.
Crashlytics analyse tous les événements de votre application (comme les plantages, les incidents non mortels et les ANR) et crée des groupes d'événements appelés problèmes : tous les événements d'un problème ont un point de défaillance commun.
Pour regrouper les événements dans ces problèmes, le moteur d'analyse amélioré examine désormais de nombreux aspects de l'événement, notamment les trames dans la trace de la pile, le message d'exception, le code d'erreur et d'autres caractéristiques de plate-forme ou de type d'erreur.
Toutefois, au sein de ce groupe d’événements, les traces de pile menant à l’échec peuvent être différentes. Une trace de pile différente pourrait signifier une cause première différente. Pour représenter cette différence possible au sein d'un problème, nous créons maintenant des variantes au sein des problèmes : chaque variante est un sous-groupe d'événements dans un problème qui ont le même point de défaillance et une trace de pile similaire. Avec les variantes, vous pouvez déboguer les traces de pile les plus courantes au sein d'un problème et déterminer si différentes causes profondes conduisent à l'échec.
Voici ce que vous découvrirez avec ces améliorations :
Métadonnées remaniées affichées dans la ligne du problème
Il est désormais plus facile de comprendre et de trier les problèmes dans votre application.Moins de problèmes en double
Un changement de numéro de ligne n’entraîne pas de nouveau problème.Débogage plus facile de problèmes complexes ayant diverses causes profondes
Utilisez des variantes pour déboguer les traces de pile les plus courantes au sein d'un problème.Alertes et signaux plus significatifs
Un nouveau problème représente en fait un nouveau bug.Recherche plus puissante
Chaque numéro contient davantage de métadonnées consultables, telles que le type d'exception et le nom du package.
Voici comment ces améliorations sont déployées :
Lorsque nous recevons de nouveaux événements de votre application, nous vérifions s'ils correspondent à un problème existant.
S'il n'y a pas de correspondance, nous appliquerons automatiquement notre algorithme de regroupement d'événements plus intelligent à l'événement et créerons un nouveau problème avec la conception repensée des métadonnées.
C'est la première grande mise à jour que nous apportons à notre groupe d'événements. Si vous avez des commentaires ou rencontrez des problèmes, veuillez nous en informer en déposant un rapport.
Si vous ne voyez pas de métriques sans crash (comme les utilisateurs et sessions sans crash) et/ou d'alertes de vitesse, assurez-vous que vous utilisez le SDK CrashlyticsCrashlytics SDK v18.6.0+ (ou Firebase BoM v32.6.0+).
Si vous ne voyez pas les journaux de fil d'Ariane , nous vous recommandons de vérifier la configuration de votre application pour Google Analytics. Assurez-vous de remplir les conditions suivantes :
Vous avez activé Google Analytics dans votre projet Firebase.
Vous avez activé le partage de données pour Google Analytics. En savoir plus sur ce paramètre dans Gérer vos paramètres de partage de données Analytics
Vous avezajouté le SDK Firebase pour Google Analyticsà votre application. Ce SDK doit être ajouté en plus du SDK Crashlytics.
Vous utilisez les dernières versions du SDK Firebaseles dernières versions du SDK Firebasepour tous les produits que vous utilisez dans votre application.
Vérifiez particulièrement que vous utilisez au minimum la version suivante du SDK Firebase pour Google Analytics :
Android — v17.2.3+ (BoM v24.7.1+) .
Crashlytics prend en charge les rapports ANR pour les applications Android provenant d'appareils exécutant Android 11 et versions ultérieures. L'API sous-jacente que nous utilisons pour collecter les ANR ( getHistoricalProcessExitReasons ) est plus fiable que les approches SIGQUIT ou basées sur un chien de garde. Cette API est disponible uniquement sur les appareils Android 11+.
Si certains de vos ANR n'ont pas leur BuildId
, résolvez les problèmes comme suit :
Assurez-vous que vous utilisez une version à jour du SDK Android Crashlytics et du plug-in Crashlytics Gradle.
S'il vous manque
BuildId
pour Android 11 et certains ANR Android 12, il est probable que vous utilisiez un SDK, un plugin Gradle ou les deux obsolètes. Pour collecter correctementBuildId
pour ces ANR, vous devez utiliser les versions suivantes :- Kit de développement logiciel Crashlytics Android v18.3.5+ (Firebase BoM v31.2.2+)
- Plugin Crashlytics Gradle v2.9.4+
Vérifiez si vous utilisez un emplacement non standard pour vos bibliothèques partagées.
S'il ne vous manque que
BuildId
pour les bibliothèques partagées de votre application, il est probable que vous n'utilisiez pas l'emplacement standard par défaut pour les bibliothèques partagées. Si tel est le cas, Crashlytics pourrait ne pas être en mesure de localiser lesBuildId
associés. Nous vous recommandons d'envisager d'utiliser l'emplacement standard pour les bibliothèques partagées.Assurez-vous de ne pas supprimer les
BuildId
pendant le processus de construction.Notez que les conseils de dépannage suivants s’appliquent à la fois aux ANR et aux plantages natifs.
Vérifiez si les
BuildId
existent en exécutantreadelf -n
sur vos binaires. Si lesBuildId
sont absents, ajoutez-Wl,--build-id
aux indicateurs de votre système de build.Vérifiez que vous ne supprimez pas involontairement les
BuildId
dans le but de réduire la taille de votre APK.Si vous conservez des versions supprimées et non supprimées d'une bibliothèque, assurez-vous de pointer vers la version correcte dans votre code.
Il peut y avoir une différence entre le nombre d'ANR entre Google Play et Crashlytics. Cela est attendu en raison de la différence dans le mécanisme de collecte et de communication des données ANR. Crashlytics signale les ANR au prochain démarrage de l'application, tandis qu'Android Vitals envoie les données ANR après que l'ANR se soit produit.
De plus, Crashlytics affiche uniquement les ANR qui se produisent sur les appareils fonctionnant sous Android 11+, contrairement à Google Play qui affiche les ANR des appareils dotés des services Google Play et du consentement à la collecte de données accepté.
Les chaînes d'outils LLVM et GNU ont des valeurs par défaut et des traitements distincts pour le segment en lecture seule des binaires de votre application, ce qui peut générer des traces de pile incohérentes dans la console Firebase. Pour atténuer ce problème, ajoutez les indicateurs d'éditeur de liens suivants à votre processus de génération :
Si vous utilisez l'éditeur de liens
lld
de la chaîne d'outils LLVM, ajoutez :-Wl,--no-rosegment
Si vous utilisez l'éditeur de liens
ld.gold
de la chaîne d'outils GNU, ajoutez :-Wl,--rosegment
Si vous constatez toujours des incohérences dans la trace de la pile (ou si aucun des deux indicateurs n'est pertinent pour votre chaîne d'outils), essayez plutôt d'ajouter ce qui suit à votre processus de construction :
-fno-omit-frame-pointer
Le plugin Crashlytics regroupe un générateur de fichiers de symboles Breakpad personnalisé . Si vous préférez utiliser votre propre binaire pour générer des fichiers de symboles Breakpad (par exemple, si vous préférez créer tous les exécutables natifs de votre chaîne de construction à partir de la source), utilisez la propriété d'extension facultative symbolGeneratorBinary
pour spécifier le chemin d'accès à l'exécutable.
Vous pouvez spécifier le chemin d'accès au binaire du générateur de fichiers de symboles Breakpad de deux manières :
Option 1 : Précisez le chemin via l'extension
firebaseCrashlytics
dans votre fichierbuild.gradle
Ajoutez ce qui suit à votre fichier
build.gradle
au niveau de l'application :android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
Option 2 : Spécifiez le chemin via une ligne de propriété dans votre fichier de propriétés Gradle
Vous pouvez utiliser la propriété
com.google.firebase.crashlytics.symbolGeneratorBinary
pour spécifier le chemin d'accès à l'exécutable.Vous pouvez mettre à jour manuellement votre fichier de propriétés Gradle ou mettre à jour le fichier via la ligne de commande. Par exemple, pour spécifier le chemin via la ligne de commande, utilisez une commande comme celle-ci :
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Si vous voyez l'exception suivante, il est probable que vous utilisez une version de DexGuard incompatible avec le SDK Firebase Crashlytics :
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Cette exception ne fait pas planter votre application mais l'empêche d'envoyer des rapports de plantage. Pour résoudre ce problème :
Assurez-vous que vous utilisez la dernière version de DexGuard 8.x. La dernière version contient les règles requises par le SDK Firebase Crashlytics.
Si vous ne souhaitez pas modifier votre version de DexGuard, essayez d'ajouter la ligne suivante à vos règles d'obscurcissement (dans votre fichier de configuration DexGuard) :
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Lorsqu'une application utilise un obfuscateur qui n'expose pas l'extension de fichier, Crashlytics génère chaque problème avec une extension de fichier .java
par défaut.
Pour que Crashlytics puisse générer des problèmes avec l'extension de fichier correcte, assurez-vous que votre application utilise la configuration suivante :
- Utilise Android Gradle 4.2.0 ou supérieur
- Utilise R8 avec l'obscurcissement activé. Pour mettre à jour votre application vers R8, suivez cette documentation .
Notez qu'après la mise à jour vers la configuration décrite ci-dessus, vous pourriez commencer à voir de nouveaux problèmes .kt
qui sont des doublons de problèmes .java
existants. Consultez la FAQ pour en savoir plus sur cette circonstance.
À partir de la mi-décembre 2021, Crashlytics a amélioré la prise en charge des applications utilisant Kotlin.
Jusqu'à récemment, les obfuscateurs disponibles n'exposaient pas l'extension de fichier, donc Crashlytics générait chaque problème avec une extension de fichier .java
par défaut. Cependant, depuis Android Gradle 4.2.0, R8 prend en charge les extensions de fichiers.
Avec cette mise à jour, Crashlytics peut désormais déterminer si chaque classe utilisée dans l'application est écrite en Kotlin et inclure le nom de fichier correct dans la signature du problème. Les plantages sont désormais correctement attribués aux fichiers .kt
(le cas échéant) si votre application a la configuration suivante :
- Votre application utilise Android Gradle 4.2.0 ou version ultérieure.
- Votre application utilise R8 avec l'obscurcissement activé.
Étant donné que les nouveaux plantages incluent désormais l'extension de fichier correcte dans leurs signatures de problème, vous pourriez voir de nouveaux problèmes .kt
qui ne sont en réalité que des doublons de problèmes existants étiquetés .java
. Dans la console Firebase, nous essayons d'identifier et de vous communiquer si un nouveau problème .kt
est un double possible d'un problème existant étiqueté .java
.
Les notes permettent aux membres du projet de commenter des problèmes spécifiques avec des questions, des mises à jour de statut, etc.
Lorsqu'un membre du projet publie une note, celle-ci porte l'adresse e-mail de son compte Google. Cette adresse e-mail est visible, avec la note, par tous les membres du projet ayant accès à la note.
Ce qui suit décrit l'accès requis pour afficher, écrire et supprimer des notes :
Les membres du projet dotés de l'un des rôles suivants peuvent afficher et supprimer les notes existantes et rédiger de nouvelles notes sur un problème.
Les membres du projet dotés de l'un des rôles suivants peuvent afficher les notes publiées sur un problème, mais ils ne peuvent pas supprimer ni rédiger de note.
- Visionneuse de projets , Visionneuse Firebase , Visionneuse de qualité ou Visionneuse Crashlytics
Voir Comprendre les métriques sans plantage .
Les notes permettent aux membres du projet de commenter des problèmes spécifiques avec des questions, des mises à jour de statut, etc.
Lorsqu'un membre du projet publie une note, celle-ci porte l'adresse e-mail de son compte Google. Cette adresse e-mail est visible, avec la note, par tous les membres du projet ayant accès à la note.
Ce qui suit décrit l'accès requis pour afficher, écrire et supprimer des notes :
Les membres du projet dotés de l'un des rôles suivants peuvent afficher et supprimer les notes existantes et rédiger de nouvelles notes sur un problème.
Les membres du projet dotés de l'un des rôles suivants peuvent afficher les notes publiées sur un problème, mais ils ne peuvent pas supprimer ni rédiger de note.
- Visionneuse de projets , Visionneuse Firebase , Visionneuse de qualité ou Visionneuse Crashlytics
Intégrations
Si votre projet utilise Crashlytics avec le SDK Google Mobile Ads, il est probable que les rapporteurs de crash interfèrent lors de l'enregistrement des gestionnaires d'exceptions. Pour résoudre le problème, désactivez les rapports d'erreur dans le SDK Mobile Ads en appelant disableSDKCrashReporting
.
Une fois que vous avez associé Crashlytics à BigQuery, les nouveaux ensembles de données que vous créez sont automatiquement localisés aux États-Unis, quel que soit l'emplacement de votre projet Firebase.
Prise en charge de la plateforme
Le NDK Firebase Crashlytics ne prend pas en charge ARMv5 (armeabi). La prise en charge de cet ABI a été supprimée à partir du NDK r17.
Problèmes régressés
Un problème a connu une régression alors que vous l'aviez précédemment résolu, mais Crashlytics reçoit un nouveau rapport indiquant que le problème s'est reproduit. Crashlytics rouvre automatiquement ces problèmes en régression afin que vous puissiez les résoudre de manière appropriée pour votre application.
Voici un exemple de scénario qui explique comment Crashlytics classe un problème comme une régression :
- Pour la toute première fois, Crashlytics reçoit un rapport d'erreur concernant le crash "A". Crashlytics ouvre un problème correspondant à ce crash (problème « A »).
- Vous corrigez ce bug rapidement, fermez le problème « A », puis publiez une nouvelle version de votre application.
- Crashlytics reçoit un autre rapport sur le problème « A » une fois que vous avez résolu le problème.
- Si le rapport provient d'une version de l'application dont Crashlytics avait connaissance lorsque vous avez résolu le problème (ce qui signifie que la version avait envoyé un rapport de crash pour tout crash), alors Crashlytics ne considérera pas le problème comme une régression. Le sujet restera clos.
- Si le rapport provient d'une version de l'application dont Crashlytics n'avait pas connaissance lorsque vous avez fermé le problème (ce qui signifie que la version n'a jamais envoyé de rapport de crash pour un quelconque crash), alors Crashlytics considère que le problème a régressé et rouvrira le problème. .
Lorsqu'un problème régresse, nous envoyons une alerte de détection de régression et ajoutons un signal de régression au problème pour vous informer que Crashlytics a rouvert le problème. Si vous ne souhaitez pas qu'un problème soit rouvert en raison de notre algorithme de régression, « éteignez » le problème au lieu de le fermer.
Si un rapport provient d'une ancienne version de l'application qui n'a jamais envoyé de rapport d'erreur lorsque vous avez fermé le problème, Crashlytics considère que le problème a régressé et rouvrira le problème.
Cette situation peut se produire dans la situation suivante : vous avez corrigé un bug et publié une nouvelle version de votre application, mais vous avez toujours des utilisateurs sur des versions plus anciennes sans la correction du bug. Si, par hasard, l'une de ces anciennes versions n'avait jamais envoyé de rapport d'erreur lorsque vous avez résolu le problème et que ces utilisateurs commencent à rencontrer le bogue, ces rapports d'erreur déclencheraient un problème de régression.
Si vous ne souhaitez pas qu'un problème soit rouvert en raison de notre algorithme de régression, « éteignez » le problème au lieu de le fermer.