Dépannage et questions fréquentes concernant Crashlytics

Vous voyez 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 nouvelle interface 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 ou lisez les points clés ci-dessous.

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 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, au sein de ce groupe d'événements, les traces de la pile menant à la défaillance peuvent être différentes. Une trace de la pile différente peut indiquer une cause différente. Pour représenter cette différence possible 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 qui ont le même point de défaillance et une trace de la pile similaire. Avec les variantes, vous pouvez déboguer les traces de la pile les plus courantes d'un problème et déterminer si différentes causes fondamentales sont à l'origine de la défaillance.

Voici ce que vous constaterez grâce à 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 un nouveau problème.

• Débogage plus facile des problèmes complexes ayant différentes causes profondes
  Utilisez des variantes pour déboguer les traces de la pile les plus courantes d'un problème.

• Alertes et signaux plus pertinents
  Un nouveau problème représente un nouveau bug.

• Recherche plus efficace
  Chaque problème contient davantage de métadonnées incluses dans l'index de recherche, 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.

• Si aucune correspondance n'est trouvée, 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 à notre regroupement d'é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 .

Les journaux du fil d'Ariane ne s'affichent pas

Si vous ne voyez pas les journaux du 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. Pour en savoir plus sur ce paramètre, consultez 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 moins 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+).

Les alertes de vitesse ne s'affichent pas

Si vous ne voyez pas d'alertes de vitesse, assurez-vous d'utiliser la

Les métriques d'utilisation sans plantage ne s'affichent pas (ou les métriques affichées ne sont pas fiables)

Si vous ne voyez pas de métriques sans plantage (comme les utilisateurs et les sessions sans plantage) ou si vous voyez des métriques non fiables, vérifiez les points suivants :

• Assurez-vous d'utiliser la version suivante :

• 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 d'activation 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. La précision des métriques sans plantage sera donc affectée, car Crashlytics ne dispose que des informations de plantage de ces utilisateurs (plutôt que 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 la collecte automatique des données est désactivée, vous pouvez utiliser sendUnsentReports pour envoyer des rapports mis en cache sur l'appareil à Crashlytics. Cette méthode envoie les données de plantage à Crashlytics, mais pas les données de session. Par conséquent, les graphiques de la console affichent 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 avec des questions, des mises à jour d'é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 est visible, ainsi que la note, par tous les membres du projet autorisés à consulter la note.

Les sections suivantes décrivent 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 des notes existantes, et rédiger de nouvelles notes sur une demande.

  • Propriétaire ou Éditeur du projet, Administrateur Firebase, Administrateur de 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 ils ne peuvent pas en supprimer ni en rédiger.

  • Lecteur, Lecteur Firebase, Lecteur de qualité ou Lecteur Crashlytics du projet

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

Un problème a régressé lorsque vous l'avez déjà fermé, mais que Crashlytics reçoit un nouveau rapport indiquant qu'il s'est reproduit. Crashlytics rouvre automatiquement ces problèmes régressés 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 en tant que régression :

1. 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).
2. Vous corrigez rapidement ce bug, fermez le problème A, puis publiez une nouvelle version de votre application.
3. Crashlytics reçoit un autre rapport concernant le problème A après que vous l'avez fermé.
   • Si le rapport provient d'une version de l'application que Crashlytics connaissait lorsque vous avez fermé le problème (ce qui signifie que la version avait envoyé un rapport d'erreur pour n'importe quel plantage), Crashlytics ne considérera pas le problème comme une régression. Le problème restera fermé.
   • Si le rapport provient d'une version de l'application que Crashlytics ne connaissait pas lorsque vous avez fermé le problème (ce qui signifie que la version n'avait jamais envoyé aucun rapport de plantage pour un plantage), Crashlytics considère que le problème a régressé 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, "ignorez" le problème au lieu de le fermer.

Pourquoi des problèmes régressés s'affichent-ils pour les anciennes versions de l'application ?

Si un rapport provient d'une ancienne version de l'application qui n'avait jamais envoyé de rapport d'erreur lorsque vous avez fermé le problème, Crashlytics considère que le problème a régressé et le rouvre.

Cela peut se produire dans la situation suivante : vous avez corrigé un bug et publié une nouvelle version de votre application, mais certains utilisateurs utilisent encore des versions antérieures qui ne comportent pas la correction du bug. Si, par hasard, l'une de ces versions antérieures n'avait jamais envoyé de rapports d'erreur lorsque vous avez clôturé le problème, et que ces utilisateurs commencent à rencontrer le bug, ces rapports d'erreur déclenchent 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, "ignorez" le problème au lieu de le fermer.

Les fichiers dSYM sont manquants ou ne s'importent pas

Pour importer les dSYM de votre projet et obtenir un résultat détaillé, vérifiez les points suivants :

1. Assurez-vous que la phase de compilation de votre projet contient le script d'exécution Crashlytics, qui permet à Xcode d'importer les 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.

2. Si une alerte "dSYM manquant" s'affiche dans la console Firebase, vérifiez que Xcode génère correctement les dSYM pour le build.

3. Si Xcode produit correctement des fichiers dSYM, mais que vous voyez toujours des fichiers dSYM manquants, il est probable que l'outil d'exécution de script se bloque 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" de 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 dSYMs.

4. Si vous continuez à voir des dSYM manquants 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 la 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 plusieurs frames (Missing) s'affichent pour la bibliothèque de votre application, vérifiez si des dSYM facultatifs sont listés comme manquants (pour la version de l'application concernée) dans l'onglet Crashlytics dSYMs de la console Firebase. Si c'est le cas, suivez l'étape de dépannage "Alerte dSYM manquant" dans la section Questions fréquentes sur les dSYM manquants ou non importés de cette page. Notez que l'importation de ces dSYM ne symbolisera pas les plantages qui se sont déjà produits, mais qu'elle permettra d'assurer la symbolisation des futurs plantages.

Puis-je utiliser Crashlytics pour macOS ou tvOS ?

Oui, vous pouvez implémenter Crashlytics dans des 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 vitesse et journaux du fil d'Ariane).

Puis-je utiliser Crashlytics dans un projet Firebase avec 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 elles 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.

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

Crashlytics est compatible avec les rapports d'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 sur un watchdog. Cette API n'est disponible que sur les appareils Android 11 ou version ultérieure.

Pourquoi certains ANR n'ont-ils pas de BuildId ?

Si certains de vos ANR n'ont pas de BuildId, procédez comme suit :

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

  S'il vous manque des BuildId pour Android 11 et certaines erreurs ANR Android 12, vous utilisez probablement un SDK ou un plug-in Gradle obsolète, ou les deux. Pour collecter correctement les BuildId pour ces 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.

  S'il ne manque que les fichiers BuildId pour les bibliothèques partagées de votre application, il est probable que vous n'utilisiez pas l'emplacement standard par défaut pour les bibliothèques partagées. Dans ce cas, Crashlytics risque de ne pas pouvoir 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 lors du processus de compilation.

  Notez que les conseils de dépannage suivants s'appliquent à la fois aux erreurs 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 options de votre système de compilation.

  • Vérifiez que vous ne supprimez pas involontairement les BuildId pour réduire la taille de votre APK.

  • Si vous conservez des versions supprimées et non supprimées d'une bibliothèque, veillez à 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

Il peut y avoir une différence entre le nombre d'ANR dans Google Play et dans Crashlytics. Cela est normal, car les mécanismes de collecte et de reporting des données ANR sont différents. Crashlytics signale les erreurs ANR au prochain démarrage de l'application, tandis qu'Android Vitals envoie les données d'erreur ANR après qu'elles se sont produites.

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

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

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, suivez cette documentation.

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

Pourquoi des problèmes .kt sont-ils des doublons de problèmes .java existants ?

À partir de 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. Crashlytics générait donc 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 présente la configuration suivante :

• 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 l'extension de fichier appropriée dans leurs signatures de problème, vous pouvez voir de nouveaux problèmes .kt qui sont en fait des doublons de problèmes existants étiquetés .java. Dans la console Firebase, nous essayons d'identifier et de vous indiquer si un nouveau problème .kt est un doublon possible d'un problème existant étiqueté .java.

Aucun plantage avec Dexguard

Si l'exception suivante s'affiche, vous utilisez probablement 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 :

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

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

Comment passer à la version 3 du plug-in Gradle Crashlytics ?

La dernière version du plug-in Gradle Crashlytics est une version majeure (v3.0.0). Elle modernise le SDK en supprimant la compatibilité avec les versions antérieures de Gradle et du plug-in Android Gradle. De plus, les modifications apportées dans cette version résolvent les problèmes liés à AGP v8.1+ et améliorent la compatibilité avec les applications natives et les builds personnalisés.

Conditions minimales requises

La version 3 du plug-in Gradle Crashlytics présente les exigences minimales suivantes :

• Plug-in Android Gradle 8.1 ou version ultérieure
  Mettez à niveau ce plug-in à l'aide de l'assistant de mise à niveau du plug-in Android Gradle sur la dernière version d'Android Studio.

• google-servicesPlug-in Gradle 4.4.1 ou version ultérieure de Firebase
  Mettez à niveau ce plug-in en spécifiant la dernière version dans le fichier de compilation Gradle de votre projet, comme suit :

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.5.0" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' apply false
  ...
}

Modifications apportées à l'extension Crashlytics

Avec la version 3 du plug-in Gradle Crashlytics, l'extension Crashlytics présente les modifications destructives suivantes :

• Suppression de l'extension du bloc Android defaultConfig. Vous devez plutôt configurer chaque variante.

• Suppression du champ obsolète mappingFile. À la place, le fichier de mappage fusionné est désormais fourni automatiquement.

• Suppression du champ obsolète strippedNativeLibsDir. Utilisez plutôt unstrippedNativeLibsDir pour toutes les bibliothèques natives.

• Le champ unstrippedNativeLibsDir est désormais cumulatif.

  Afficher un exemple avec plusieurs répertoires

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  La tâche uploadCrashlyticsSymbolFilesBasicRelease n'importera que les symboles dans MY/NATIVE/LIBS, mais uploadCrashlyticsSymbolFilesFeatureXRelease importera les symboles dans MY/NATIVE/LIBS et MY/FEATURE_X/LIBS.

• Le champ de fermeture symbolGenerator a été remplacé par deux nouveaux champs de premier niveau :

  • symbolGeneratorType, une chaîne de "breakpad" (par défaut) ou "csym".
  • breakpadBinary, un fichier d'un remplacement binaire dump_syms local.

Exemple de mise à niveau de l'extension

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

Différences entre les traces de la 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 la pile incohérentes dans la console Firebase. Pour y remédier, ajoutez les options d'éditeur de liens suivantes à 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 la pile (ou si aucune option n'est pertinente 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 inclut un générateur de fichiers de symboles Breakpad personnalisé. 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.

______________________________________________________________________________________________________________________________________ _____________________________

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

  Ajoutez le code suivant au 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 infé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 semblable à celle-ci :

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Est-ce que Crashlytics est compatible avec armeabi ?

Le NDK Firebase Crashlytics n'est pas compatible avec ARMv5 (armeabi). La compatibilité avec cet ABI a été supprimée à partir de la version r17 du NDK.

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

Si vous utilisez Unity IL2CPP et que vous voyez des traces de la pile non symbolisées, essayez de procéder comme suit :

1. Assurez-vous d'utiliser la version 8.6.1 ou ultérieure du SDK Unity Crashlytics.

2. 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 tout build pour lequel vous souhaitez afficher des traces de la 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 la 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 :

1. Assurez-vous d'utiliser la version 8.6.0 ou ultérieure du SDK Unity Crashlytics.

2. 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 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 tout build pour lequel vous souhaitez afficher des traces de la pile symbolisées dans la console Firebase. Pour en savoir plus, consultez Obtenir des rapports d'erreur lisibles.

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

En signalant les exceptions non interceptées comme des erreurs 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, votre 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 :

• 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 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 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 (un 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 être renvoyé à un état connu.

Pour contrôler les types d'exceptions interceptés et gérés par un 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 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 vous aider à résoudre le problème.

Lorsque vous utilisez Crashlytics, voici les deux options les plus courantes et les plus recommandées :

• Option 1 : Imprimer dans la console Unity, mais ne pas envoyer de rapport à Crashlytics, pendant le développement ou le dépannage

  • Imprimez dans la console Unity à l'aide de Debug.Log(exception), Debug.LogWarning(exception) et Debug.LogError(exception), qui impriment le contenu de l'exception dans la console Unity et ne renvoient pas 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 est 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 été générée ou interceptée ou non). Elle 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 entraîne toujours une exception non interceptée.

Par conséquent, n'appelez Debug.LogException que 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 générer 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 interceptée dans la console Unity et l'importer dans Crashlytics en tant qu'événement non fatal, procédez 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
    //
}

L'application utilise également le SDK Google Mobile Ads, mais ne subit pas de plantages

Si votre projet utilise Crashlytics avec le SDK Google Mobile Ads, il est probable que les outils de rapport d'erreur 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 ?

Firebase exporte les données vers l'emplacement de l'ensemble de données que vous avez sélectionné lorsque vous avez configuré l'exportation des données vers BigQuery.

• Cet emplacement s'applique à la fois à l'ensemble de données Crashlytics et à l'ensemble de données des sessions Firebase (si l'exportation des données de sessions est activée).

• Cet emplacement ne s'applique qu'aux données exportées vers BigQuery. Il n'a aucune incidence sur l'emplacement des données stockées pour être utilisées dans le tableau de bord Crashlytics de la console Firebase ou dans Android Studio.

• Une fois l'ensemble de données créé, son emplacement ne peut plus être modifié, mais vous pouvez le copier dans un autre emplacement ou le déplacer (recréer) manuellement dans un autre emplacement. Pour en savoir plus, consultez Modifier l'emplacement des exportations existantes.

Vous rencontrez des problèmes après être passé à la nouvelle infrastructure d'exportation pour BigQuery ?

À la mi-octobre 2024, Crashlytics a lancé une nouvelle infrastructure pour l'exportation par lot des données Crashlytics vers BigQuery.

Tous les projets Firebase ont été automatiquement migrés vers la nouvelle infrastructure d'exportation par lot le 2 mars 2026.

Différences importantes entre l'ancienne et la nouvelle infrastructure d'exportation

• La nouvelle infrastructure est compatible avec les emplacements d'ensembles de données Crashlytics en dehors des États-Unis.

  • Exportation activée avant la mi-octobre 2024 et mise à niveau vers la nouvelle infrastructure d'exportation : vous pouvez désormais modifier l'emplacement d'exportation des données (facultatif).

  • Exportation activée mi-octobre 2024 ou plus tard : vous avez été invité à sélectionner un emplacement pour l'exportation des données lors de la configuration.

• La nouvelle infrastructure n'est pas compatible avec les remplissages de données antérieurs à l'activation de l'exportation.

  • L'ancienne infrastructure permettait de remplir les données jusqu'à 30 jours avant la date à laquelle vous aviez activé l'exportation.

  • La nouvelle infrastructure accepte les remplissages jusqu'aux 30 derniers jours ou pour la date la plus récente à laquelle vous avez activé l'exportation vers BigQuery (selon la date la plus récente).

• La nouvelle infrastructure nomme les tables de lot BigQuery à l'aide des identifiants définis pour vos applications Firebase dans votre projet Firebase.

  • L'ancienne infrastructure écrivait les données dans des tables de lot dont les noms étaient basés sur les ID du bundle ou les noms de package dans le binaire de votre application.

  • La nouvelle infrastructure écrit les données dans des tables par lot dont les noms sont basés sur les ID de bundle ou les noms de package définis pour vos applications Firebase enregistrées dans votre projet Firebase.

Si le nom de votre ancienne table par lot ne correspondait pas à l'identifiant de votre application Firebase

Si le nom de votre ancienne table par lot ne correspondait pas à l'ID du bundle ou au nom de package définis pour votre application Firebase enregistrée, implémentez l'une de ces options pour éviter d'autres interruptions de vos données par lot exportées.

Comprendre comment l'infrastructure d'exportation utilise des identifiants pour écrire des données dans des tables BigQuery

Voici comment les deux infrastructures d'exportation écrivent les données Crashlytics dans les tables de lot BigQuery :

• Ancienne infrastructure d'exportation : les données étaient écrites dans une table dont le nom était basé sur l'ID du bundle ou le nom du package dans le binaire de votre application.

• Nouvelle infrastructure d'exportation : écrit les données dans une table dont le nom est basé sur l'ID du bundle ou le nom de package définis pour votre application Firebase enregistrée dans votre projet Firebase.

Malheureusement, il arrive que l'ID de bundle ou le nom de package dans le binaire de votre application ne corresponde pas à l'ID de bundle ou au nom de package définis pour votre application Firebase enregistrée dans votre projet Firebase. Cela se produit généralement si quelqu'un n'a pas saisi l'identifiant réel lors de l'enregistrement de l'application.

Que se passe-t-il si ce problème n'a pas été résolu avant la mise à niveau ?

Si les identifiants de ces deux emplacements ne correspondent pas, cela signifie que :

• Vos données Crashlytics sont désormais écrites dans une nouvelle table par lot BigQuery, c'est-à-dire une nouvelle table dont le nom est basé sur l'ID du bundle ou le nom de package définis pour votre application Firebase enregistrée dans votre projet Firebase.

• Les données ne sont plus écrites dans les tables "anciennes" existantes dont le nom est basé sur l'identifiant dans le binaire de votre application.

Exemples de cas de figure d'identifiants non concordants

Notez que les noms des tables de lot BigQuery sont automatiquement suivis de _IOS ou _ANDROID pour indiquer la plate-forme de l'application.

^{* Si l'identifiant du binaire de votre application correspondait à l'un des identifiants définis pour une application Firebase, la nouvelle infrastructure d'exportation n'a pas créé de table pour cet identifiant. Au lieu de cela, il continuera d'y écrire des données pour cette application spécifique. Toutes les autres applications seront écrites dans de nouvelles tables.}

^{** Si l'un des identifiants du binaire de votre application correspondait à l'identifiant défini pour l'application Firebase, la nouvelle infrastructure d'exportation n'a pas créé de table. À la place, elle conservera cette table et commencera à y écrire les données de toutes les applications.}

Options pour limiter les perturbations

• OPTION 1 :
  Utilisez la table créée par la nouvelle infrastructure d'exportation. Vous allez copier les données de votre ancienne table vers la nouvelle.

  1. Dans la console Google Cloud, copiez toutes les données de votre ancienne table vers la nouvelle table créée lors de la mise à niveau de l'infrastructure.

  2. Si vous avez des dépendances en aval qui dépendent de votre table de traitement par lot, modifiez-les pour utiliser la nouvelle table.

• OPTION 2 :
  Reconfigurez l'écriture dans votre ancienne table. Pour ce faire, vous devez remplacer certaines valeurs par défaut dans une configuration BigQuery.

  1. Dans la console Firebase, recherchez et notez l'ID de l'application Firebase (par exemple, 1:1234567890:ios:321abc456def7890) de l'application dont le nom et l'identifiant de la table de lot ne correspondent pas :
     Accédez aux paramètres du projet de votre settings, puis à la fiche Vos applications pour afficher toutes vos applications Firebase et leurs informations.

  2. Dans la console Google Cloud, modifiez la nouvelle "configuration de transfert de données" créée par la mise à niveau de l'infrastructure afin que les données soient écrites dans votre ancienne table :

     1. Accédez à BigQuery > Transferts de données pour afficher votre configuration de transfert de données.

     2. Sélectionnez la configuration contenant la source Firebase Crashlytics with Multi-Region Support.

     3. Cliquez sur Modifier en haut à droite.

     4. Dans la section Détails de la source de données, recherchez une liste pour gmp_app_id et une liste pour client_namespace.

        Dans BigQuery, l'ID de l'application Firebase est appelé gmp_app_id. Par défaut, la valeur client_namespace dans BigQuery correspond à l'ID du bundle / nom de package unique de l'application, mais vous allez remplacer cette configuration par défaut.

        BigQuery utilise la valeur client_namespace pour le nom de la table de lot dans laquelle chaque application Firebase associée écrit.

     5. Recherchez le gmp_app_id de l'application Firebase pour laquelle vous souhaitez remplacer les paramètres par défaut. Remplacez sa valeur client_namespace par le nom de la table dans laquelle vous souhaitez que l'application Firebase écrive (il s'agit généralement du nom de l'ancienne table dans laquelle l'application écrivait avec l'ancienne infrastructure d'exportation).

     6. Enregistrez la modification de la configuration.

  3. Planifiez un backfill pour les jours où il manque des données dans votre ancienne table.

  4. Une fois le backfill terminé, supprimez la nouvelle table créée automatiquement par la nouvelle infrastructure d'exportation.