Cette page a été traduite par l'API Cloud Translation.

Dépannage de Crashlytics et questions fréquentes

Cette page fournit une aide de dépannage et des réponses aux questions fréquentes sur l'utilisation de Crashlytics. Si vous vous n'avez pas trouvé ce que vous cherchez ou vous avez besoin d'une aide supplémentaire, contactez Assistance Firebase.

Dépannage général/Questions fréquentes

Affichage de différents formats (et parfois "variants") pour certains problèmes du tableau Issues (Problèmes)

Vous remarquerez peut-être deux formats différents pour les problèmes répertoriés dans votre tableau Problèmes. dans 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é permettant de regrouper les événements ainsi qu'un nouveau design et des fonctionnalités avancées pour de nouveaux problèmes (comme variantes !). Pour en savoir plus, consultez notre article de blog récent. Vous trouverez ci-dessous les points forts.

Crashlytics analyse tous les événements de votre appli (plantages, non fatals, et ANR) et crée des groupes d'événements appelés problèmes. Tous les événements d'une ont un point de défaillance commun.

Pour regrouper les événements dans ces problèmes, le moteur d'analyse amélioré prend désormais en compte de nombreux aspects de l'événement, y compris les frames dans la trace de la pile, message d'exception, code d'erreur et autre plate-forme ou type d'erreur caractéristiques.

Toutefois, dans ce groupe d'événements, les traces de pile menant à l'échec peuvent être différents. Une autre trace de la pile peut indiquer une autre cause. Pour représenter cette différence possible au sein d'un problème, nous créons maintenant variantes au sein d'un même problème : chaque variante est un sous-groupe d'événements dans un problème. qui présentent 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 d'un problème et déterminer si différentes causes sont à l'origine de l'échec.

Voici ce que vous allez constater avec ces améliorations :

Nouvelles métadonnées affichées sur 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 ne génère pas de 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 pertinents
Un nouveau problème est en fait un nouveau bug.
Recherche plus efficace
Chaque problème contient plus de métadonnées pouvant être recherchées, comme le type d'exception et le nom du package.

Voici comment ces améliorations seront 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 à l'événement et créer un problème avec les nouvelles métadonnées la conception.

Il s'agit de la première modification importante que nous apportons au regroupement des événements. Si vous si vous avez des commentaires ou rencontrez des problèmes, veuillez nous en informer en envoyant un signalement.

Ne pas voir des métriques d'utilisation sans plantage et/ou des alertes de vitesse ;

Si vous ne voyez pas de métriques sur l'utilisation sans plantage (par exemple, les utilisateurs et les sessions n'ayant pas subi de plantage) et/ou des alertes de vitesse, assurez-vous d'utiliser le

Les journaux de fil d'Ariane ne s'affichent pas

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 Google Analytics activé dans votre projet Firebase.
Vous avez activé le partage de données pour Google Analytics. Pour en savoir plus sur ce paramètre, consultez 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.

Qui peut consulter, 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, celle-ci est associée à l'adresse e-mail Google Cloud. Cette adresse e-mail, ainsi que la note, sont visibles par tous les membres du projet autorisés à les consulter.

Vous trouverez ci-dessous 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 créer de nouvelles pour un problème.
- Propriétaire ou éditeur du projet Administrateur Firebase, Administrateur qualité, ou Administrateur Crashlytics
Les membres du projet disposant de l'un des rôles suivants peuvent afficher les notes publiées sur un problème, mais ne peuvent pas les supprimer ni en écrire.
- Lecteur de projet Lecteur Firebase, Lecteur de qualité, ou Lecteur Crashlytics

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.

Vous trouverez ci-dessous 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 créer de nouvelles pour un problème.
- Propriétaire ou éditeur du projet Administrateur Firebase, Administrateur qualité, ou Administrateur Crashlytics
Les membres du projet dotés de l'un des rôles suivants peuvent consulter les notes publiées sur un problème, mais il ne peut pas supprimer ni rédiger de note.
- Project Viewer (Lecteur de projet), Firebase Viewer (Lecteur Firebase), Quality Viewer (Lecteur de qualité) ou Crashlytics Viewer (Lecteur Crashlytics)

Intégrations

L'application utilise également la Google Mobile Ads SDK, mais pas de plantages

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 le signalement des plantages 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 de régression ?

Un problème a régressé lorsque vous l'avez déjà fermé, mais que Crashlytics reçoit un nouveau rapport indiquant qu'il est à nouveau survenu. Crashlytics rouvre automatiquement ces problèmes de régression afin que vous puissiez les résoudre en fonction de votre application.

Voici un exemple de scénario expliquant comment Crashlytics catégorise un problème en tant que régression :

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").
Vous corrigez ce bug rapidement, fermez le problème "A", puis publiez une nouvelle version de votre application.
Crashlytics reçoit un autre signalement concernant le problème "A" après avoir fermé problème.
- Si le rapport provient d'une version de l'application que Crashlytics connaissait La date de clôture du problème (la version ayant généré un plantage signaler aucun plantage, alors Crashlytics ne prend pas en compte comme régressif. Le problème restera clôturé.
- Si le rapport provient d'une version d'application dont Crashlytics n'avait pas connaissance lorsque vous avez clôturé le problème (c'est-à-dire que la version n'a jamais envoyé aucun rapport d'erreur pour un plantage), Crashlytics considère que le problème est en régression et le rouvre.

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

Pourquoi des problèmes de régression apparaissent-ils 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.

Cette situation peut se produire dans les cas suivants : vous avez corrigé un bug et publié une nouvelle version de votre application, mais des utilisateurs utilisent toujours d'anciennes versions sans correction du bug. Si, par hasard, l'une de ces anciennes versions n'avait jamais envoyé des rapports d'erreur quand vous avez fermé le problème rencontrant le bug, ces rapports d'erreur déclenchent un problème régressif.

Si vous ne souhaitez pas qu'un problème soit de nouveau ouvert en raison de notre algorithme de régression, "couper le son" le problème au lieu de le fermer.