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 CrashlyticsSDK Crashlytics 11.7.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.
Si vous utilisez Unity IL2CPP et que vous voyez des traces de pile non symbolisées, essayez ce qui suit :
Assurez-vous que vous utilisez la version 8.6.1 ou supérieure du SDK Crashlytics Unity.
Assurez-vous que vous êtes configuré et exécutez la commande
crashlytics:symbols:uploadde la CLI Firebase pour générer et télécharger votre fichier de symboles.Vous devez exécuter cette commande CLI chaque fois que vous créez une version de version ou toute version pour laquelle vous souhaitez voir les traces de pile symbolisées dans la console Firebase. Apprenez-en davantage sur la page Obtenir des rapports d’erreur lisibles .
Oui, Crashlytics peut afficher des traces de pile symbolisées pour vos applications qui utilisent IL2CPP. Cette fonctionnalité est disponible pour les applications publiées sur les plates-formes Android ou Apple. Voici ce que vous devez faire :
Assurez-vous que vous utilisez la version 8.6.0 ou supérieure du SDK Crashlytics Unity.
Effectuez les tâches nécessaires pour votre plateforme :
Pour les applications de la plateforme Apple : aucune action particulière n'est requise. Pour les applications de la plateforme Apple, le plugin Firebase Unity Editor configure automatiquement votre projet Xcode pour télécharger des symboles.
Pour les applications Android : assurez-vous que vous êtes configuré pour et que vous exécutez la commande
crashlytics:symbols:uploadla CLI Firebase pour générer et télécharger votre fichier de symboles.Vous devez exécuter cette commande CLI chaque fois que vous créez une version de version ou toute version pour laquelle vous souhaitez voir les traces de pile symbolisées dans la console Firebase. Apprenez-en davantage sur la page Obtenir des rapports d’erreur lisibles .
La valeur sans crash représente le pourcentage d'utilisateurs qui ont interagi avec votre application mais n'ont pas rencontré de crash sur une période de temps spécifique.
Voici la formule pour calculer le pourcentage d’utilisateurs sans crash. Ses valeurs d'entrée sont fournies par Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Lorsqu'un crash 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 crash est une agrégation au fil du 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 ont interagi avec votre application chaque jour et lesquels de ces utilisateurs ont eu un crash ce jour-là :
| Lundi | Mardi | Mercredi | |
|---|---|---|---|
| Utilisateurs qui ont interagi avec votre application | A, B, C | A, B, C | UN B |
| Utilisateur qui a eu un crash | C | B | UN |
Mercredi, votre pourcentage d'utilisateurs sans crash est de 50 % (1 utilisateur sur 2 n'a eu aucun crash).
Deux de vos utilisateurs ont interagi avec votre application mercredi, mais un seul d'entre eux (utilisateur B) n'a eu aucun plantage.Au cours des 2 derniers jours, votre pourcentage d'utilisateurs sans crash est de 33,3 % (1 utilisateur sur 3 n'a eu aucun crash).
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 eu aucun plantage.Au cours des 3 derniers jours, votre pourcentage d'utilisateurs sans crash est de 0 % (0 utilisateur sur 3 n'a eu aucun crash).
Trois de vos utilisateurs ont interagi avec votre application au cours des trois derniers jours, mais aucun d'entre eux n'a rencontré de crash.
La valeur des utilisateurs sans crash ne doit pas être comparée sur différentes périodes. La probabilité qu'un seul utilisateur subisse un crash augmente à mesure qu'il utilise votre application, de sorte que la valeur des utilisateurs sans crash est susceptible d'être plus faible sur des périodes plus longues.
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.
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.
Signaler les exceptions non interceptées comme fatales
Crashlytics peut signaler les exceptions non interceptées comme fatales (à partir de la version 10.4.0 du SDK Unity). Les FAQ suivantes aident à expliquer la justification et les meilleures pratiques d'utilisation de cette fonctionnalité.
En signalant les exceptions non interceptées comme fatales, vous obtenez une indication plus réaliste des exceptions qui peuvent rendre le jeu injouable, même si l'application continue de fonctionner.
Notez que si vous commencez à signaler les incidents mortels, votre pourcentage d'utilisateurs sans crash (CFU) diminuera probablement, mais la métrique CFU sera plus représentative de l'expérience des utilisateurs finaux avec votre application.
Pour que Crashlytics signale une exception non interceptée comme fatale, les deux conditions suivantes doivent être remplies :
Lors de l'initialisation dans votre application, la propriété
ReportUncaughtExceptionsAsFataldoit être définie surtrue.Votre application (ou une bibliothèque incluse) génère une exception qui n'est pas interceptée. Une exception créée, mais non levée , n'est pas considérée comme non interceptée.
Lorsque vous commencez à recevoir des rapports signalant vos exceptions non interceptées comme étant fatales, voici quelques options pour gérer ces exceptions non interceptées :
- Réfléchissez à la manière dont vous pouvez commencer à détecter et gérer ces exceptions non détectées.
- Envisagez différentes options pour consigner les exceptions dans la console de débogage Unity et dans Crashlytics.
Attraper et gérer les exceptions levées
Des exceptions sont créées et levées pour refléter des états inattendus ou exceptionnels . La résolution des problèmes reflétés par une exception levée implique de ramener le programme à un état connu (un processus appelé gestion des exceptions ).
Il est recommandé de détecter et de gérer toutes les exceptions prévues, à moins que le programme ne puisse pas être ramené à un état connu.
Pour contrôler quels types d'exceptions sont interceptés et gérés par quel code, enveloppez le code susceptible de générer une exception dans un bloc try-catch . Assurez-vous que les conditions dans les instructions catch sont aussi étroites que possible pour gérer les exceptions spécifiques de manière appropriée.
Consigner les exceptions dans Unity ou Crashlytics
Il existe plusieurs façons d'enregistrer des exceptions dans Unity ou Crashlytics pour aider à déboguer le problème.
Lorsque vous utilisez Crashlytics, voici les deux options les plus courantes et recommandées :
Option 1 : Imprimez dans la console Unity, mais ne faites pas de rapport à Crashlytics, pendant le développement ou le dépannage
- Imprimez sur la console Unity à l'aide de
Debug.Log(exception),Debug.LogWarning(exception)etDebug.LogError(exception)qui impriment le contenu de l'exception sur la console Unity et ne renvoient pas l'exception.
- Imprimez sur la console Unity à l'aide de
Option 2 : importer vers Crashlytics pour obtenir des rapports consolidés dans le tableau de bord Crashlytics pour les situations suivantes :
- Si une exception mérite d'être consignée pour déboguer un éventuel événement Crashlytics ultérieur, utilisez
Crashlytics.Log(exception.ToString()). - Si une exception doit toujours être signalée à Crashlytics bien qu'elle ait été interceptée et gérée, utilisez
Crashlytics.LogException(exception)pour la consigner en tant qu'événement non fatal.
- Si une exception mérite d'être consignée pour déboguer un éventuel événement Crashlytics ultérieur, utilisez
Toutefois, si vous souhaitez signaler manuellement un événement fatal à Unity Cloud Diagnostics, vous pouvez utiliser Debug.LogException . Cette option imprime l'exception sur la console Unity comme l'option 1, mais elle lève également l'exception (qu'elle ait déjà été levée ou interceptée ou non). Il renvoie l'erreur de manière non locale. Cela signifie que même une Debug.LogException(exception) environnante avec des blocs try-catch entraîne toujours une exception non interceptée.
Par conséquent, appelez Debug.LogException si et seulement si vous souhaitez effectuer toutes les opérations suivantes :
- Pour imprimer l'exception sur la console Unity.
- Pour télécharger l'exception sur Crashlytics en tant qu'événement fatal.
- Pour lever l'exception, faites-la traiter comme une exception non interceptée et signalez-la à Unity Cloud Diagnostics.
Notez que si vous souhaitez imprimer une exception interceptée sur la console Unity et la télécharger sur Crashlytics en tant qu'événement non fatal, procédez plutôt comme suit :
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}