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'une aide supplémentaire, contactez l'assistance Firebase .
Dépannage général/FAQ
Si vous ne voyez pas d'utilisateurs sans plantage, de journaux de fil d'Ariane et/ou d'alertes de vélocité, nous vous recommandons de vérifier la configuration de votre application pour Google Analytics.
Assurez-vous d'avoir activé Google Analytics dans votre projet Firebase.
Assurez-vous que le partage de données est activé pour Google Analytics dans la page Intégrations > Google Analytics de la console Firebase. Notez que les paramètres de partage de données sont affichés dans la console Firebase mais gérés dans la console Google Analytics.
En plus du SDK Firebase Crashlytics, assurez-vous d'avoir ajouté le SDK Firebase pour Google Analytics à votre application ( iOS+ | Android ).
Assurez-vous que vous utilisez les dernières versions pour tous vos SDK Firebase ( iOS+ | Android ).
Vérifiez en particulier que vous utilisez au minimum les versions suivantes du SDK Firebase pour Google Analytics : iOS+ — v6.3.1+ (v8.9.0+ pour macOS et tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Crashlytics prend en charge les rapports ANR pour les applications Android à partir 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 SIGQUIT ou les approches basées sur le chien de garde. Cette API est disponible uniquement sur les appareils Android 11+.
Il peut y avoir une incohé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 l'ANR.
De plus, Crashlytics affiche uniquement les ANR qui se produisent sur les appareils exécutant Android 11+, par rapport à Google Play qui affiche les ANR des appareils avec les services Google Play et le 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 fichiers 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 options d'éditeur de liens suivantes à votre processus de compilation :
Si vous utilisez l'éditeur de liens
lldde la chaîne d'outils LLVM, ajoutez :-Wl,--no-rosegmentSi vous utilisez l'éditeur de liens
ld.goldde 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 indicateur n'est pertinent pour votre chaîne d'outils), essayez plutôt d'ajouter ce qui suit à votre processus de génération :
-fno-omit-frame-pointer
Le plug-in 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 génération à 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 l'une des deux manières suivantes :
Option 1 : Spécifiez le chemin via l'extension
firebaseCrashlyticsdans votre fichierbuild.gradleAjoutez les éléments suivants à votre fichier
build.gradleau 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.symbolGeneratorBinarypour 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 utilisiez une version de DexGuard incompatible avec le SDK Firebase Crashlytics :
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Cette exception ne plante pas votre application mais l'empêche d'envoyer des rapports de plantage. Pour résoudre ce problème :
Assurez-vous d'utiliser 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 qui utilisent 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 supérieur.
- 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 pouvez voir de nouveaux problèmes .kt qui ne sont en fait que des doublons de problèmes étiquetés .java existants. Dans la console Firebase, nous essayons d'identifier et de vous communiquer si un nouveau problème .kt est un doublon possible d'un problème existant portant l' .java .
La valeur sans plantage représente le pourcentage d'utilisateurs qui ont interagi avec votre application mais qui n'ont pas eu de plantage sur une période donnée. Vous sélectionnez cette période dans le menu déroulant en haut à droite du tableau de bord Crashlytics.
Le pourcentage d'utilisateurs sans plantage est une agrégation dans le temps , et non une moyenne.
Par exemple, imaginez que votre application compte trois utilisateurs ; nous les appellerons Utilisateur A, Utilisateur B et Utilisateur C. Le tableau suivant indique quels utilisateurs interagissent avec votre application chaque jour et lesquels de ces utilisateurs ont eu un plantage ce jour-là :
| Lundi | Mardi | Mercredi | |
|---|---|---|---|
| Utilisateurs ayant interagi avec votre application | A, B, C | A, B, C | UN B |
| Utilisateur qui a eu un plantage | C | B | UN |
Mercredi, votre pourcentage d'utilisateurs sans plantage est de 50 % (1 utilisateur sur 2 n'a pas eu de plantage).
Deux de vos utilisateurs ont utilisé votre application mercredi, mais un seul d'entre eux (utilisateur B) n'a pas eu de plantage.Au cours des 2 derniers jours, votre pourcentage d'utilisateurs sans plantage est de 33,3 % (1 utilisateur sur 3 n'a pas eu de plantage).
Trois de vos utilisateurs ont interagi avec votre application au cours des deux derniers jours, mais un seul d'entre eux (utilisateur C) n'a rencontré aucun plantage.Au cours des 3 derniers jours, votre pourcentage d'utilisateurs sans plantage est de 0 % (0 utilisateur sur 3 n'a pas eu de plantage).
Trois de vos utilisateurs ont utilisé votre application au cours des trois derniers jours, mais aucun d'entre eux n'a eu de plantage.
Si nécessaire, voici les entrées spécifiques et la formule pour le calcul du pourcentage d'utilisateurs sans plantage :
1 - ( IMPACTED_USERS / ALL_USERS )
Où IMPACTED_USERS et ALL_USERS sont collectés par Google Analytics et disponibles via le tableau de bord Analytics.
Intégrations
Si votre projet utilise Crashlytics en même temps que le SDK Google Mobile Ads, il est probable que les rapporteurs de plantage 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 situés aux États-Unis, quel que soit l'emplacement de votre projet Firebase.
Prise en charge de la plate-forme
Le NDK Firebase Crashlytics ne prend pas en charge ARMv5 (armeabi). La prise en charge de cet ABI a été supprimée à partir de NDK r17.
Problèmes régressés
Un problème a régressé lorsque vous avez précédemment fermé le problème, mais Crashlytics reçoit un nouveau rapport indiquant que le problème s'est reproduit. Crashlytics rouvre automatiquement ces problèmes régressés afin que vous puissiez les résoudre en fonction de votre application.
Voici un exemple de scénario qui explique comment Crashlytics classe un problème en tant que régression :
- Pour la toute première fois, Crashlytics reçoit un rapport de plantage sur le crash "A". Crashlytics ouvre un problème correspondant à ce plantage (Problème "A").
- Vous corrigez rapidement ce bogue, 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 fermé 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 a envoyé un rapport de plantage pour n'importe quel plantage), alors Crashlytics ne considérera pas le problème comme ayant régressé. 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 plantage pour un plantage quelconque), 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 voulez pas qu'un problème se rouvre en raison de notre algorithme de régression, "ignorez" le problème au lieu de le fermer.
Si un rapport provient d'une ancienne version de l'application qui n'avait 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 bogue et publié une nouvelle version de votre application, mais vous avez encore des utilisateurs sur des versions plus anciennes sans le correctif de bogue. Si, par hasard, l'une de ces anciennes versions n'avait jamais envoyé de rapport de plantage lorsque vous avez fermé le problème et que ces utilisateurs commencent à rencontrer le bogue, ces rapports de plantage déclencheraient un problème de régression.
Si vous ne voulez pas qu'un problème se rouvre en raison de notre algorithme de régression, "ignorez" le problème au lieu de le fermer.