Fehlerbehebung und FAQs zu Crashlytics

In der Tabelle Probleme werden für einige Probleme unterschiedliche Formate (und manchmal auch „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“. Hier erfährst du, warum.

Anfang 2023 haben wir eine verbesserte Analyse-Engine zum Gruppieren 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 unten für Sie zusammengefasst.

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

Um Ereignisse in diese Probleme zu gruppieren, werden von der verbesserten Analyse-Engine jetzt viele Aspekte des Ereignisses berücksichtigt, darunter die Frames im Stacktrace, die Ausnahmemeldung, der Fehlercode und andere Merkmale der Plattform oder des Fehlertyps.

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 hindeuten. 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 eines Problems beheben und feststellen, ob der Fehler verschiedene Ursachen hat.

Das sind die Vorteile der Verbesserungen:

• Überarbeitete Metadaten in der Problemzeile
  Probleme in Ihrer App lassen sich jetzt leichter nachvollziehen 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 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 durchsuchbare Metadaten, z. B. Ausnahmetyp und Paketname.

So werden diese Verbesserungen eingeführt:

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

• Wenn keine Übereinstimmung gefunden wird, wenden wir automatisch unseren optimierten Algorithmus zur 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, melden Sie uns dies bitte .

Navigationspfad-Logs werden nicht angezeigt

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

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

• Sie haben die Datenfreigabe für Google Analytics aktiviert. Weitere Informationen zu dieser Einstellung

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

• Sie verwenden die aktuellen 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, ob Sie mindestens die folgende Version des Firebase SDK für Google Analytics verwenden: iOS+: v6.3.1+ (v8.9.0+ für macOS und tvOS) | Android: v17.2.3+ (BoM v24.7.1+).

Keine Geschwindigkeitswarnungen

Wenn Sie keine Geschwindigkeitswarnungen sehen, achten Sie darauf, dass Sie die folgenden SDK-Versionen verwenden:

Messwerte zu Sitzungen ohne Abstürze werden nicht angezeigt oder sind unzuverlässig

Wenn Sie keine Messwerte zu Abstürzen sehen (z. B. Nutzer ohne Abstürze und Sitzungen ohne Abstürze) oder die Messwerte unzuverlässig sind, prüfen Sie Folgendes:

• Achten Sie darauf, dass Sie das

• Prüfen Sie, ob die Einstellungen für die Datenerhebung die Qualität Ihrer Messwerte zu Nutzern ohne Abstürze 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. Daher wird die Genauigkeit der Messwerte ohne Abstürze beeinträchtigt, weil Crashlytics nur Absturzinformationen von diesen Nutzern mit Einwilligung (und nicht von allen Nutzern) enthält. Das bedeutet, dass Ihre Messwerte zu Nutzern ohne Abstürze möglicherweise weniger zuverlässig sind und die Gesamtstabilität Ihrer App weniger genau widerspiegeln.

  • Wenn die automatische Datenerhebung deaktiviert ist, können Sie mit sendUnsentReports Berichte, die auf dem Gerät zwischengespeichert wurden, an Crashlytics senden. Wenn Sie diese Methode verwenden, werden Absturzdaten an Crashlytics gesendet, aber keine Sitzungsdaten. Daher werden in den Konsolendiagrammen niedrige oder keine Werte für Messwerte ohne Abstürze angezeigt.

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

Weitere Informationen zu Messwerten ohne Abstürze

Wer kann Anmerkungen zu einem Problem ansehen, verfassen und löschen?

Mit Notizen können Projektmitglieder bestimmte Probleme kommentieren, z. B. mit Fragen oder Statusupdates.

Wenn ein Projektmitglied eine Anmerkung 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 Ansehen, Schreiben und Löschen von Notizen erforderlich ist:

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

  • Projektinhaber oder -bearbeiter, Firebase-Administrator, Quality-Administrator, oder Crashlytics-Administrator

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

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

Was ist ein Problem, das sich verschlechtert hat?

Ein Problem ist zurückgekehrt, wenn Sie es zuvor geschlossen haben, aber Crashlytics einen neuen Bericht erhält, dass es wieder aufgetreten ist. Crashlytics öffnet diese zurückgegangenen Probleme automatisch wieder, damit Sie sie für Ihre App beheben können.

Hier ist ein Beispiel dafür, wie Crashlytics ein Problem als Regression kategorisiert:

1. Crashlytics erhält zum ersten Mal einen Absturzbericht zu „Crash A“. Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem A).
2. Sie beheben diesen Fehler schnell, schließen Problem A und veröffentlichen dann eine neue Version Ihrer 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 hatte einen Absturzbericht für jeden Absturz gesendet), wird das Problem von Crashlytics nicht als Regression betrachtet. Das Problem bleibt geschlossen.
   • Wenn der Bericht von einer App-Version stammt, die Crashlytics nicht kannte, als Sie das Problem geschlossen haben (d. h., die Version hatte nie einen Absturzbericht für einen Absturz gesendet), betrachtet Crashlytics das Problem als Regression und öffnet es wieder.

Wenn ein Problem wieder 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, sollten Sie es stummschalten, anstatt es zu schließen.

Warum sehe ich Probleme in älteren App-Versionen?

Wenn ein Bericht von einer alten App-Version stammt, für die beim Schließen des Problems noch keine Absturzberichte gesendet wurden, betrachtet Crashlytics das Problem als Regression und öffnet es wieder.

Das kann passieren, wenn Sie einen Fehler behoben und eine neue Version Ihrer App veröffentlicht haben, aber Nutzer noch ältere Versionen ohne die Fehlerkorrektur verwenden. Wenn in einer dieser früheren Versionen nie Absturzberichte gesendet wurden, als Sie das Problem geschlossen haben, und diese Nutzer den Fehler jetzt feststellen, lösen diese Absturzberichte ein zurückgegangenes Problem aus.

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

dSYMs 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 Crashlytics-Ausführungsskript enthält. Dadurch kann Xcode die dSYMs Ihres Projekts während des Builds hochladen. 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 „dSYM fehlt“ angezeigt wird, prüfen Sie in Xcode, ob dSYMs für den Build richtig erstellt werden.

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

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

   • Laden Sie die fehlenden dSYM-Dateien manuell hoch:

     • Option 1:Verwenden Sie die konsolenbasierte Drag-and-drop-Option 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 weiterhin fehlschlagen, wenden Sie sich an den Firebase-Support und fügen Sie Ihre Logs bei.

Abstürze sind schlecht symbolisiert

Wenn Ihre Stacktraces schlecht symbolisiert zu sein scheinen, prüfen Sie Folgendes:

• Wenn Frames aus der Bibliothek Ihrer App keine Verweise auf den Code Ihrer App enthalten, prüfen Sie, ob -fomit-frame-pointer als Kompilierungsflag 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 „Fehlende dSYM-Warnung“ in den FAQs zu fehlenden/nicht hochgeladenen dSYMs auf dieser Seite. Durch das Hochladen dieser dSYMs werden keine Abstürze symbolisiert, die bereits aufgetreten sind. Es wird jedoch sichergestellt, dass künftige Abstürze symbolisiert werden.

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 einbinden, damit für Abstürze auf Messwerte zugegriffen werden kann, die von Google Analytics erfasst werden (nutzerfrei von Abstürzen, letzte Version, Geschwindigkeitswarnungen und Breadcrumb-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 separate Firebase-Projekte aufteilen, wenn sie dieselbe Bundle-ID enthielten.

Warum werden ANR-Fehler nur für Android 11+ 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 Ansätze, die auf SIGQUIT oder Watchdog basieren. Diese API ist nur auf Geräten mit Android 11 und höher verfügbar.

Warum fehlt bei einigen ANRs die BuildId?

Wenn bei einigen Ihrer ANRs die BuildId fehlen, gehen Sie so vor:

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

  Wenn Sie BuildId für Android 11 und einige ANR-Fehler unter Android 12 nicht sehen, verwenden Sie wahrscheinlich ein veraltetes SDK, ein veraltetes 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 v2.9.4 oder höher

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

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

• Achten Sie darauf, dass Sie während des Build-Prozesses keine BuildIds entfernen.

  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 BuildId fehlen, fügen Sie -Wl,--build-id den Flags für Ihr Build-System hinzu.

  • Prüfen Sie, ob Sie die BuildId nicht versehentlich entfernen, um die APK-Größe zu verringern.

  • Wenn Sie sowohl die gestrippte als auch die nicht gestrippte Version einer Bibliothek verwenden, müssen Sie in Ihrem 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 des Unterschieds beim Erfassen und Melden von ANR-Daten zu erwarten. Crashlytics meldet ANRs, wenn die App das nächste Mal gestartet wird. Android Vitals sendet ANR-Daten, 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. In Google Play werden ANR-Fehler von Geräten angezeigt, auf denen die Google Play-Dienste installiert sind und die Einwilligung zur Datenerhebung erteilt wurde.

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

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

Damit Crashlytics Probleme mit der richtigen Dateiendung generieren kann, muss Ihre App so eingerichtet sein:

• Android Gradle 4.2.0 oder höher wird verwendet.
• Verwendet R8 mit aktivierter Verschleierung. Hier finden Sie eine Anleitung zum Aktualisieren Ihrer App auf R8.

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

Warum sehe ich .kt-Probleme, die Duplikate von vorhandenen .java-Problemen 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 Obfuskierungsfunktionen nicht offengelegt. Daher wurde jedes Problem in Crashlytics standardmäßig mit der Dateiendung .java generiert. Ab Android Gradle 4.2.0 unterstützt R8 jedoch Dateiendungen.

Mit diesem Update kann Crashlytics jetzt ermitteln, 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 (falls zutreffend), wenn Ihre App die folgende Einrichtung hat:

• In Ihrer App wird Android Gradle 4.2.0 oder höher verwendet.
• 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 von vorhandenen Problemen mit dem Label .java sind. In der Firebase-Konsole versuchen wir, neue .kt-Probleme zu erkennen und Sie darüber zu informieren, wenn sie möglicherweise Duplikate eines vorhandenen Problems mit dem Label .java sind.

Keine Abstürze mit Dexguard

Wenn Sie die folgende Ausnahme sehen, 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 Absturzberichte gesendet werden. So lösen Sie das Problem:

1. Achten Sie darauf, dass Sie die aktuelle DexGuard 8.x-Version verwenden. Die neueste 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 den folgenden Code in Ihre Verschleierungsregeln (in Ihrer DexGuard-Konfigurationsdatei) ein:

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

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

Das aktuelle Release des Crashlytics-Gradle-Plug-ins ist eine Hauptversion (v3.0.0). Das SDK wurde modernisiert, indem die Unterstützung für niedrigere Versionen von Gradle und des Android-Gradle-Plug-ins eingestellt wurde. Außerdem werden mit den Änderungen in diesem Release Probleme mit AGP v8.1+ behoben und die Unterstützung für native Apps und benutzerdefinierte Builds verbessert.

Mindestanforderungen

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

• Android-Gradle-Plug-in 8.1+
  Aktualisieren Sie dieses Plug-in mit dem Android-Gradle-Plug-in-Upgrade-Assistenten in der neuesten Version von Android Studio.

• Firebase-Gradle-Plug-in google-services4.4.1+
  Aktualisieren Sie dieses Plug-in, indem Sie die aktuelle Version in der Gradle-Build-Datei Ihres Projekts angeben:

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

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

Änderungen an der Erweiterung „Crashlytics“

In Version 3 des Crashlytics-Gradle-Plug-ins gibt es die folgenden wichtigen Änderungen an der Crashlytics-Erweiterung:

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

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

• Das eingestellte Feld strippedNativeLibsDir wurde entfernt. Stattdessen sollten Sie unstrippedNativeLibsDir für alle nativen Bibliotheken verwenden.

• Das Feld unstrippedNativeLibsDir wurde in ein kumulatives Feld 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")
        }
      }
    }
  }

  Bei der Aufgabe uploadCrashlyticsSymbolFilesBasicRelease werden nur die Symbole in MY/NATIVE/LIBS hochgeladen, bei uploadCrashlyticsSymbolFilesFeatureXRelease werden Symbole in MY/NATIVE/LIBS und MY/FEATURE_X/LIBS hochgeladen.

• Das Feld „closure“ symbolGenerator wurde durch zwei neue Felder der obersten Ebene ersetzt:

  • symbolGeneratorType, ein String mit entweder "breakpad" (Standard) oder "csym".
  • breakpadBinary: Eine Datei mit einer lokalen dump_syms-Binärüberschreibung.

Beispiel für das Aktualisieren 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 in logcat

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

• Wenn Sie den lld-Linker 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 weiterhin Inkonsistenzen im Stacktrace auftreten oder keiner der beiden Flags für Ihre Toolchain relevant ist, fügen Sie stattdessen Folgendes in Ihren Build-Prozess ein:

-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 Ihr eigenes Binärprogramm zum Generieren von Breakpad-Symboldateien verwenden möchten (z. B. wenn Sie alle nativen ausführbaren Dateien in Ihrem Build-Prozess lieber aus dem Quellcode erstellen), können Sie mit der optionalen Erweiterungseigenschaft symbolGeneratorBinary den Pfad zur ausführbaren Datei angeben.

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

• Option 1: Pfad über die Erweiterung firebaseCrashlytics in der Datei build.gradle angeben

  Fügen Sie der Datei build.gradle.kts auf App-Ebene Folgendes hinzu:

  Gradle-Plug-in v3.0.0 oder höher

  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: Pfad über eine Eigenschaftszeile in der Datei „gradle.properties“ angeben

  Mit der Property 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 beispielsweise den Pfad über die Befehlszeile angeben möchten, verwenden Sie 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
  

Wird armeabi von Crashlytics unterstützt?

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

Unsichtbare Stacktraces für Android-Apps im Crashlytics-Dashboard

Wenn Sie IL2CPP von Unity verwenden und unsymbolisierte Stacktraces sehen, gehen Sie so vor:

1. Achten Sie darauf, dass Sie Version 8.6.1 oder höher des Crashlytics Unity SDK verwenden.

2. Achten Sie darauf, dass Sie die Firebase-Befehlszeile eingerichtet haben und den Befehl crashlytics:symbols:upload ausführen, um die 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

Kann Crashlytics mit Apps verwendet werden, die IL2CPP verwenden?

Ja, Crashlytics kann symbolisierte Stacktraces für Ihre Apps anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die auf Android- oder Apple-Plattformen veröffentlicht wurden. So gehts:

1. Achten Sie darauf, dass Sie Version 8.6.0 oder höher des Crashlytics Unity SDK verwenden.

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

   • Apps für Apple-Plattformen: Es sind keine besonderen Maßnahmen erforderlich. Bei Apps für Apple-Plattformen konfiguriert das Firebase Unity Editor-Plug-in Ihr Xcode-Projekt automatisch für das Hochladen von Symbolen.

   • Für Android-Apps: Achten Sie darauf, dass Sie die Firebase-Befehlszeile eingerichtet haben und den crashlytics:symbols:upload-Befehl ausführen, 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

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

Wenn Sie nicht abgefangene Ausnahmen als schwerwiegend melden, erhalten Sie einen realistischeren Hinweis darauf, welche Ausnahmen dazu führen können, dass das Spiel nicht mehr spielbar ist – auch wenn die App weiter ausgeführt wird.

Wenn Sie mit dem Melden von schwerwiegenden Fehlern beginnen, sinkt der Prozentsatz der Nutzer ohne Abstürze wahrscheinlich. Der Messwert „Nutzer ohne Abstürze“ ist dann aber repräsentativer für die Erfahrungen der Endnutzer mit Ihrer App.

Welche Ausnahmen werden als schwerwiegend gemeldet?

Damit Crashlytics eine nicht abgefangene Ausnahme als schwerwiegend meldet, müssen beide der folgenden Bedingungen erfüllt sein:

• Bei der Initialisierung in Ihrer App muss die ReportUncaughtExceptionsAsFatal-Property auf true festgelegt 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 das Melden nicht abgefangener Ausnahmen als schwerwiegende Fehler aktiviert habe, erhalte ich jetzt viele neue schwerwiegende Fehler. Wie gehe ich richtig mit diesen Ausnahmen um?

Wenn Sie Berichte zu Ihren nicht abgefangenen Ausnahmen als schwerwiegend erhalten, haben Sie folgende Möglichkeiten, diese nicht abgefangenen Ausnahmen zu behandeln:

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

Ausnahmen abfangen und behandeln

Ausnahmen werden erstellt und ausgelöst, um unerwartete oder außergewöhnliche Zustände zu kennzeichnen. 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 wird empfohlen, alle vorhersehbaren Ausnahmen abzufangen und zu behandeln, es sei denn, das Programm kann nicht in einen bekannten Zustand zurückgesetzt werden.

Um zu steuern, welche Arten von Ausnahmen von welchem Code abgefangen und verarbeitet werden, schließen Sie Code, der möglicherweise eine Ausnahme generiert, 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 die beiden folgenden Optionen am häufigsten und werden empfohlen:

• Option 1: In der Unity-Konsole ausgeben, aber während der Entwicklung oder Fehlerbehebung nicht an Crashlytics senden

  • Geben Sie mit Debug.Log(exception), Debug.LogWarning(exception) und Debug.LogError(exception) in die Unity-Konsole aus. Dabei wird der Inhalt der Ausnahme in die 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 soll, um ein mögliches nachfolgendes Crashlytics-Ereignis zu debuggen, verwenden Sie Crashlytics.Log(exception.ToString()).
  • Wenn eine Ausnahme trotz des Abfangens und der Verarbeitung weiterhin an Crashlytics gemeldet werden soll, verwenden Sie Crashlytics.LogException(exception), um sie als nicht schwerwiegendes Ereignis zu protokollieren.

Wenn Sie jedoch 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, sie wird aber auch ausgelöst, unabhängig davon, ob sie bereits ausgelöst oder abgefangen wurde. Der Fehler wird nicht lokal ausgegeben. Das bedeutet, dass auch ein umgebender Debug.LogException(exception)-Block mit try-catch-Blöcken zu einer nicht abgefangenen Ausnahme führt.

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

• Gibt die Ausnahme in der Unity-Konsole aus.
• Die Ausnahme wird als schwerwiegendes Ereignis in Crashlytics hochgeladen.
• Die Ausnahme wird ausgelöst, als nicht erfasste Ausnahme behandelt und an Unity Cloud Diagnostics gemeldet.

Wenn Sie eine abgefangene Ausnahme in der Unity-Konsole ausgeben und als nicht schwerwiegendes Ereignis in Crashlytics hochladen möchten, gehen Sie 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 treten aber keine Abstürze auf

Wenn in Ihrem Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet wird, stören sich die Absturzberichte wahrscheinlich beim Registrieren von Ausnahmebehandlern. Um das Problem zu beheben, deaktivieren Sie die Absturzberichterstattung 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-Sitzungsdataset (sofern der Export von Sitzungsdaten aktiviert ist).

• Dieser Speicherort gilt nur für die in BigQuery exportierten Daten und hat keinen Einfluss auf den Speicherort von Daten, die für die Verwendung im Crashlytics-Dashboard der Firebase-Konsole oder in Android Studio gespeichert werden.

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

Wie kann ich für BigQuery auf die neue Exportinfrastruktur umstellen?

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

• Wenn Sie den Batch-Export nach Oktober 2024 aktiviert haben, wird in Ihrem Firebase-Projekt automatisch die neue Exportinfrastruktur verwendet. Sie müssen nichts weiter tun.

• Wenn Sie den Batch-Export vor oder während Oktober 2024 aktiviert haben, lesen Sie die Informationen in diesen FAQs, um festzustellen, ob Sie Maßnahmen ergreifen müssen.

Alle Firebase-Projekte werden bereits am 9. Januar 2026 automatisch auf die neue Infrastruktur für den Batch-Export umgestellt. Sie können vor diesem Datum ein Upgrade durchführen. Achten Sie jedoch darauf, dass Ihre BigQuery-Batchtabellen die Voraussetzungen für ein Upgrade erfüllen.

Sie können ein Upgrade auf die neue Infrastruktur durchführen. Achten Sie jedoch darauf, dass Ihre BigQuery-Batchtabellen die Voraussetzungen für das Upgrade erfüllen.

Prüfen, ob Sie die neue Infrastruktur nutzen

Wenn Sie den Batch-Export Mitte Oktober 2024 oder später aktiviert haben, wird in Ihrem Firebase-Projekt automatisch die neue Exportinfrastruktur verwendet.

So können Sie prüfen, welche Infrastruktur für Ihr Projekt verwendet wird: Rufen Sie die Google Cloud-Konsole auf. Wenn Ihre Konfiguration für die Datenübertragung mit Firebase Crashlytics with Multi-Region Support gekennzeichnet ist, wird für Ihr Projekt die neue Exportinfrastruktur verwendet.

Wichtige Unterschiede zwischen der alten und der neuen Exportinfrastruktur

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

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

  • Export ab Mitte Oktober 2024 aktiviert: Bei der Einrichtung wurden Sie aufgefordert, einen Speicherort für den Datenexport auszuwählen.

• Die neue Infrastruktur unterstützt keine Backfills von Daten aus der Zeit vor der Aktivierung des Exports.

  • In der alten Infrastruktur war ein Backfill bis zu 30 Tage vor dem Datum möglich, an dem Sie den Export aktiviert haben.

  • Die neue Infrastruktur unterstützt Backfills bis zu den letzten 30 Tagen oder bis zum letzten Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was zuletzt war).

• Die neuen Infrastrukturnamen BigQuery Batch-Tabellen mit den Kennungen, die für Ihre Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

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

  • Bei der neuen Infrastruktur werden Daten in Batchtabellen mit Namen geschrieben, die auf den für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegten Paket-IDs oder Paketnamen basieren.

Schritt 1: Voraussetzungen für das Upgrade

1. Prüfen Sie, ob für Ihre vorhandenen BigQuery-Batchtabellen dieselben Kennungen wie für die Paket-IDs oder Paketnamen verwendet werden, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind. Wenn sie nicht übereinstimmen, kann es zu Unterbrechungen bei den exportierten Batchdaten kommen. Die meisten Projekte sind in einem geeigneten und kompatiblen Zustand. Es ist jedoch wichtig, dies vor dem Upgrade zu prüfen.

   • Alle in Ihrem Firebase-Projekt registrierten Firebase-Apps finden Sie in der Firebase Console: Rufen Sie die settings Projekteinstellungen auf und scrollen Sie dann zur Karte Ihre Apps, um alle Ihre Firebase-Apps und die zugehörigen Informationen zu sehen.

   • Alle Ihre BigQuery-Batchtabellen finden Sie in der BigQuery-Seite der Google Cloud-Konsole.

   Hier sind einige Beispiele für ideale Zustände, in denen beim Upgrade keine Probleme auftreten:

   • Sie haben eine Batchtabelle mit dem Namen com_yourcompany_yourproject_IOS und eine Firebase iOS+-App mit der Bundle-ID com.yourcompany.yourproject, die in Ihrem Firebase-Projekt registriert ist.

   • Sie haben eine Batchtabelle mit dem Namen com_yourcompany_yourproject_ANDROID und eine Firebase-Android-App mit dem Paketnamen com.yourcompany.yourproject, die in Ihrem Firebase-Projekt registriert ist.

2. Wenn Sie Batchtabellennamen haben, die nicht mit den für Ihre registrierten Firebase-Apps festgelegten Kennungen übereinstimmen, folgen Sie der Anleitung auf dieser Seite , bevor Sie ein manuelles Upgrade durchführen oder vor dem 9. Januar 2026, um Unterbrechungen beim Batchexport zu vermeiden.

Schritt 2: Manuelles Upgrade auf die neue Infrastruktur

Wenn Sie den Batch-Export vor Mitte Oktober 2024 aktiviert haben, können Sie manuell auf die neue Infrastruktur umstellen, indem Sie den Crashlytics-Datenexport in der Firebase-Konsole deaktivieren und dann wieder aktivieren.

So gehts:

1. Rufen Sie in der Firebase Console die Seite Integrationen auf.

2. Klicken Sie auf der Karte BigQuery auf Verwalten.

3. Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätige, dass du den Datenexport beenden möchtest.

4. Aktivieren Sie den Schieberegler Crashlytics sofort wieder, um den Export wieder zu aktivieren. Bestätige, dass du Daten exportieren möchtest.

   Ihr Crashlytics-Datenexport nach BigQuery erfolgt jetzt über die neue Exportinfrastruktur.

Der Name Ihrer vorhandenen Batchtabelle stimmt nicht mit der Kennung Ihrer Firebase-App überein