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

Dépannage de Crashlytics et questions fréquentes

Cette page fournit une aide pour le 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'une nouvelle interface 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 dans la trace de la pile, le message d'exception, le code d'erreur et d'autres caractéristiques de la plate-forme ou du 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 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 :

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 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.
Alertes et signaux plus pertinents
Un nouveau problème représente en réalité 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 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 .

Métriques sans plantage et/ou alertes de vitesse manquantes

Si vous ne voyez pas de métriques sans plantage (comme les utilisateurs et les sessions sans plantage) et/ou d'alertes de vitesse, assurez-vous d'utiliser le SDK Crashlytics 18.6.0 ou version ultérieure (ou Firebase BoM 32.6.0 ou version ultérieure).

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 activé Google Analytics 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 ajouté 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 Firebase pour tous les produits que vous utilisez dans votre application.

Vérifiez en particulier que vous utilisez au moins la version suivante du SDK Firebase pour Google Analytics:
Android : version 17.2.3 ou ultérieure (BoM v24.7.1 ou version ultérieure).

Pourquoi les erreurs ANR ne sont-elles signalées que pour Android 11 ou version ultérieure ?

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

Pourquoi les `BuildId` de certaines erreurs ANR sont-elles manquantes ?

Si les BuildId de certains de vos ANR sont manquantes, procédez comme suit :

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

Si des BuildId sont manquantes pour Android 11 et certains 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 erreurs ANR, vous devez utiliser les versions suivantes :
- Crashlytics SDK Android v18.3.5 ou version ultérieure (Firebase BoM v31.2.2 ou version ultérieure)
- Crashlytics Plug-in Gradle v2.9.4 ou version ultérieure
Vérifiez si vous utilisez un emplacement non standard pour vos bibliothèques partagées.

Si seuls des BuildId sont manquants pour les bibliothèques partagées de votre application, il est probable que vous n'utilisiez pas l'emplacement par défaut standard pour les bibliothèques partagées. Dans ce cas, Crashlytics ne pourra peut-être 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 éléments BuildId pendant le processus de compilation.

Notez que les conseils de dépannage suivants s'appliquent aux erreurs ANR et aux plantages natifs.
- Vérifiez si les BuildId existent en exécutant readelf -n sur vos binaires. Si les valeurs BuildId sont absentes, ajoutez -Wl,--build-id aux options de votre système de compilation.
- Vérifiez que vous ne supprimez pas les BuildId par inadvertance pour réduire la taille de votre APK.
- Si vous conservez des versions abrégées et complètes d'une bibliothèque, assurez-vous de pointer vers la version appropriée dans votre code.

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

Le nombre d'erreurs ANR peut être différent entre Google Play et Crashlytics. Cela est normal en raison de la différence entre les mécanismes de collecte et de création de rapports sur les données ANR. Crashlytics signale les erreurs ANR lors du prochain démarrage de l'application, tandis qu'Android Vitals envoie des données ANR après l'occurrence de l'erreur ANR.

De plus, Crashlytics n'affiche que les erreurs ANR qui se produisent sur des appareils équipés d'Android 11 ou version ultérieure, par rapport à Google Play, qui affiche les erreurs ANR des appareils sur lesquels les services Google Play et le consentement pour la collecte de données ont été acceptés.

Différences entre les traces de pile du 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 limiter ce problème, ajoutez les indicateurs d'association suivants à votre processus de compilation:

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

Si vous constatez toujours des incohérences dans la trace de la pile (ou si aucun indicateur n'est pertinent pour votre chaîne d'outils), essayez d'ajouter ce qui suit à votre processus de compilation :

-fno-omit-frame-pointer

Comment utiliser mon propre 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é. Si vous préférez utiliser votre propre binaire pour générer les 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 binaire du générateur de fichiers de symboles Breakpad de deux manières :

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

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

Plug-in Gradle 3.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 faire 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
```

Aucun plantage avec Dexguard

Si l'exception suivante s'affiche, il est probable que vous utilisiez une version de DexGuard incompatible avec le SDK Firebase Crashlytics :

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

Cette exception ne fait pas planter 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 de DexGuard 8.x. La dernière version contient des règles requises par le SDK Firebase Crashlytics.
Si vous ne souhaitez pas modifier la 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
```

Pourquoi des plantages de fichiers `.kt` marqués comme `.java` se produisent-ils ?

Lorsqu'une application utilise un outil d'obscurcissement 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 l'extension de fichier appropriée, 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 la documentation.

Notez qu'après avoir mis à jour la configuration décrite ci-dessus, vous pouvez commencer à voir de nouveaux problèmes .kt, qui sont des doublons de problèmes .java existants. Consultez les questions fréquentes pour en savoir plus à ce sujet.

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

À partir de la mi-décembre 2021, Crashlytics a amélioré la compatibilité avec les applications qui utilisent Kotlin.

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.

Avec 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 leurs signatures de problème, vous pouvez voir de nouveaux problèmes .kt qui ne sont en réalité que des doublons de problèmes existants libellés .java. Dans la console Firebase, nous essayons d'identifier et de vous informer si un nouveau problème .kt est un doublon d'un problème existant libellé .java.

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 d'un projet publie une note, elle est associée à l'adresse e-mail de son compte Google. Cette adresse e-mail et la note sont visibles par tous les membres du projet autorisés à consulter la note.

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 de la 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.
- Project Viewer, Lecteur Firebase, Lecteur de qualité ou Lecteur Crashlytics

Comment sont calculés les utilisateurs n'ayant pas subi de plantage ?

Consultez Comprendre les métriques d'utilisation sans plantage.

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.

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 de la qualité 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 ni les supprimer, ni en rédiger.
- Project Viewer, Lecteur Firebase, Lecteur de qualité ou Lecteur Crashlytics

Intégrations

L'appli utilise aussi le SDK Google Mobile Ads, mais ne génère pas de plantages

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 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

Crashlytics est-il compatible avec armeabi ?

Le NDK Firebase Crashlytics n'est pas compatible avec ARMv5 (armeabi). La prise en charge de cette ABI n'est plus assurée depuis le NDK r17.

Problèmes régressifs

Qu'est-ce qu'un problème de régression ?

Un problème a connu une régression lorsque vous l'avez fermé, mais Crashlytics reçoit un nouveau rapport indiquant que le problème 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 le plantage "A". Crashlytics ouvre un problème correspondant à ce plantage (problème "A").
Vous corrigez rapidement ce bug, 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 Crashlytics connaissait 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 de l'application que Crashlytics n'avait pas connaissance lorsque vous avez fermé le problème (autrement dit, que la version n'avait jamais envoyé aucun rapport d'erreur pour un plantage), 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 indiquer que Crashlytics l'a rouvert. 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 fermé le problème, Crashlytics considère que le problème a régressé et le rouvrira.

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.