Dépannage de Crashlytics et questions fréquentes

iOS+ Android Flutter Unity

Cette page fournit une aide au dépannage et des réponses aux questions fréquentes 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/Questions fréquentes

Différents formats (et parfois "variantes") pour certains problèmes dans le tableau Problèmes

Vous remarquerez peut-être deux formats différents pour les problèmes listés dans le tableau Problèmes de la console Firebase. 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 interface mise à jour et des fonctionnalités avancées pour les nouveaux problèmes (comme les variantes). Pour en savoir plus, consultez notre récent article de blog. Vous trouverez ci-dessous les points clés.

Crashlytics analyse tous les événements de votre application (comme les plantages, les erreurs non fatales 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 frames de la trace de 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 autre trace de pile peut indiquer une autre cause première. Pour représenter cette différence potentielle au sein d'un problème, nous créons désormais des variantes au sein des problèmes. Chaque variante est un sous-groupe d'événements d'un problème ayant le même point de défaillance et une trace de pile similaire. Les variantes vous permettent de déboguer les traces de pile les plus courantes d'un problème et de déterminer si différentes causes sont à l'origine de l'échec.

Voici ce que vous constaterez avec ces améliorations :

• Métadonnées repensé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 la création d'un nouveau problème.

• Débogage plus facile des problèmes complexes avec différentes causes
  Utilisez des variantes pour déboguer les traces de pile les plus courantes d'un problème.

• Des alertes et des signaux plus utiles
  Un nouveau problème correspond en fait à un nouveau bug.

• Recherche plus performante
  Chaque problème contient davantage de métadonnées pouvant faire l'objet d'une recherche, comme 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.

• En l'absence de correspondance, nous appliquerons automatiquement notre algorithme de regroupement d'événements plus intelligent à l'événement et créerons un problème avec la nouvelle conception des métadonnées.

Il s'agit de la première mise à jour majeure que nous apportons au regroupement des événements. Si vous avez des commentaires ou si vous rencontrez des problèmes, n'hésitez pas à nous en faire part en envoyant un rapport .

Journaux de fil d'Ariane non visibles

Si vous ne voyez pas de 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 des données Analytics

• Vous avez à votre application. Ce SDK doit être ajouté en plus du SDK Crashlytics.

• Vous utilisez les pour tous les produits que vous utilisez dans votre application.

Je ne vois pas d'alertes de vitesse

Si vous ne voyez pas d'alertes de vélocité, assurez-vous d'utiliser les versions suivantes du SDK Crashlytics :

Vous ne voyez pas les métriques d'utilisation sans plantage (ou elles ne sont pas fiables)

Si vous ne voyez pas de métriques sans plantage (comme les utilisateurs et les sessions sans plantage) ou si les métriques ne sont pas fiables, vérifiez les points suivants :

• Assurez-vous d'utiliser les versions suivantes du SDK Crashlytics :

• Assurez-vous que vos paramètres de collecte de données n'ont pas d'incidence sur la qualité de vos métriques sans plantage :

  • Si vous activez les rapports avec consentement en désactivant les rapports d'erreur automatiques, les informations sur les plantages ne peuvent être envoyées à Crashlytics que par les utilisateurs qui ont explicitement accepté la collecte de données. Par conséquent, la précision des métriques sans plantage sera affectée, car Crashlytics ne dispose que des informations sur les plantages de ces utilisateurs ayant activé le partage (et non de tous vos utilisateurs). Cela signifie que vos métriques d'utilisation sans plantage peuvent être moins fiables et moins représentatives de la stabilité globale de votre application.

  • Si vous avez désactivé la collecte automatique des données, vous pouvez utiliser sendUnsentReports pour envoyer les rapports mis en cache sur l'appareil à Crashlytics. Cette méthode envoie les données crash à Crashlytics, mais pas les données sessions. Les graphiques de la console affichent donc des valeurs faibles ou nulles pour les métriques sans plantage.

Comment le nombre d'utilisateurs n'ayant pas subi de plantage est-il calculé ?

Consultez Comprendre les métriques d'utilisation sans plantage.

Qui peut afficher, rédiger et supprimer des notes sur un problème ?

Les notes permettent aux membres du projet de commenter des problèmes spécifiques en posant des questions, en fournissant des informations sur l'état, etc.

Lorsqu'un membre du projet publie une note, l'adresse e-mail de son compte Google est indiquée. Cette adresse e-mail est visible, ainsi que la note, par tous les membres du projet ayant accès à la note.

Vous trouverez ci-dessous une description de l'accès requis pour afficher, écrire et supprimer des notes :

• Les membres du projet disposant de l'un des rôles suivants peuvent afficher et supprimer les notes existantes, et en rédiger de nouvelles sur un problème.

  • Propriétaire ou éditeur du projet, administrateur Firebase, administrateur Quality ou administrateur Crashlytics

• Les membres du projet disposant de l'un des rôles suivants peuvent consulter les notes publiées sur un problème, mais ne peuvent pas en supprimer ni en rédiger.

  • Lecteur de projet, Lecteur Firebase, Lecteur Quality, ou Lecteur Crashlytics

Intégrations

L'application utilise également le SDK Google Mobile Ads, mais ne rencontre aucun plantage.

Si votre projet utilise Crashlytics avec le SDK Google Mobile Ads, il est probable que les outils de signalement des plantages 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.

Où se trouve mon ensemble de données BigQuery ?

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.

Compatibilité avec les plates-formes

Problèmes régressifs

Qu'est-ce qu'un problème régressé ?

Un problème a régressé lorsque vous l'avez déjà fermé, mais qu'un nouveau rapport indique qu'il s'est reproduit.Crashlytics Crashlytics rouvre automatiquement ces problèmes de 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 catégorise un problème comme une régression :

1. Pour la première fois, Crashlytics reçoit un rapport d'erreur concernant l'erreur "A". Crashlytics ouvre un problème correspondant à ce plantage (problème A).
2. Vous corrigez rapidement ce bug, fermez le problème A, puis publiez une nouvelle version de votre application.
3. Crashlytics reçoit un autre signalement concernant le problème A après que vous l'avez clôturé.
   • Si le rapport provient d'une version de l'application que Crashlytics connaissait lorsque vous avez clôturé le problème (c'est-à-dire que la version avait envoyé un rapport d'erreur pour n'importe quelle erreur), Crashlytics ne considérera pas le problème comme une régression. Le problème restera clos.
   • Si le rapport provient d'une version de l'application qui Crashlytics n'était pas au courant lorsque vous avez clôturé le problème (c'est-à-dire que la version n'avait jamais envoyé aucun rapport d'erreur pour aucun plantage), Crashlytics considère que le problème est en régression et le rouvrira.

Remarque : Avant février 2022, Crashlytics classait un problème comme régression lorsqu'il se reproduisait dans n'importe quelle version de l'application, même pour les versions de l'application que nous connaissions lorsque vous avez clôturé le problème. Par conséquent, Crashlytics identifiait parfois des régressions de manière inexacte. Nous utilisons désormais la convention décrite ci-dessus.

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 l'a rouvert. Si vous ne souhaitez pas qu'un problème soit rouvert en raison de notre algorithme de régression, mettez-le en sourdine au lieu de le fermer.

Pourquoi vois-je des problèmes de régression pour les anciennes versions de l'application ?

Si un rapport provient d'une ancienne version de l'application qui n'a jamais envoyé de rapports d'erreur lorsque vous avez clôturé le problème, Crashlytics considère que le problème a régressé et le rouvre.

Cela peut se produire dans les cas suivants : vous avez corrigé un bug et publié une nouvelle version de votre application, mais certains utilisateurs utilisent encore des versions antérieures qui ne contiennent pas la correction du bug. Si, par hasard, l'une de ces versions antérieures n'a jamais envoyé de rapports d'erreur lorsque vous avez fermé le problème, et que ces utilisateurs commencent à rencontrer le bug, 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, "désactivez" le problème au lieu de le fermer.

Remarque : Avant février 2022, Crashlytics classait un problème comme régression lorsqu'il se reproduisait dans n'importe quelle version de l'application, même pour les versions de l'application que nous connaissions lorsque vous avez fermé le problème. Cela a parfois conduit Crashlytics à identifier des régressions de manière inexacte. Nous utilisons désormais la convention décrite ci-dessus.

Si vous constatez de nombreuses régressions mal identifiées avant février 2022, vous pouvez les fermer à nouveau pour éviter qu'elles ne se rouvrent.