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 recherchez ou si vous avez besoin d'aide supplémentaire, contactez l'assistance Firebase.
Dépannage général/FAQ
Affichage de différents formats (et parfois de "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'un design mis à jour et des fonctionnalités avancées pour les nouveaux problèmes (comme les 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 application (comme les plantages, les erreurs non fatales et les erreurs 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 la pile, le message d'exception, le code d'erreur et d'autres caractéristiques de plate-forme ou de type d'erreur.
Toutefois, dans ce groupe d'événements, les traces de la pile menant à la défaillance peuvent être différentes. Une trace de pile différente peut indiquer une cause première différente.
Pour représenter cette différence possible dans un problème, nous créons désormais des variantes dans les 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. 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 sont à l'origine de l'échec.
Voici ce que vous allez constater avec ces améliorations :
Métadonnées remaniées affichées dans la ligne du problème Vous pouvez désormais comprendre et trier plus facilement les problèmes de 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 de 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 performante Chaque problème contient des métadonnées dans lesquelles les recherches sont plus poussées, telles que 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 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.
Il s'agit de la première modification importante que nous apportons au regroupement des événements. Si vous avez des commentaires ou rencontrez des problèmes, n'hésitez pas à nous
envoyer un rapport
.
Les métriques d'utilisation sans plantage et/ou les alertes de vitesse ne s'affichent pas
Si vous ne voyez pas de métriques d'utilisation n'ayant pas subi de plantage (comme les utilisateurs et les sessions n'ayant pas subi de plantage)
et/ou les alertes de vitesse, assurez-vous d'utiliser
Les journaux de fil d'Ariane ne s'affichent pas
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:
Affichage de traces de pile non symbolisées pour les applications Android dans le tableau de bord Crashlytics
Si vous utilisez IL2CPP Unity et que des traces de pile non symbolisées s'affichent, procédez comme suit :
Assurez-vous d'utiliser la version 8.6.1 ou ultérieure du SDK Unity Crashlytics.
Assurez-vous d'avoir configuré et exécuté la commande crashlytics:symbols:upload de la CLI Firebase pour générer et importer votre fichier de symboles.
Vous devez exécuter cette commande CLI chaque fois que vous créez un build de version ou un build pour lequel vous souhaitez afficher des traces de pile symbolisées dans la console Firebase. Pour en savoir plus, consultez la page Obtenir des rapports de plantage lisibles.
Crashlytics peut-il être utilisé avec les applications qui utilisent IL2CPP ?
Oui, Crashlytics peut afficher des traces de pile décodées pour les 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 d'utiliser la version 8.6.0 ou ultérieure du SDK Unity Crashlytics.
Effectuez les tâches nécessaires pour votre plate-forme:
Pour les applications de la plate-forme Apple : aucune action particulière n'est requise. Pour les applications pour la plate-forme Apple, le plug-in Firebase Unity Editor configure automatiquement votre projet Xcode pour importer des symboles.
Pour les applications Android : assurez-vous d'avoir configuré et d'exécuter la commande crashlytics:symbols:upload de la CLI Firebase pour générer et importer votre fichier de symboles.
Vous devez exécuter cette commande CLI chaque fois que vous créez un build de version ou un build pour lequel vous souhaitez afficher des traces de pile symbolisées dans la console Firebase. Pour en savoir plus, consultez la page Obtenir des rapports de plantage lisibles.
Comment sont calculés les utilisateurs n'ayant pas subi de plantage ?
La valeur "Sans plantage" représente le pourcentage d'utilisateurs qui ont interagi avec votre application, mais qui n'ont pas subi de plantage au cours d'une période donnée.
Voici la formule permettant de calculer le pourcentage d'utilisateurs n'ayant pas subi de plantage. Ses valeurs d'entrée sont fournies par Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
En cas de plantage, Google Analytics envoie un type d'événement app_exception, et CRASHED_USERS représente le nombre d'utilisateurs associés à ce type d'événement.
ALL_USERS représente le nombre total d'utilisateurs ayant 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 n'ayant pas subi de plantage correspond à une agrégation au fil du temps, et non à une moyenne.
Par exemple, imaginons que votre application compte trois utilisateurs, que nous appellerons Utilisateur A, Utilisateur B et Utilisateur C. Le tableau suivant indique quels utilisateurs ont interagi avec votre application chaque jour et lesquels ont subi un plantage ce jour-là:
Lundi
Mardi
Mercredi
Utilisateurs ayant interagi avec votre application
A, B, C
A, B, C
A, B
Utilisateur ayant subi un plantage
C
B
A
Le mercredi, le pourcentage d'utilisateurs n'ayant pas subi de plantage est de 50 % (un utilisateur sur deux n'a pas subi de plantage). Deux de vos utilisateurs ont interagi avec votre application mercredi, mais seul l'un d'eux (l'utilisateur B) n'a pas rencontré de plantage.
Au cours des deux derniers jours, le pourcentage d'utilisateurs n'ayant pas subi de plantage est de 33,3% (un utilisateur sur trois n'a pas subi de plantage). Trois de vos utilisateurs ont interagi avec votre application au cours des deux derniers jours, mais seul l'un d'eux (l'utilisateur C) n'a pas rencontré de plantage.
Au cours des trois derniers jours, le pourcentage d'utilisateurs n'ayant pas subi de plantage est de 0% (0 utilisateur sur 3 n'a pas subi de plantage). Trois de vos utilisateurs ont interagi avec votre application au cours des trois derniers jours, mais aucun d'entre eux n'a subi de plantage.
La valeur des utilisateurs sans plantage ne doit pas être comparée sur différentes périodes.
La probabilité qu'un utilisateur unique subisse un plantage augmente à mesure qu'il utilise votre application. Par conséquent, la valeur des utilisateurs sans plantage est susceptible d'être plus faible sur de longues périodes.
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 de son compte Google. 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.
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 ni les supprimer, ni en rédiger.
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 de son compte Google. 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 rédiger de nouvelles sur un problème.
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 ni les supprimer, ni en rédiger.
L'application utilise également le SDK Google Mobile Ads, mais ne plante pas
Si votre projet utilise Crashlytics avec le SDK Google Mobile Ads, il est probable que les rapports d'erreur 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.
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 régressifs afin que vous puissiez les résoudre de manière appropriée pour 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 que vous l'avez clôturé.
Si le rapport provient d'une version d'application que Crashlyticsconnaissait lorsque vous avez clôturé le problème (c'est-à-dire que la version a envoyé un rapport d'erreur pour tout plantage), Crashlytics ne considérera pas le problème comme une régression. Le problème restera clôturé.
Si le rapport provient d'une version d'application dont Crashlyticsn'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 informer que Crashlytics a rouvert le problème. Si vous ne souhaitez pas qu'un problème soit à nouveau ouvert en raison de notre algorithme de régression, mettez-le "en sourdine" 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'a jamais envoyé de rapports de plantage lorsque vous avez clos le problème et que ces utilisateurs commencent à rencontrer le bug, ces rapports de plantage déclencheront un problème de régression.
Si vous ne souhaitez pas qu'un problème soit réouvert en raison de notre algorithme de régression, "ignorer" le problème au lieu de le fermer.
Signaler les exceptions non détectées en tant qu'événements fatals
Crashlytics peut signaler les exceptions non détectées en tant qu'exceptions fatales (à partir de la version 10.4.0 du SDK Unity). Les questions fréquentes suivantes expliquent la raison d'être et les bonnes pratiques concernant l'utilisation de cette fonctionnalité.
Pourquoi une application doit-elle signaler les exceptions non détectées en tant qu'événements fatals ?
En signalant les exceptions non détectées comme des erreurs fatales, vous obtenez une indication plus réaliste des exceptions pouvant rendre le jeu injouable, même si l'application continue de s'exécuter.
Notez que si vous commencez à signaler les erreurs fatales, le pourcentage d'utilisateurs sans plantage (CFU) diminuera probablement, mais la métrique CFU sera plus représentative de l'expérience des utilisateurs finaux avec votre application.
Quelles exceptions seront signalées comme fatales ?
Pour que Crashlytics signale une exception non détectée comme fatale, les deux conditions suivantes doivent être remplies :
Votre application (ou une bibliothèque incluse) génère une exception qui n'est pas interceptée. Une exception créée, mais non générée, n'est pas considérée comme non interceptée.
Après avoir activé le signalement des exceptions non détectées en tant qu'erreurs fatales, j'ai maintenant de nombreuses nouvelles erreurs fatales. Comment gérer correctement ces exceptions ?
Lorsque vous commencez à recevoir des rapports signalant vos exceptions non détectées en tant qu'erreurs fatales, voici quelques options pour gérer ces exceptions non détectées:
Les exceptions sont créées et générées pour refléter les états inattendus ou exceptionnels.
Pour résoudre les problèmes reflétés par une exception générée, vous devez rétablir le programme dans un état connu (processus appelé gestion des exceptions).
Il est recommandé de détecter et de gérer toutes les exceptions prévues, sauf si le programme ne peut pas être renvoyé à un état connu.
Journaliser les exceptions dans Unity ou Crashlytics
Il existe plusieurs façons d'enregistrer des exceptions dans Unity ou Crashlytics pour vous aider à déboguer le problème.
Lorsque vous utilisez Crashlytics, voici les deux options les plus courantes et recommandées :
Option 1 : Imprimer dans la console Unity, mais ne pas envoyer de rapport à Crashlytics, lors du développement ou du dépannage
Imprimer dans la console Unity à l'aide de Debug.Log(exception), Debug.LogWarning(exception) et Debug.LogError(exception), qui affichent le contenu de l'exception dans la console Unity et ne la renvoient pas à nouveau.
Option 2 : Importez les données dans Crashlytics pour obtenir des rapports consolidés dans le tableau de bord Crashlytics dans les cas suivants :
Si une exception vaut la peine d'être enregistré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 soit interceptée et traitée, utilisez Crashlytics.LogException(exception) pour la consigner en tant qu'événement non fatal.
Toutefois, si vous souhaitez signaler manuellement un événement fatal à Unity Cloud Diagnostics, vous pouvez utiliser Debug.LogException. Cette option affiche l'exception dans la console Unity comme l'option 1, mais elle l'exception également (qu'elle ait déjà été lancée ou interceptée). Il génère l'erreur de manière non locale. Cela signifie que même un Debug.LogException(exception) entouré de blocs try-catch génère toujours une exception non détectée.
N'appelez Debug.LogException que si vous souhaitez effectuer toutes les opérations suivantes:
Pour afficher l'exception dans la console Unity, procédez comme suit :
Pour importer l'exception dans Crashlytics en tant qu'événement fatal.
Pour générer l'exception, vous devez la traiter comme une exception non interceptée et la signaler à Unity Cloud Diagnostics.
Notez que si vous souhaitez imprimer une exception détectée dans la console Unity et l'importer dans Crashlytics en tant qu'événement non fatal, procédez comme suit :
try{methodThatThrowsMyCustomExceptionType();}catch(MyCustomExceptionTypeexception){// 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//}
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/11/09 (UTC).
[null,null,["Dernière mise à jour le 2024/11/09 (UTC)."],[],[]]
