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+) .
Vous remarquerez peut-être deux formats différents pour les problèmes répertoriés dans votre tableau des 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'un design mis à jour et quelques fonctionnalités avancées pour les nouveaux problèmes (comme les variantes !). Consultez notre récent article de blog pour tous les détails, mais vous pouvez lire ci-dessous les faits saillants.
Crashlytics analyse tous les événements de votre application (comme les plantages, les événements non fatals 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, y compris 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.
Cependant, 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 peut signifier une cause racine 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 dans un problème et déterminer si différentes causes profondes sont à l'origine de l'échec.
Voici ce que vous allez découvrir 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 de doublons
Un changement de numéro de ligne n'entraîne pas de nouveau problème.Débogage plus facile des problèmes complexes avec diverses causes profondes
Utilisez des variantes pour déboguer les traces de pile les plus courantes dans un problème.Alertes et signaux plus significatifs
Un nouveau problème représente en fait un nouveau bogue.Recherche plus puissante
Chaque problème contient davantage de métadonnées consultables, telles que le type d'exception et le nom du package.
Voici comment ces améliorations se déploient :
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 de métadonnées remaniée.
Il s'agit de 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 remplissant un rapport.
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.
Voici la formule pour calculer le pourcentage d'utilisateurs sans plantage. Ses valeurs d'entrée sont fournies par Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Lorsqu'un plantage se produit, Google Analytics envoie un type d'événement
app_exceptionet CRASHED_USERS représente le nombre d'utilisateurs associés à ce type d'événement.ALL_USERS représente le nombre total d'utilisateurs qui ont interagi avec votre application au cours de la période que vous avez sélectionnée 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 les utilisateurs qui ont utilisé 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.
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 est étiquetée avec 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 vue de la note.
La section suivante décrit l'accès requis pour afficher, rédiger et supprimer des notes :
Les membres du projet avec l'un des rôles suivants peuvent afficher et supprimer des notes existantes et rédiger de nouvelles notes sur un problème.
Les membres du projet avec l'un des rôles suivants peuvent afficher les notes publiées sur un problème, mais ils ne peuvent pas supprimer ou écrire une note.
- Visionneuse de projet , visionneuse Firebase , visionneuse de qualité ou visionneuse Crashlytics
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
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.