| Sélectionnez une plate-forme : | iOS+ Android Flutter Unity |
Vous pouvez cliquer sur un problème et obtenir un rapport d'événement détaillé dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase. Vous pouvez personnaliser ces rapports pour mieux comprendre ce qui se passe dans votre application et les circonstances des événements signalés à Crashlytics.
Signalez les exceptions interceptées et les exceptions non interceptées à Crashlytics.
Incluez les rapports GWP-ASan pour résoudre les problèmes de mémoire corrompue.
Instrumentez votre application pour consigner des clés personnalisées, des messages de journal personnalisés et des identifiants utilisateur.
Obtenez automatiquement des journaux du fil d'Ariane si votre application utilise le SDK Firebase pour Google Analytics. Ces journaux vous permettent de voir les actions des utilisateurs qui ont conduit à un événement collecté par Crashlytics dans votre application.
Désactivez les rapports d'erreur automatiques et activez les rapports d'erreur activables pour vos utilisateurs. Notez que, par défaut, Crashlytics collecte automatiquement les rapports d'erreur pour tous les utilisateurs de votre application.
Signaler des exceptions
Signaler les exceptions interceptées
Si vous avez des exceptions attendues, vous pouvez demander au SDK Crashlytics de les signaler comme des événements non fatals. Ces événements sont consignés sur l'appareil, puis envoyés avec le rapport d'événement fatal suivant ou lorsque l'utilisateur final redémarre le jeu.
Vous pouvez consigner les exceptions en C# à l'aide de la méthode suivante :
Crashlytics.LogException(Exception ex);
Vous pouvez consigner les exceptions attendues dans les blocs try/catch de votre jeu :
try { myMethodThatThrows(); } catch (Exception e) { Crashlytics.LogException(e); // handle your exception here! }
Signaler les exceptions non détectées
Pour les exceptions non détectées qui n'entraînent pas le plantage de votre jeu (par exemple, les exceptions C# non détectées dans la logique du jeu), vous pouvez demander au SDK Crashlytics de les signaler en tant qu'événements fatals en définissant la propriété Crashlytics.ReportUncaughtExceptionsAsFatal sur true là où vous initialisez Crashlytics dans votre projet Unity.
Ces événements sont signalés à Crashlytics en temps réel, sans que l'utilisateur final ait besoin de redémarrer le jeu.
Le signalement de ces exceptions non détectées en tant qu'événements fatals signifie qu'elles seront prises en compte dans vos statistiques d'utilisation sans plantage et dans les alertes de vitesse.
Notez que les plantages natifs sont toujours signalés comme des événements fatals. Ces événements sont enregistrés sur l'appareil, puis envoyés lorsque l'utilisateur final redémarre le jeu.
void Start() { // Since there is no try-block surrounding this call, if an exception is thrown, // it is considered unexpected. // Setting `Crashlytics.ReportUncaughtExceptionsAsFatal = true` // will ensure that such cases are reported as fatals. thirdPartyMethodThatMayThrow(); }
Inclure les rapports GWP-ASan pour résoudre les problèmes de mémoire corrompue
Pour les applications Android qui utilisent IL2CPP, Crashlytics peut vous aider à déboguer les plantages causés par des erreurs de mémoire native en collectant des rapports GWP-ASan. Ces erreurs liées à la mémoire peuvent être associées à une corruption de la mémoire dans votre application, ce qui est la principale cause des failles de sécurité des applications.
Dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase, vous pouvez effectuer les opérations suivantes avec ces données :
Vous pouvez afficher ces données dans un nouvel onglet "Traces de la pile de mémoire" lorsque vous cliquez sur les détails d'un problème.
Vous pouvez utiliser le nouveau signal et le nouveau filtre "Rapport GWP-ASan" pour afficher rapidement tous les problèmes liés à ces données.
Vous pouvez obtenir des rapports sur la mémoire GWP-ASan si votre application utilise la dernière version du SDK Crashlytics pour Unity (v10.7.0 ou ultérieure) et que GWP-ASan est explicitement activé (vous devez modifier le fichier manifeste de votre application Android). Si votre application contient du code C++, vous pouvez tester votre configuration GWP-ASan à l'aide de l'exemple de code natif de la documentation Android.
Ajouter des clés personnalisées
Les clés personnalisées vous permettent de connaître l'état spécifique de votre application pouvant entraîner un plantage. Vous pouvez associer des paires clé-valeur arbitraires à vos rapports d'erreur, puis utiliser les clés personnalisées pour rechercher et filtrer les rapports d'erreur dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase.
Vous pouvez rechercher des problèmes correspondant à une clé personnalisée.
Lorsque vous examinez un problème spécifique dans la console, vous pouvez afficher les clés personnalisées associées à chaque événement (sous-onglet Clés) et même filtrer les événements par clés personnalisées (menu Filtre en haut de la page).
En cas d'appels multiples, les nouvelles valeurs des clés existantes mettent à jour la valeur, et seule la valeur la plus récente est capturée lorsqu'un plantage est enregistré.
Crashlytics.SetCustomKey(string key, string value);
Ajouter des messages de journal personnalisés
Pour obtenir plus de contexte sur les événements qui ont précédé un plantage, vous pouvez ajouter des journaux Crashlytics personnalisés à votre application. Crashlytics associe les journaux à vos données de plantage et les affiche dans l'onglet Journaux lorsque vous consultez les détails d'un problème (consultez tous vos problèmes dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase).
Crashlytics.Log(string message);
Définir des identifiants utilisateur
Vous pouvez utiliser un numéro d'identification, un jeton ou une valeur de hachage pour identifier de manière unique l'utilisateur final de votre application sans divulguer ni transmettre ses informations personnelles. Vous pouvez également effacer la valeur en la définissant sur une chaîne vide. Cette valeur s'affiche lorsque vous consultez un plantage spécifique dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase.
Crashlytics.SetUserId(string identifier);
Obtenir les journaux du fil d'Ariane
Les journaux du fil d'Ariane vous permettent de mieux comprendre les interactions d'un utilisateur avec votre application avant un plantage, une erreur non fatale ou un événement ANR. Ces journaux peuvent être utiles pour reproduire et déboguer un problème.
Les journaux du fil d'Ariane sont fournis par Google Analytics. Pour les obtenir, vous devez activer Google Analytics pour votre projet Firebase et ajouter le SDK Firebase pour Google Analytics à votre application. Une fois ces conditions remplies, les journaux du fil d'Ariane sont automatiquement inclus dans les données d'un événement dans l'onglet Journaux lorsque vous affichez les détails d'un problème (consultez tous vos problèmes dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase).
Le SDK Analytics enregistre automatiquement l'événement screen_view, ce qui permet aux journaux du fil d'Ariane d'afficher la liste des écrans consultés avant le plantage, l'erreur non fatale ou l'événement ANR. Un journal du fil d'Ariane screen_view contient un paramètre firebase_screen_class.
Les journaux du fil d'Ariane sont également renseignés avec tous les événements personnalisés que vous enregistrez manuellement au cours de la session de l'utilisateur, y compris les données des paramètres de l'événement. Ces données peuvent aider à afficher une série d'actions utilisateur ayant conduit à un plantage, un problème non fatal ou un événement ANR.
Notez que vous pouvez contrôler la collecte et l'utilisation des données Google Analytics, y compris les données qui alimentent les journaux du fil d'Ariane.
Activer le reporting d'activation
Par défaut, Crashlytics collecte automatiquement les rapports d'erreur pour tous les utilisateurs de votre application. Vous pouvez donner aux utilisateurs plus de contrôle sur les données qu'ils envoient en leur permettant d'activer le signalement des plantages.
Pour désactiver la collecte automatique uniquement pour certains utilisateurs, appelez le remplacement de la collecte de données Crashlytics au moment de l'exécution. La valeur de remplacement persiste lors de tous les lancements ultérieurs de votre application, de sorte que Crashlytics puisse collecter automatiquement les rapports pour cet utilisateur.
Crashlytics.IsCrashlyticsCollectionEnabled = true
Si l'utilisateur désactive ultérieurement la collecte de données, vous pouvez transmettre false comme valeur de remplacement. Elle sera appliquée la prochaine fois que l'utilisateur lancera l'application et persistera lors de tous les lancements ultérieurs pour cet utilisateur.
Gérer les données Crash Insights
Les insights sur les plantages vous aident à résoudre les problèmes en comparant vos traces de pile anonymisées à celles d'autres applications Firebase et en vous indiquant si votre problème s'inscrit dans une tendance plus générale. Pour de nombreux problèmes, Crash Insights fournit même des ressources pour vous aider à déboguer le plantage.
Crash Insights utilise des données de plantage agrégées pour identifier les tendances courantes en matière de stabilité. Si vous préférez ne pas partager les données de votre application, vous pouvez désactiver les insights sur les plantages dans le menu Insights sur les plantages en haut de la liste des problèmes dans le tableau de bord DevOps et engagement > Crashlytics de la console Firebase.
Étapes suivantes
- Exportez vos données vers BigQuery ou Cloud Logging pour bénéficier d'analyses et de fonctionnalités avancées, comme l'interrogation de vos données, la création de tableaux de bord personnalisés et la configuration d'alertes personnalisées.