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

Dépannage de Crashlytics et questions fréquentes

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 des "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 la 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 consultables, 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 introuvables

Si vous ne voyez pas de journaux de fil d'Ariane (iOS+ | Android | Flutter | Unity), 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 ajouté à votre application le SDK Firebase pour Google Analytics : iOS+ | Android | Flutter | Unity.
Ce SDK doit être ajouté en plus du SDK Crashlytics.
Vous utilisez les dernières versions du SDK Firebase pour tous les produits que vous utilisez dans votre application (iOS+ | Android | Flutter | Unity).

Pour les plates-formes Apple et les applications Android, vérifiez en particulier que vous utilisez au minimum la version suivante du SDK Firebase pour Google Analytics : iOS+ : v6.3.1+ (v8.9.0+ pour macOS et tvOS) | Android : v17.2.3+ (BoM v24.7.1+).

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 d'utilisation 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. L'exactitude des métriques sans plantage sera donc 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, avec 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

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 :

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 rapidement ce bug, clôturez 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 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'avait pas connaissance du problème lorsque vous l'avez clôturé (c'est-à-dire que la version n'avait jamais envoyé aucun rapport d'erreur pour une erreur quelconque), 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 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.

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.

Assistance spécifique à la plate-forme

Les sections suivantes fournissent une assistance pour le dépannage et les questions fréquentes spécifiques à chaque plate-forme : iOS+ | Android | Unity.

Compatibilité avec les plates-formes Apple

Fichiers dSYM manquants/non importés

Pour importer les dSYM de votre projet et obtenir une sortie détaillée, vérifiez les points suivants :

Assurez-vous que la phase de compilation de votre projet contient le script d'exécution Crashlytics, qui permet à Xcode d'importer les fichiers dSYM de votre projet au moment de la compilation (consultez Initialiser Crashlytics pour savoir comment ajouter le script). Après avoir mis à jour votre projet, forcez un plantage et vérifiez qu'il apparaît dans le tableau de bord Crashlytics.
Si une alerte "dSYM manquant" s'affiche dans la console Firebase, vérifiez dans Xcode que les dSYM sont correctement générés pour la compilation.
Si Xcode produit correctement des fichiers dSYM et que vous constatez toujours qu'il en manque, il est probable que l'outil de script d'exécution soit bloqué lors de l'importation des fichiers dSYM. Dans ce cas, essayez chacune des solutions suivantes :
- Assurez-vous d'utiliser la dernière version de Crashlytics.
- Importez manuellement les fichiers dSYM manquants :
  - Option 1 : Utilisez l'option "Glisser-déposer" basée sur la console dans l'onglet dSYMs pour importer une archive ZIP contenant les fichiers dSYM manquants.
  - Option 2 : Utilisez le script upload-symbols pour importer les fichiers dSYM manquants pour les UUID fournis dans l'onglet Fichiers dSYM.
Si des fichiers dSYM continuent de manquer ou si les importations échouent toujours, contactez l'assistance Firebase et veillez à inclure vos journaux.

Les plantages sont mal symbolisés

Si vos traces de pile semblent mal décodées, vérifiez les points suivants :

Si les frames de la bibliothèque de votre application ne contiennent pas de références au code de votre application, assurez-vous que -fomit-frame-pointer n'est pas défini comme indicateur de compilation.
Si vous voyez plusieurs frames (Missing) pour la bibliothèque de votre application, vérifiez si des dSYM optionnels sont indiqués comme manquants (pour la version concernée de l'application) dans l'onglet Crashlytics dSYM de la console Firebase. Si c'est le cas, suivez la procédure de dépannage "Alerte de fichier dSYM manquant" dans la FAQ sur les fichiers dSYM manquants ou non importés sur cette page. Notez que l'importation de ces fichiers dSYM ne permettra pas de symboliser les plantages qui se sont déjà produits, mais elle contribuera à garantir la symbolisation des futurs plantages.

Puis-je utiliser Crashlytics pour macOS ou tvOS ?

Oui, vous pouvez implémenter Crashlytics dans les projets macOS et tvOS. Veillez à inclure la version 8.9.0 ou ultérieure du SDK Firebase pour Google Analytics afin que les plantages aient accès aux métriques collectées par Google Analytics (utilisateurs sans plantage, dernière version, alertes de vélocité et journaux de breadcrumbs).

Puis-je utiliser Crashlytics dans un projet Firebase comportant plusieurs applications sur différentes plates-formes Apple ?

Vous pouvez désormais signaler les plantages de plusieurs applications dans un même projet Firebase, même si les applications sont conçues pour différentes plates-formes Apple (par exemple, iOS, tvOS et Mac Catalyst). Auparavant, vous deviez séparer les applications dans des projets Firebase individuels si elles contenaient le même ID de bundle.

Compatibilité avec Android

Pourquoi les erreurs ANR ne sont-elles signalées que pour Android 11 et versions ultérieures ?

Crashlytics est compatible avec le signalement des erreurs ANR pour les applications Android sur les appareils équipés d'Android 11 ou version ultérieure. L'API sous-jacente que nous utilisons pour collecter les ANR (getHistoricalProcessExitReasons) est plus fiable que les approches basées sur SIGQUIT ou le watchdog. Cette API n'est disponible que sur les appareils Android 11 et versions ultérieures.

Pourquoi certaines erreurs ANR ne sont-elles pas associées à des `BuildId` ?

Si certains de vos ANR ne comportent pas de BuildId, procédez comme suit :

Assurez-vous d'utiliser une version à jour du SDK Android Crashlytics et du plug-in Gradle Crashlytics.

Si vous ne voyez pas les BuildId pour Android 11 et certaines ANR Android 12, il est probable que vous utilisiez un SDK ou un plug-in Gradle obsolètes, ou les deux. Pour collecter correctement les BuildId pour ces ANR, vous devez utiliser les versions suivantes :
- Crashlytics SDK Android v18.3.5+ (Firebase BoM v31.2.2+)
- Plug-in Gradle 2.9.4 ou version ultérieureCrashlytics
Vérifiez si vous utilisez un emplacement non standard pour vos bibliothèques partagées.

Si vous ne trouvez pas les BuildId de vos bibliothèques partagées, il est probable que vous n'utilisiez pas l'emplacement standard par défaut pour les bibliothèques partagées. Dans ce cas, il est possible que Crashlytics ne puisse pas localiser les BuildId associés. Nous vous recommandons d'utiliser l'emplacement standard pour les bibliothèques partagées.
Assurez-vous de ne pas supprimer les BuildId pendant le processus de compilation.

Notez que les conseils de dépannage suivants s'appliquent à la fois aux ANR et aux plantages natifs.
- Vérifiez si les BuildId existent en exécutant readelf -n sur vos binaires. Si les BuildId sont absents, ajoutez -Wl,--build-id aux indicateurs de votre système de compilation.
- Vérifiez que vous ne supprimez pas involontairement les BuildId afin de réduire la taille de votre fichier APK.
- Si vous conservez des versions dépouillées et non dépouillées d'une bibliothèque, veillez à pointer vers la bonne version dans votre code.

Différences entre les rapports ANR dans le tableau de bord Crashlytics et la Google Play Console

Il peut y avoir une différence entre le nombre d'ANR sur Google Play et sur Crashlytics. Cela est normal en raison de la différence dans le mécanisme de collecte et de reporting des données ANR. Crashlytics signale les ANR au prochain démarrage de l'application, tandis qu'Android Vitals envoie les données ANR après leur survenue.

De plus, Crashlytics n'affiche que les ANR qui se produisent sur les appareils exécutant Android 11 ou version ultérieure, contrairement à Google Play qui affiche les ANR des appareils pour lesquels les services Google Play et le consentement à la collecte de données sont acceptés.

Pourquoi des plantages de fichiers `.kt` sont-ils signalés comme des problèmes `.java` ?

Lorsqu'une application utilise un obfuscateur qui n'expose pas l'extension de fichier, Crashlytics génère chaque problème avec une extension de fichier .java par défaut.

Pour que Crashlytics puisse générer des problèmes avec la bonne extension de fichier, assurez-vous que votre application utilise la configuration suivante :

Utilise Android Gradle 4.2.0 ou version ultérieure
Utilise R8 avec l'obscurcissement activé. Pour mettre à jour votre application vers R8, consultez cette documentation.

Notez qu'après la mise à jour vers la configuration décrite ci-dessus, vous verrez peut-être de nouveaux problèmes .kt qui sont des doublons de problèmes .java existants. Pour en savoir plus sur cette situation, consultez les questions fréquentes.

Pourquoi des problèmes `.kt` s'affichent-ils alors qu'il s'agit de doublons de problèmes `.java` existants ?

À partir de mi-décembre 2021, Crashlytics la compatibilité avec les applications utilisant Kotlin sera améliorée.

Jusqu'à récemment, les obfuscateurs disponibles n'exposaient pas l'extension de fichier. Par conséquent, Crashlytics générait chaque problème avec une extension de fichier .java par défaut. Toutefois, à partir d'Android Gradle 4.2.0, R8 est compatible avec les extensions de fichier.

Grâce à cette mise à jour, Crashlytics peut désormais déterminer si chaque classe utilisée dans l'application est écrite en Kotlin et inclure le nom de fichier correct dans la signature du problème. Les plantages sont désormais correctement attribués aux fichiers .kt (le cas échéant) si votre application est configurée comme suit :

Votre application utilise Android Gradle 4.2.0 ou version ultérieure.
Votre application utilise R8 avec l'obscurcissement activé.

Étant donné que les nouveaux plantages incluent désormais la bonne extension de fichier dans la signature du problème, il est possible que de nouveaux problèmes .kt soient en fait des doublons de problèmes existants portant le libellé .java. Dans la console Firebase, nous essayons d'identifier les nouveaux problèmes .kt qui pourraient être des doublons de problèmes existants portant le libellé .java et de vous en informer.

Aucun plantage avec Dexguard

Si l'exception suivante s'affiche, cela signifie probablement que vous utilisez une version de DexGuard incompatible avec le SDK Firebase Crashlytics :

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Cette exception ne plante pas votre application, mais l'empêche d'envoyer des rapports d'erreur. Pour résoudre ce problème, procédez comme suit :

Assurez-vous d'utiliser la dernière version 8.x de DexGuard. La dernière version contient les règles requises par le SDK Firebase Crashlytics.
Si vous ne souhaitez pas modifier votre version de DexGuard, essayez d'ajouter la ligne suivante à vos règles d'obscurcissement (dans votre fichier de configuration DexGuard) :
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

Assistance spécifique à Android NDK

Différences entre les traces de pile NDK dans le tableau de bord Crashlytics et logcat

Les chaînes d'outils LLVM et GNU ont des valeurs par défaut et des traitements distincts pour le segment en lecture seule des binaires de votre application, ce qui peut générer des traces de pile incohérentes dans la console Firebase. Pour atténuer ce problème, ajoutez les indicateurs d'éditeur de liens suivants à votre processus de compilation :

Si vous utilisez l'éditeur de liens lld de la chaîne d'outils LLVM, ajoutez :
```
-Wl,--no-rosegment
```
Si vous utilisez l'éditeur de liens ld.gold de la chaîne d'outils GNU, ajoutez :
```
-Wl,--rosegment
```

Si vous constatez toujours des incohérences dans la trace de pile (ou si aucun des indicateurs n'est pertinent pour votre chaîne d'outils), essayez plutôt d'ajouter les éléments suivants à votre processus de compilation :

-fno-omit-frame-pointer

Comment utiliser mon propre fichier binaire de générateur de fichiers de symboles Breakpad pour le NDK ?

Le plug-in Crashlytics regroupe un générateur de fichiers de symboles Breakpad personnalisés. Si vous préférez utiliser votre propre binaire pour générer des fichiers de symboles Breakpad (par exemple, si vous préférez compiler tous les exécutables natifs de votre chaîne de compilation à partir de la source), utilisez la propriété d'extension facultative symbolGeneratorBinary pour spécifier le chemin d'accès à l'exécutable.

Vous pouvez spécifier le chemin d'accès au fichier binaire du générateur de fichiers de symboles Breakpad de deux manières :

Option 1 : Spécifier le chemin d'accès via l'extension firebaseCrashlytics dans votre fichier build.gradle

Ajoutez le code ci-dessous à votre fichier build.gradle.kts au niveau de l'application :

Plug-in Gradle v3.0.0 ou version ultérieure

android {
  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        // Add these optional fields to specify the path to the executable
        symbolGeneratorType = "breakpad"
        breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
      }
    }
  }
}

versions antérieures du plug-in

android {
  // ...
  buildTypes {
    // ...
    release {
      // ...
      firebaseCrashlytics {
        // existing; required for either symbol file generator
        nativeSymbolUploadEnabled true
        // Add this optional new block to specify the path to the executable
        symbolGenerator {
          breakpad {
            binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
          }
        }
      }
   }
}

Option 2 : Spécifiez le chemin d'accès via une ligne de propriété dans votre fichier de propriétés Gradle.

Vous pouvez utiliser la propriété com.google.firebase.crashlytics.breakpadBinary pour spécifier le chemin d'accès à l'exécutable.

Vous pouvez mettre à jour manuellement votre fichier de propriétés Gradle ou le mettre à jour via la ligne de commande. Par exemple, pour spécifier le chemin d'accès via la ligne de commande, utilisez une commande comme celle-ci :
```
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
  -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
  app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
```

Crashlytics est-il compatible avec armeabi ?

Le NDK Firebase Crashlytics n'est pas compatible avec ARMv5 (armeabi). La compatibilité avec cette ABI a été supprimée dans NDK r17.

Assistance Unity

Afficher les traces de pile non symbolisées pour les applications Android dans le tableau de bord Crashlytics

Si vous utilisez IL2CPP Unity et que vous voyez des traces de pile non symbolisées, essayez ce qui suit :

Assurez-vous d'utiliser la version 8.6.1 ou ultérieure du SDK Unity Crashlytics.
Assurez-vous d'être configuré pour exécuter la commande crashlytics:symbols:upload de la CLI Firebase afin de générer et d'importer votre fichier de symboles.

Vous devez exécuter cette commande CLI chaque fois que vous créez un build de version ou tout build pour lequel vous souhaitez afficher des traces de pile symbolisées dans la console Firebase. Pour en savoir plus, consultez Obtenir des rapports d'erreur lisibles.

Crashlytics peut-il être utilisé avec des applications qui utilisent IL2CPP ?

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. Procédez comme suit :

Assurez-vous d'utiliser la version 8.6.0 ou ultérieure du SDK Crashlytics Unity.
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 de la plate-forme Apple, le plug-in Firebase Unity Editor configure automatiquement votre projet Xcode pour importer les symboles.
- Pour les applications Android : assurez-vous d'être configuré pour exécuter la commande crashlytics:symbols:upload de la CLI Firebase afin de générer et d'importer votre fichier de symboles.
  
  Vous devez exécuter cette commande CLI chaque fois que vous créez un build de version ou tout build pour lequel vous souhaitez afficher des traces de pile symbolisées dans la console Firebase. Pour en savoir plus, consultez Obtenir des rapports d'erreur lisibles.

Signaler les exceptions non détectées comme fatales

Crashlytics peut signaler les exceptions non détectées comme fatales (à partir de la version 10.4.0 du SDK Unity). Les questions fréquentes suivantes vous aideront à comprendre la logique et les bonnes pratiques d'utilisation de cette fonctionnalité.

Pourquoi une application doit-elle signaler les exceptions non détectées comme fatales ?

En signalant les exceptions non détecté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 s'exécuter.

Notez que si vous commencez à signaler les erreurs fatales, le pourcentage d'utilisateurs sans plantage 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 :

Lors de l'initialisation dans votre application, la propriété ReportUncaughtExceptionsAsFatal doit être définie sur true.
Votre application (ou une bibliothèque incluse) génère une exception qui n'est pas interceptée. Une exception créée, mais non déclenché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 sur vos exceptions non interceptées en tant qu'erreurs fatales, voici quelques options pour gérer ces exceptions non interceptées :

Réfléchissez à la manière dont vous pouvez commencer à intercepter et à gérer ces exceptions non interceptées.
Envisagez différentes options pour consigner les exceptions dans la console de débogage Unity et dans Crashlytics.

Intercepter et gérer les exceptions générées

Les exceptions sont créées et générées pour refléter des états inattendus ou exceptionnels. Pour résoudre les problèmes reflétés par une exception générée, il faut ramener le programme à un état connu (processus appelé gestion des exceptions).

Il est recommandé d'intercepter et de gérer toutes les exceptions prévues, sauf si le programme ne peut pas revenir à un état connu.

Pour contrôler les types d'exceptions interceptées et gérées par quel code, encapsulez le code susceptible de générer une exception dans un bloc try-catch. Assurez-vous que les conditions des instructions catch sont aussi précises que possible pour gérer correctement les exceptions spécifiques.

Enregistrer les exceptions dans Unity ou Crashlytics

Il existe plusieurs façons d'enregistrer les 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 signaler à Crashlytics, pendant le développement ou le dépannage
- Affichez le contenu de l'exception dans la console Unity à l'aide de Debug.Log(exception), Debug.LogWarning(exception) et Debug.LogError(exception), qui n'affichent pas à nouveau l'exception.
Option 2 : Importez les données dans Crashlytics pour obtenir des rapports consolidés dans le tableau de bord Crashlytics dans 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 même si elle a été interceptée et géré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 génère également l'exception (qu'elle ait déjà été générée ou interceptée ou non). Il génère l'erreur de manière non locale. Cela signifie que même un Debug.LogException(exception) environnant avec des blocs try-catch génère 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 dans la console Unity.
Pour importer l'exception dans Crashlytics en tant qu'événement fatal.
Pour lever l'exception, faites en sorte qu'elle soit traitée comme une exception non détectée et qu'elle soit signalée à 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 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
    //
}