Fehlerbehebung und häufig gestellte Fragen zu Crashlytics

In der Tabelle Probleme werden für einige Probleme unterschiedliche Formate (und manchmal „Varianten“) angezeigt.

In der Tabelle Probleme in der Firebase-Konsole werden Probleme möglicherweise in zwei verschiedenen Formaten aufgeführt. Möglicherweise sehen Sie bei einigen Problemen auch eine Funktion namens „Varianten“. Das hat folgende Gründe:

Anfang 2023 haben wir eine verbesserte Analyse-Engine für die Gruppierung von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme (z. B. Varianten) eingeführt. Alle Details finden Sie in unserem aktuellen Blogpost. Die wichtigsten Informationen haben wir hier für Sie zusammengefasst.

Crashlytics analysiert alle Ereignisse in Ihrer App (z. B. Abstürze, nicht schwerwiegende Fehler und ANRs) und erstellt Ereignisgruppen, die als Probleme bezeichnet werden. Alle Ereignisse in einem Problem haben einen gemeinsamen Point of Failure.

Um Ereignisse in diese Probleme zu gruppieren, berücksichtigt die verbesserte Analyse-Engine jetzt viele Aspekte des Ereignisses, einschließlich der Frames im Stacktrace, der Ausnahmemeldung, des Fehlercodes und anderer Plattform- oder Fehlertypmerkmale.

Innerhalb dieser Gruppe von Ereignissen können sich die Stacktraces, die zu dem Fehler führen, jedoch unterscheiden. Ein anderer Stacktrace kann auf eine andere Ursache hinweisen. Um diesen möglichen Unterschied innerhalb eines Problems darzustellen, erstellen wir jetzt Varianten innerhalb von Problemen. Jede Variante ist eine Untergruppe von Ereignissen in einem Problem, die denselben Point of Failure und einen ähnlichen Stacktrace haben. Mit Varianten können Sie Fehler in den häufigsten Stacktraces innerhalb eines Problems beheben und feststellen, ob verschiedene Ursachen zum Fehler führen.

Das sind die Vorteile dieser Verbesserungen:

• Überarbeitete Metadaten in der Problemzeile
  Probleme in Ihrer App lassen sich jetzt leichter verstehen und priorisieren.

• Weniger doppelte Probleme
  Eine Änderung der Zeilennummer führt nicht zu einem neuen Problem.

• Einfachere Fehlerbehebung bei komplexen Problemen mit verschiedenen Ursachen
  Mit Varianten können Sie Fehler in den häufigsten Stacktraces innerhalb eines Problems beheben.

• Aussagekräftigere Benachrichtigungen und Signale
  Ein neues Problem ist tatsächlich ein neuer Fehler.

• Leistungsstärkere Suche
  Jedes Problem enthält mehr suchbare Metadaten, z. B. Ausnahmetyp und Paketname.

Diese Verbesserungen werden folgendermaßen eingeführt:

• Wenn wir neue Ereignisse von deiner App erhalten, prüfen wir, ob sie mit einem vorhandenen Problem übereinstimmen.

• Wenn es keine Übereinstimmung gibt, wenden wir automatisch unseren intelligenteren Algorithmus für die Ereignisgruppierung auf das Ereignis an und erstellen ein neues Problem mit dem überarbeiteten Metadatendesign.

Dies ist das erste große Update, das wir an der Gruppierung von Ereignissen vornehmen. Wenn Sie Feedback haben oder Probleme auftreten, reichen Sie bitte einen Bericht ein .

Navigationspfad-Logs werden nicht angezeigt

Wenn Sie keine Navigationspfad-Logs sehen (iOS+ | Android | Flutter | Unity), sollten Sie die Konfiguration Ihrer App für Google Analytics prüfen. Sie müssen die folgenden Anforderungen erfüllen:

• Sie haben Google Analytics in Ihrem Firebase-Projekt aktiviert.

• Sie haben die Datenweitergabe für Google Analytics aktiviert. Weitere Informationen zu dieser Einstellung finden Sie unter Einstellungen für die Freigabe von Analytics-Daten verwalten.

• Sie haben das Firebase SDK für Google Analytics zu Ihrer App hinzugefügt: iOS+ | Android | Flutter | Unity.
  Dieses SDK muss zusätzlich zum Crashlytics SDK hinzugefügt werden.

• Sie verwenden die neuesten Firebase SDK-Versionen für alle Produkte, die Sie in Ihrer App verwenden (iOS+ | Android | Flutter | Unity).

  Prüfen Sie bei Apple-Plattformen und Android-Apps insbesondere, ob Sie mindestens die folgende Version des Firebase SDK für Google Analytics verwenden: iOS+ – Version 6.3.1 oder höher (Version 8.9.0 oder höher für macOS und tvOS) | Android – Version 17.2.3 oder höher (BoM Version 24.7.1 oder höher).

Keine Geschwindigkeitswarnungen

Wenn Sie keine Geschwindigkeitswarnungen sehen, prüfen Sie, ob Sie die folgenden Versionen verwenden:

Messwerte ohne Abstürze werden nicht angezeigt (oder sind unzuverlässig)

Wenn Sie keine Messwerte für absturzfreie Nutzer und Sitzungen oder unzuverlässige Messwerte sehen, prüfen Sie Folgendes:

• Achten Sie darauf, dass Sie die folgenden Versionen verwenden:

• Achten Sie darauf, dass die Einstellungen für die Datenerhebung die Qualität der Messwerte zu Nutzern ohne Abstürze nicht beeinträchtigen:

  • Wenn Sie die Berichterstellung mit Einwilligung aktivieren, indem Sie die automatische Absturzberichterstellung deaktivieren, können Absturzinformationen nur von Nutzern an Crashlytics gesendet werden, die der Datenerhebung ausdrücklich zugestimmt haben. Die Genauigkeit der Messwerte zu absturzfreien Sitzungen wird dadurch beeinträchtigt, da Crashlytics nur Absturzinformationen von diesen Nutzern hat, die ihre Einwilligung gegeben haben (und nicht von allen Nutzern). Das bedeutet, dass Ihre Messwerte zu Nutzern ohne Abstürze möglicherweise weniger zuverlässig sind und die Gesamtstabilität Ihrer App weniger gut widerspiegeln.

  • Wenn Sie die automatische Datenerhebung deaktiviert haben, können Sie mit sendUnsentReports auf dem Gerät im Cache gespeicherte Berichte an Crashlytics senden. Bei dieser Methode werden Absturzdaten an Crashlytics gesendet, aber keine Sitzungsdaten. Dadurch werden in den Console-Diagrammen niedrige oder Nullwerte für absturzfreie Messwerte angezeigt.

Wie wird der Anteil der nicht von einem Absturz betroffenen Nutzer berechnet?

Weitere Informationen finden Sie unter Messwerte ohne Abstürze.

Wer kann Notizen zu einem Problem ansehen, schreiben und löschen?

Mit Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.

Wenn ein Projektmitglied eine Notiz postet, wird sie mit der E‑Mail-Adresse seines Google-Kontos gekennzeichnet. Diese E-Mail-Adresse ist zusammen mit der Notiz für alle Projektmitglieder sichtbar, die Zugriff auf die Notiz haben.

Im Folgenden wird der Zugriff beschrieben, der zum Aufrufen, Schreiben und Löschen von Notizen erforderlich ist:

• Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen aufrufen und löschen sowie neue Notizen zu einem Problem schreiben.

  • Inhaber oder Bearbeiter des Projekts, Firebase-Administrator, Qualitätsadministrator oder Crashlytics-Administrator

• Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem geposteten Notizen aufrufen, aber keine Notiz löschen oder schreiben.

  • Projektbetrachter, Firebase-Betrachter, Qualitätsbetrachter oder Crashlytics-Betrachter

Was ist ein Problem mit Regression?

Eine Regression liegt vor, wenn Sie ein Problem zuvor geschlossen haben, Crashlytics aber einen neuen Bericht erhält, dass das Problem wieder aufgetreten ist. Crashlytics öffnet diese Probleme automatisch wieder, damit Sie sie entsprechend Ihrer App beheben können.

Hier ist ein Beispielszenario, in dem erklärt wird, wie Crashlytics ein Problem als Regression kategorisiert:

1. Crashlytics erhält zum ersten Mal einen Absturzbericht zu Absturz A. Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem „A“).
2. Du behebst diesen Fehler schnell, schließt Problem „A“ und veröffentlichst dann eine neue Version deiner App.
3. Crashlytics erhält einen weiteren Bericht zu Problem „A“, nachdem Sie das Problem geschlossen haben.
   • Wenn der Bericht von einer App-Version stammt, die Crashlytics bekannt war, als Sie das Problem geschlossen haben (d. h., die Version hat einen Absturzbericht für irgendeinen Absturz gesendet), betrachtet Crashlytics das Problem nicht als Regression. Das Problem bleibt geschlossen.
   • Wenn der Bericht von einer App-Version stammt, die Crashlytics nicht bekannt war, als Sie das Problem geschlossen haben (d. h., die Version hatte noch nie einen Absturzbericht für einen Absturz gesendet), betrachtet Crashlytics das Problem als wieder aufgetreten und öffnet es wieder.

Wenn ein Problem erneut auftritt, senden wir eine Benachrichtigung zur Regressionserkennung und fügen dem Problem ein Regressionssignal hinzu, um Sie darüber zu informieren, dass Crashlytics das Problem wieder geöffnet hat. Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus wieder geöffnet wird, „ignorieren“ Sie das Problem, anstatt es zu schließen.

Warum werden mir Probleme mit älteren App-Versionen angezeigt, die bereits behoben waren?

Wenn ein Bericht von einer alten App-Version stammt, die beim Schließen des Problems noch keine Absturzberichte gesendet hatte, wird das Problem von Crashlytics als wieder aufgetreten eingestuft und erneut geöffnet.

Das kann passieren, wenn Sie einen Fehler behoben und eine neue Version Ihrer App veröffentlicht haben, aber noch Nutzer mit früheren Versionen ohne die Fehlerkorrektur vorhanden sind. Wenn eine dieser früheren Versionen nie Absturzberichte gesendet hat, als Sie das Problem geschlossen haben, und diese Nutzer dann auf den Fehler stoßen, würden diese Absturzberichte ein Problem mit Regression auslösen.

Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus wieder geöffnet wird, „ignorieren“ Sie das Problem, anstatt es zu schließen.

dSYM-Dateien fehlen oder werden nicht hochgeladen

Wenn Sie die dSYMs Ihres Projekts hochladen und eine ausführliche Ausgabe erhalten möchten, prüfen Sie Folgendes:

1. Achten Sie darauf, dass die Build-Phase Ihres Projekts das Ausführungsskript Crashlytics enthält, damit Xcode die dSYMs Ihres Projekts während des Builds hochladen kann. Eine Anleitung zum Hinzufügen des Skripts finden Sie unter Crashlytics initialisieren. Nachdem Sie Ihr Projekt aktualisiert haben, erzwingen Sie einen Absturz und prüfen Sie, ob der Absturz im Crashlytics-Dashboard angezeigt wird.

2. Wenn in der Firebase-Konsole die Meldung „Missing dSYM“ (dSYM fehlt) angezeigt wird, prüfen Sie in Xcode, ob dSYMs für den Build ordnungsgemäß erstellt werden.

3. Wenn Xcode dSYM-Dateien korrekt erstellt und Sie trotzdem fehlende dSYM-Dateien sehen, bleibt das Run-Script-Tool wahrscheinlich beim Hochladen der dSYM-Dateien hängen. Versuchen Sie in diesem Fall Folgendes:

   • Achten Sie darauf, dass Sie die aktuelle Version von Crashlytics verwenden.

   • Laden Sie die fehlenden dSYM-Dateien manuell hoch:

     • Option 1:Verwenden Sie die konsolenbasierte Option „Drag-and-drop“ auf dem Tab dSYMs, um ein ZIP-Archiv mit den fehlenden dSYM-Dateien hochzuladen.
     • Option 2: Verwenden Sie das upload-symbols-Skript, um die fehlenden dSYM-Dateien für die angegebenen UUIDs auf dem Tab dSYMs hochzuladen.

4. Wenn weiterhin dSYMs fehlen oder Uploads fehlschlagen, wenden Sie sich an den Firebase-Support und fügen Sie Ihre Protokolle bei.

Abstürze werden schlecht symbolisch dargestellt

Wenn Ihre Stacktraces schlecht symbolisch dargestellt werden, prüfen Sie Folgendes:

• Wenn Frames aus der Bibliothek Ihrer App keine Verweise auf den Code Ihrer App enthalten, achten Sie darauf, dass -fomit-frame-pointer nicht als Kompilierungs-Flag festgelegt ist.

• Wenn Sie mehrere (Missing)-Frames für die Bibliothek Ihrer App sehen, prüfen Sie, ob auf dem Tab Crashlytics dSYMs der Firebase-Konsole optionale dSYMs als fehlend aufgeführt sind (für die betroffene App-Version). Wenn ja, folgen Sie dem Schritt zur Fehlerbehebung „Warnung zu fehlender dSYM-Datei“ in den FAQs zu fehlenden/nicht hochgeladenen dSYM-Dateien auf dieser Seite. Beachten Sie, dass durch das Hochladen dieser dSYMs Abstürze, die bereits aufgetreten sind, nicht symbolisiert werden. Dies hilft jedoch, die Symbolisierung für zukünftige Abstürze sicherzustellen.

Kann ich Crashlytics für macOS oder tvOS verwenden?

Ja, Sie können Crashlytics in macOS- und tvOS-Projekten implementieren. Achten Sie darauf, dass Sie Version 8.9.0 oder höher des Firebase SDK für Google Analytics verwenden, damit bei Abstürzen auf die von Google Analytics erfassten Messwerte zugegriffen werden kann (Nutzer ohne Abstürze, neuester Release, Geschwindigkeitswarnungen und Navigationspfad-Logs).

Kann ich Crashlytics in einem Firebase-Projekt mit mehreren Apps auf verschiedenen Apple-Plattformen verwenden?

Sie können jetzt Abstürze für mehrere Apps in einem einzigen Firebase-Projekt melden, auch wenn die Apps für verschiedene Apple-Plattformen (z. B. iOS, tvOS und Mac Catalyst) entwickelt wurden. Bisher mussten Sie die Apps in einzelne Firebase-Projekte aufteilen, wenn sie dieselbe Paket-ID hatten.

Warum werden ANR-Fehler nur für Android 11 und höher gemeldet?

Crashlytics unterstützt ANR-Berichte für Android-Apps von Geräten mit Android 11 und höher. Die zugrunde liegende API, die wir zum Erfassen von ANRs verwenden (getHistoricalProcessExitReasons), ist zuverlässiger als SIGQUIT- oder Watchdog-basierte Ansätze. Diese API ist nur auf Geräten mit Android 11 oder höher verfügbar.

Warum fehlen bei einigen ANRs die BuildIds?

Wenn bei einigen Ihrer ANRs die BuildIds fehlen, können Sie das Problem so beheben:

• Achten Sie darauf, dass Sie eine aktuelle Version des Crashlytics Android SDK und des Crashlytics Gradle-Plug-ins verwenden.

  Wenn BuildIds für Android 11 und einige ANRs für Android 12 fehlen, verwenden Sie wahrscheinlich ein veraltetes SDK, Gradle-Plug-in oder beides. Damit BuildIds für diese ANRs richtig erfasst werden, müssen Sie die folgenden Versionen verwenden:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle-Plug-in, Version 2.9.4 oder höher

• Prüfen Sie, ob Sie einen nicht standardmäßigen Speicherort für Ihre gemeinsam genutzten Bibliotheken verwenden.

  Wenn nurBuildIds für die gemeinsam genutzten Bibliotheken Ihrer App fehlen, verwenden Sie wahrscheinlich nicht den standardmäßigen Speicherort für gemeinsam genutzte Bibliotheken. In diesem Fall kann Crashlytics die zugehörigen BuildIds möglicherweise nicht finden. Wir empfehlen, den Standardspeicherort für gemeinsam genutzte Bibliotheken zu verwenden.

• Achten Sie darauf, dass BuildIds während des Build-Prozesses nicht entfernt werden.

  Die folgenden Tipps zur Fehlerbehebung gelten sowohl für ANR-Fehler als auch für native Abstürze.

  • Prüfen Sie, ob die BuildIds vorhanden sind, indem Sie readelf -n für Ihre Binärdateien ausführen. Wenn die BuildIds fehlen, fügen Sie den Flags für Ihr Build-System -Wl,--build-id hinzu.

  • Achte darauf, dass du die BuildIds nicht versehentlich entfernst, um die APK-Größe zu reduzieren.

  • Wenn du sowohl die bereinigte als auch die unbereinigte Version einer Bibliothek behältst, musst du in deinem Code auf die richtige Version verweisen.

Unterschiede zwischen ANR-Berichten im Crashlytics-Dashboard und in der Google Play Console

Die Anzahl der ANRs kann zwischen Google Play und Crashlytics abweichen. Dies ist aufgrund der unterschiedlichen Mechanismen zur Erfassung und Meldung von ANR-Daten zu erwarten. Crashlytics meldet ANRs beim nächsten Start der App, während Android Vitals ANR-Daten sendet, nachdem der ANR aufgetreten ist.

Außerdem werden in Crashlytics nur ANR-Fehler angezeigt, die auf Geräten mit Android 11 oder höher auftreten. Bei Google Play werden dagegen ANR-Fehler von Geräten mit Google Play-Diensten und akzeptierter Einwilligung zur Datenerhebung angezeigt.

Warum werden Abstürze aus .kt-Dateien als .java-Probleme gekennzeichnet?

Wenn eine App einen Obfuscator verwendet, der die Dateiendung nicht preisgibt, generiert Crashlytics jedes Problem standardmäßig mit der Dateiendung .java.

Damit Crashlytics Probleme mit der richtigen Dateiendung generieren kann, muss Ihre Anwendung die folgende Einrichtung verwenden:

• Android Gradle 4.2.0 oder höher wird verwendet.
• Verwendet R8 mit aktivierter Verschleierung. In dieser Dokumentation wird beschrieben, wie Sie Ihre App auf R8 aktualisieren.

Nach der Aktualisierung auf die oben beschriebene Einrichtung werden möglicherweise neue .kt-Probleme angezeigt, die Duplikate vorhandener .java-Probleme sind. Weitere Informationen zu diesem Umstand finden Sie in den FAQs.

Warum werden mir .kt-Probleme angezeigt, die Duplikate vorhandener .java-Probleme sind?

Seit Mitte Dezember 2021 bietet Crashlytics eine verbesserte Unterstützung für Anwendungen, die Kotlin verwenden.

Bis vor Kurzem wurde die Dateiendung von den verfügbaren Obfuskierungstools nicht offengelegt. Daher hat Crashlytics jede Ausgabe standardmäßig mit der Dateiendung .java generiert. Ab Android Gradle 4.2.0 unterstützt R8 jedoch Dateiendungen.

Mit diesem Update kann Crashlytics jetzt feststellen, ob jede in der App verwendete Klasse in Kotlin geschrieben ist, und den richtigen Dateinamen in die Problemsignatur aufnehmen. Abstürze werden jetzt korrekt .kt-Dateien zugeordnet (sofern zutreffend), wenn Ihre App die folgende Einrichtung hat:

• Ihre App verwendet Android Gradle 4.2.0 oder höher.
• In Ihrer App wird R8 mit aktivierter Verschleierung verwendet.

Da neue Abstürze jetzt die richtige Dateiendung in ihren Problemsignaturen enthalten, werden möglicherweise neue .kt-Probleme angezeigt, die eigentlich nur Duplikate vorhandener Probleme mit der Bezeichnung .java sind. In der Firebase-Konsole versuchen wir, zu erkennen und Ihnen mitzuteilen, ob ein neues .kt-Problem möglicherweise ein Duplikat eines vorhandenen, mit .java gekennzeichneten Problems ist.

Keine Abstürze mit Dexguard

Wenn die folgende Ausnahme auftritt, verwenden Sie wahrscheinlich eine Version von DexGuard, die nicht mit dem Firebase Crashlytics SDK kompatibel ist:

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

Diese Ausnahme führt nicht zum Absturz Ihrer App, verhindert aber, dass sie Absturzberichte sendet. So lösen Sie das Problem:

1. Achten Sie darauf, dass Sie die neueste DexGuard 8.x-Version verwenden. Die aktuelle Version enthält Regeln, die für das Firebase Crashlytics SDK erforderlich sind.

2. Wenn Sie Ihre DexGuard-Version nicht ändern möchten, fügen Sie Ihren Verschleierungsregeln (in Ihrer DexGuard-Konfigurationsdatei) die folgende Zeile hinzu:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Wie führe ich ein Upgrade auf das Crashlytics-Gradle-Plug-in, Version 3, durch?

Die neueste Version des Crashlytics-Gradle-Plug-ins ist eine Hauptversion (v3.0.0) und modernisiert das SDK, indem die Unterstützung für ältere Versionen von Gradle und dem Android-Gradle-Plug-in eingestellt wird. Außerdem werden mit den Änderungen in dieser Version Probleme mit AGPv8.1+ behoben und die Unterstützung für systemeigene Apps und benutzerdefinierte Builds verbessert.

Mindestanforderungen

Für das Crashlytics Gradle-Plug-in v3 gelten die folgenden Mindestanforderungen:

• Android-Gradle-Plug-in 8.1 oder höher
  Aktualisieren Sie dieses Plug-in mit dem Android-Gradle-Plug-in-Upgrade-Assistenten in der aktuellen Version von Android Studio.

• Firebase-Gradle-Plug-in google-services 4.4.1 oder höher
  Aktualisieren Sie dieses Plug-in, indem Sie die aktuelle Version in der Gradle-Build-Datei Ihres Projekts angeben, z. B. so:

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

Änderungen an der Erweiterung „Crashlytics“

In Version 3 des Crashlytics-Gradle-Plug-ins gibt es in der Crashlytics-Erweiterung die folgenden funktionsgefährdenden Änderungen:

• Die Erweiterung wurde aus dem Android-Block „defaultConfig“ entfernt. Stattdessen sollten Sie jede Variante konfigurieren.

• Das verworfene Feld mappingFile wurde entfernt. Stattdessen wird die zusammengeführte Zuordnungsdatei jetzt automatisch bereitgestellt.

• Das verworfene Feld strippedNativeLibsDir wurde entfernt. Verwende stattdessen unstrippedNativeLibsDir für alle nativen Bibliotheken.

• Das Feld unstrippedNativeLibsDir wurde in „kumulativ“ geändert.

  Beispiel mit mehreren Verzeichnissen ansehen

  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")
        }
      }
    }
  }

  Mit der Aufgabe uploadCrashlyticsSymbolFilesBasicRelease werden nur die Symbole in MY/NATIVE/LIBS hochgeladen, mit uploadCrashlyticsSymbolFilesFeatureXRelease werden jedoch Symbole in MY/NATIVE/LIBS und MY/FEATURE_X/LIBS hochgeladen.

• Das Feld symbolGenerator für die Schließung wurde durch zwei neue Felder auf oberster Ebene ersetzt:

  • symbolGeneratorType, ein String mit entweder "breakpad" (Standard) oder "csym".
  • breakpadBinary, eine Datei mit einem lokalen dump_syms-Binär-Override.

Beispiel für das Upgrade der Erweiterung

        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")
            }
          }
        }
      

Unterschiede zwischen NDK-Stacktraces im Crashlytics-Dashboard und Logcat

LLVM- und GNU-Toolchains haben unterschiedliche Standardeinstellungen und Behandlungen für das schreibgeschützte Segment der Binärdateien Ihrer App, was zu inkonsistenten Stacktraces in der Firebase-Konsole führen kann. Fügen Sie Ihrem Build-Prozess die folgenden Linker-Flags hinzu, um dieses Problem zu beheben:

• Wenn Sie den Linker lld aus der LLVM-Toolchain verwenden, fügen Sie Folgendes hinzu:

  -Wl,--no-rosegment

• Wenn Sie den ld.gold-Linker aus der GNU-Toolchain verwenden, fügen Sie Folgendes hinzu:

  -Wl,--rosegment

Wenn Sie weiterhin Inkonsistenzen im Stacktrace sehen (oder wenn keines der Flags für Ihre Toolchain relevant ist), fügen Sie stattdessen Folgendes zu Ihrem Build-Prozess hinzu:

-fno-omit-frame-pointer

Wie verwende ich meine eigene Binärdatei für den Breakpad-Symboldateigenerator für das NDK?

Das Crashlytics-Plug-in enthält einen angepassten Breakpad-Symboldateigenerator. Wenn Sie lieber Ihre eigene Binärdatei zum Generieren von Breakpad-Symboldateien verwenden möchten (z. B. wenn Sie alle nativen ausführbaren Dateien in Ihrer Build-Kette aus der Quelle erstellen möchten), verwenden Sie das optionale Erweiterungsattribut symbolGeneratorBinary, um den Pfad zur ausführbaren Datei anzugeben.

Sie können den Pfad zur Binärdatei des Breakpad-Symboldateigenerators auf zwei Arten angeben:

• Option 1: Geben Sie den Pfad über die Erweiterung firebaseCrashlytics in der Datei build.gradle an.

  Fügen Sie der Datei build.gradle.kts auf Anwendungsebene Folgendes hinzu:

  Gradle-Plug-in v3.0.0+

  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")
        }
      }
    }
  }

  niedrigere Plug-in-Versionen

  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: Geben Sie den Pfad über eine Attributzeile in Ihrer Gradle-Attributdatei an.

  Mit dem Attribut com.google.firebase.crashlytics.breakpadBinary können Sie den Pfad zur ausführbaren Datei angeben.

  Sie können die Gradle-Eigenschaftendatei manuell oder über die Befehlszeile aktualisieren. Wenn Sie den Pfad über die Befehlszeile angeben möchten, verwenden Sie beispielsweise einen Befehl wie den folgenden:

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

Unterstützt Crashlytics armeabi?

Das Firebase Crashlytics-NDK unterstützt ARMv5 (armeabi) nicht. Die Unterstützung für dieses ABI wurde mit NDK r17 entfernt.

Nicht symbolisierte Stacktraces für Android-Apps im Crashlytics-Dashboard sehen

Wenn Sie Unity IL2CPP verwenden und nicht symbolisierte Stacktraces angezeigt werden, versuchen Sie Folgendes:

1. Sie müssen Version 8.6.1 oder höher des Crashlytics Unity SDK verwenden.

2. Achten Sie darauf, dass Sie für die Ausführung des Firebase-Befehlszeilenbefehls crashlytics:symbols:upload eingerichtet sind, um Ihre Symboldatei zu generieren und hochzuladen.

   Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen anderen Build erstellen, für den Sie symbolisierte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen finden Sie unter Lesbare Absturzberichte erhalten.

Kann Crashlytics mit Apps verwendet werden, die IL2CPP verwenden?

Ja, Crashlytics kann symbolische Stacktraces für Ihre Apps anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die entweder auf Android- oder Apple-Plattformen veröffentlicht wurden. Gehen Sie dazu so vor:

1. Sie müssen Version 8.6.0 oder höher des Crashlytics Unity SDK verwenden.

2. Führen Sie die erforderlichen Schritte für Ihre Plattform aus:

   • Für Apple-Plattform-Apps: Es sind keine besonderen Maßnahmen erforderlich. Bei Apple-Plattform-Apps konfiguriert das Firebase Unity Editor-Plug-in Ihr Xcode-Projekt automatisch so, dass Symbole hochgeladen werden.

   • Für Android-Apps: Achten Sie darauf, dass Sie für die Ausführung des Firebase-Befehlszeilenbefehls crashlytics:symbols:upload eingerichtet sind, um Ihre Symboldatei zu generieren und hochzuladen.

     Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen anderen Build erstellen, für den Sie symbolisierte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen finden Sie unter Lesbare Absturzberichte erhalten.

Warum sollten nicht erfasste Ausnahmen in einer App als schwerwiegende Fehler gemeldet werden?

Wenn du nicht abgefangene Ausnahmen als schwerwiegende Fehler meldest, erhältst du einen realistischeren Hinweis darauf, welche Ausnahmen dazu führen können, dass das Spiel nicht mehr spielbar ist – auch wenn die App weiterhin ausgeführt wird.

Wenn Sie mit dem Melden schwerwiegender Fehler beginnen, sinkt wahrscheinlich der Prozentsatz der absturzfreien Nutzer (CFU). Der CFU-Messwert ist dann jedoch repräsentativer für die Erfahrungen der Endnutzer mit Ihrer App.

Welche Ausnahmen werden als schwerwiegend gemeldet?

Damit Crashlytics eine nicht erfasste Ausnahme als schwerwiegend meldet, müssen die beiden folgenden Bedingungen erfüllt sein:

• Während der Initialisierung in Ihrer App muss das Attribut ReportUncaughtExceptionsAsFatal auf true gesetzt werden.

• Ihre App (oder eine enthaltene Bibliothek) löst eine Ausnahme aus, die nicht abgefangen wird. Eine Ausnahme, die erstellt, aber nicht ausgelöst wird, gilt nicht als nicht abgefangen.

Nachdem ich die Meldung nicht erfasster Ausnahmen als schwerwiegende Fehler aktiviert habe, habe ich jetzt viele neue schwerwiegende Fehler. Wie gehe ich mit diesen Ausnahmen richtig um?

Wenn Sie Berichte zu nicht abgefangenen Ausnahmen als schwerwiegende Fehler erhalten, haben Sie folgende Möglichkeiten, diese nicht abgefangenen Ausnahmen zu verarbeiten:

• Überlegen Sie, wie Sie diese nicht abgefangenen Ausnahmen abfangen und verarbeiten können.
• Verschiedene Optionen zum Protokollieren von Ausnahmen in der Unity-Debugging-Konsole und in Crashlytics in Betracht ziehen.

Ausgelöste Ausnahmen abfangen und verarbeiten

Ausnahmen werden erstellt und ausgelöst, um unerwartete oder außergewöhnliche Zustände widerzuspiegeln. Um die Probleme zu beheben, die durch eine ausgelöste Ausnahme angezeigt werden, muss das Programm in einen bekannten Zustand zurückversetzt werden. Dieser Vorgang wird als Ausnahmebehandlung bezeichnet.

Es empfiehlt sich, alle vorhersehbaren Ausnahmen abzufangen und zu behandeln, es sei denn, das Programm kann nicht in einen bekannten Zustand zurückversetzt werden.

Wenn Sie steuern möchten, welche Arten von Ausnahmen von welchem Code abgefangen und verarbeitet werden, schließen Sie Code, der eine Ausnahme generieren könnte, in einen try-catch-Block ein. Achten Sie darauf, dass die Bedingungen in den catch-Anweisungen so eng wie möglich gefasst sind, damit die spezifischen Ausnahmen angemessen behandelt werden.

Ausnahmen in Unity oder Crashlytics protokollieren

Es gibt mehrere Möglichkeiten, Ausnahmen in Unity oder Crashlytics aufzuzeichnen, um das Problem zu beheben.

Wenn Sie Crashlytics verwenden, sind dies die beiden gängigsten und empfohlenen Optionen:

• Option 1: Während der Entwicklung oder Fehlerbehebung in der Unity-Konsole ausgeben, aber nicht an Crashlytics melden

  • Geben Sie die Ausnahme mit Debug.Log(exception), Debug.LogWarning(exception) und Debug.LogError(exception) in der Unity-Konsole aus. Dadurch wird der Inhalt der Ausnahme in der Unity-Konsole ausgegeben und die Ausnahme wird nicht noch einmal ausgelöst.

• Option 2: In den folgenden Situationen in Crashlytics hochladen, um konsolidierte Berichte im Crashlytics-Dashboard zu erhalten:

  • Wenn eine Ausnahme protokolliert werden sollte, um ein mögliches nachfolgendes Crashlytics-Ereignis zu debuggen, verwenden Sie Crashlytics.Log(exception.ToString()).
  • Wenn eine Ausnahme trotz Abfangen und Behandeln an Crashlytics gemeldet werden soll, verwenden Sie Crashlytics.LogException(exception), um sie als nicht schwerwiegendes Ereignis zu protokollieren.

Wenn Sie ein schwerwiegendes Ereignis manuell an Unity Cloud Diagnostics melden möchten, können Sie Debug.LogException verwenden. Bei dieser Option wird die Ausnahme wie bei Option 1 in der Unity-Konsole ausgegeben, aber es wird auch die Ausnahme ausgelöst (unabhängig davon, ob sie bereits ausgelöst oder abgefangen wurde). Der Fehler wird nicht lokal ausgegeben. Das bedeutet, dass selbst ein umgebender Debug.LogException(exception) mit try-catch-Blöcken zu einer nicht abgefangenen Ausnahme führt.

Rufen Sie Debug.LogException daher nur auf, wenn Sie alle der folgenden Schritte ausführen möchten:

• Um die Ausnahme in der Unity-Konsole auszugeben.
• Um die Ausnahme als schwerwiegendes Ereignis in Crashlytics hochzuladen.
• Wenn Sie die Ausnahme auslösen möchten, lassen Sie sie als nicht abgefangene Ausnahme behandeln und an Unity Cloud Diagnostics melden.

Wenn Sie eine abgefangene Ausnahme in der Unity-Konsole ausgeben und als nicht schwerwiegendes Ereignis in Crashlytics hochladen möchten, gehen Sie stattdessen so vor:

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

Die App verwendet auch das Google Mobile Ads-SDK, es kommt jedoch nicht zu Abstürzen

Wenn in Ihrem Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet wird, ist es wahrscheinlich, dass die Crash Reporter bei der Registrierung von Ausnahme-Handlern interferieren. Deaktivieren Sie zur Problembehebung die Absturzberichte im Mobile Ads SDK, indem Sie disableSDKCrashReporting aufrufen.

Wo befindet sich mein BigQuery-Dataset?

Firebase exportiert Daten an den Dataset-Speicherort, den Sie beim Einrichten des Datenexports nach BigQuery ausgewählt haben.

• Dieser Speicherort gilt sowohl für das Crashlytics-Dataset als auch für das Firebase-Sitzungs-Dataset (wenn der Export von Sitzungsdaten aktiviert ist).

• Dieser Standort gilt nur für die nach BigQuery exportierten Daten und hat keine Auswirkungen auf den Standort der Daten, die für die Verwendung im Dashboard Crashlytics der Firebase-Konsole oder in Android Studio gespeichert werden.

• Nachdem ein Dataset erstellt wurde, kann der Standort nicht mehr geändert werden. Sie können aber das Dataset an einen anderen Standort kopieren oder es manuell verschieben, d. h. an einem anderen Standort neu erstellen. Weitere Informationen finden Sie unter Speicherort für vorhandene Exporte ändern.

Probleme nach dem Upgrade auf die neue Exportinfrastruktur für BigQuery?

Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Batch-Export von Crashlytics-Daten nach BigQuery eingeführt.

Alle Firebase-Projekte wurden am 2. März 2026 automatisch auf die neue Infrastruktur für den Batchexport umgestellt.

Wichtige Unterschiede zwischen der alten und der neuen Exportinfrastruktur

• Die neue Infrastruktur unterstützt Crashlytics Dataset-Standorte außerhalb der USA.

  • Export vor Mitte Oktober 2024 aktiviert und auf die neue Exportinfrastruktur aktualisiert: Sie können jetzt optional den Speicherort für den Datenexport ändern.

  • Export Mitte Oktober 2024 oder später aktiviert: Sie wurden während der Einrichtung aufgefordert, einen Speicherort für den Datenexport auszuwählen.

• Die neue Infrastruktur unterstützt keine Backfills von Daten, die vor der Aktivierung des Exports erstellt wurden.

  • Die alte Infrastruktur unterstützte Backfills bis zu 30 Tage vor dem Datum, an dem Sie den Export aktiviert haben.

  • Die neue Infrastruktur unterstützt Backfills für die letzten 30 Tage oder für das letzte Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was aktueller ist).

• Die neue Infrastruktur benennt BigQuery-Batchtabellen mit den Kennungen, die für Ihre Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

  • In der alten Infrastruktur wurden Daten in Batchtabellen geschrieben, deren Namen auf den Paket-IDs oder Paketnamen in der Binärdatei Ihrer App basierten.

  • Die neue Infrastruktur schreibt Daten in Batchtabellen mit Namen, die auf den Paket-IDs oder Paketnamen basieren, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

Wenn der Name Ihrer alten Batchtabelle nicht mit der Kennung Ihrer Firebase-App übereinstimmt

Wenn der Name Ihrer alten Batchtabelle nicht mit der Paket-ID oder dem Paketnamen übereinstimmte, der für Ihre registrierte Firebase-App festgelegt ist, implementieren Sie eine der folgenden Optionen, um weitere Unterbrechungen Ihrer exportierten Batchdaten zu vermeiden.

Verstehen, wie die Exportinfrastruktur Kennungen verwendet, um Daten in BigQuery-Tabellen zu schreiben

So schreiben die beiden Exportinfrastrukturen Crashlytics-Daten in BigQuery-Batchtabellen:

• Alte Exportinfrastruktur: Daten wurden in eine Tabelle geschrieben, deren Name auf der Paket-ID oder dem Paketnamen in der Binärdatei Ihrer App basiert.

• Neue Exportinfrastruktur: Schreibt Daten in eine Tabelle mit einem Namen, der auf der Paket-ID oder dem Paketnamen basiert, der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt ist.

Leider stimmt die Paket-ID oder der Paketname in der Binärdatei Ihrer App manchmal nicht mit der Paket-ID oder dem Paketnamen überein, der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt ist. Das passiert in der Regel, wenn jemand bei der App-Registrierung nicht die tatsächliche Kennung eingegeben hat.

Was passiert, wenn das Problem vor dem Upgrade nicht behoben wurde?

Wenn die Kennungen an diesen beiden Stellen nicht übereinstimmen, ist Folgendes passiert:

• Ihre Crashlytics-Daten werden jetzt in eine neue BigQuery-Batchtabelle geschrieben. Das ist eine neue Tabelle mit einem Namen, der auf der Paket-ID oder dem Paketnamen basiert, der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt ist.

• In vorhandene „Legacy“-Tabellen mit einem Namen, der auf der Kennung in der Binärdatei Ihrer App basiert, werden keine Daten mehr geschrieben.

Beispielszenarien für nicht übereinstimmende Kennungen

Beachten Sie, dass an die Namen der BigQuery-Batchtabellen automatisch _IOS oder _ANDROID angehängt wird, um die Plattform der App anzugeben.

^{* Wenn die Kennung in der Binärdatei Ihrer App mit einer der für eine Firebase-App festgelegten Kennungen übereinstimmte, wurde von der neuen Exportinfrastruktur keine neue Tabelle für diese Kennung erstellt. Stattdessen werden weiterhin Daten für diese App dorthin geschrieben. Alle anderen Apps werden in neue Tabellen geschrieben.}

^{** Wenn eine der Kennungen in der Binärdatei Ihrer App mit der für die Firebase-App festgelegten Kennung übereinstimmt, wurde von der neuen Exportinfrastruktur keine neue Tabelle erstellt. Stattdessen wird diese Tabelle beibehalten und es werden Daten für alle Apps in diese Tabelle geschrieben.}

Optionen zur Minimierung von Unterbrechungen

• OPTION 1:
  Verwenden Sie die neue Tabelle, die von der neuen Exportinfrastruktur erstellt wurde. Sie kopieren Daten aus der Legacy-Tabelle in die neue Tabelle.

  1. Kopieren Sie in der Google Cloud-Konsole alle Daten aus der Legacy-Tabelle in die neue Tabelle, die während des Infrastrukturupgrades erstellt wurde.

  2. Wenn Sie nachgelagerte Abhängigkeiten haben, die von Ihrer Batchtabelle abhängen, ändern Sie sie so, dass die neue Tabelle verwendet wird.

• OPTION 2:
  Konfigurieren Sie die Einstellungen so, dass wieder in die Legacy-Tabelle geschrieben wird. Dazu müssen Sie einige Standardeinstellungen in einer BigQuery-Konfiguration überschreiben.

  1. Suchen Sie in der Firebase-Konsole nach der Firebase-App-ID (z. B. 1:1234567890:ios:321abc456def7890) der App mit dem nicht übereinstimmenden Batchtabellennamen und der Kennung und notieren Sie sie:
     Rufen Sie die settings Projekteinstellungen auf und rufen Sie dann die Karte Meine Apps auf, um alle Ihre Firebase-Apps und die zugehörigen Informationen zu sehen.

  2. Ändern Sie in der Google Cloud-Konsole die neue „Datenübertragungskonfiguration“, die durch das Infrastruktur-Upgrade erstellt wurde, sodass Daten in Ihre Legacy-Tabelle geschrieben werden:

     1. Rufen Sie BigQuery > Datenübertragungen auf, um Ihre „Datenübertragungskonfiguration“ aufzurufen.

     2. Wählen Sie die Konfiguration mit der Quelle Firebase Crashlytics with Multi-Region Support aus.

     3. Klicken Sie rechts oben auf Bearbeiten.

     4. Im Abschnitt Details zur Datenquelle finden Sie eine Liste für gmp_app_id und eine Liste für client_namespace.

        In BigQuery wird die Firebase-App-ID als gmp_app_id bezeichnet. Standardmäßig ist der client_namespace-Wert in BigQuery die entsprechende eindeutige Paket-ID / der entsprechende eindeutige Paketname der App. Sie überschreiben diese Standardkonfiguration jedoch.

        BigQuery verwendet den Wert client_namespace für den Namen der Batchtabelle, in die jede verknüpfte Firebase-App schreibt.

     5. Suchen Sie die gmp_app_id der Firebase-App, für die Sie die Standardeinstellungen überschreiben möchten. Ändern Sie den Wert client_namespace in den Namen der Tabelle, in die die Firebase-App stattdessen schreiben soll. In der Regel ist dies der Name der Legacy-Tabelle, in die die App mit der Legacy-Exportinfrastruktur geschrieben hat.

     6. Speichern Sie die Konfigurationsänderung.

  3. Planen Sie einen Backfill für die Tage, an denen in Ihrer Legacy-Tabelle Daten fehlen.

  4. Löschen Sie nach Abschluss des Backfills die neue Tabelle, die automatisch von der neuen Exportinfrastruktur erstellt wurde.