Auf dieser Seite finden Sie Hilfe bei der Fehlerbehebung und Antworten auf häufig gestellte Fragen zur Verwendung von Crashlytics. Wenn Sie nicht finden, wonach Sie suchen, oder weitere Hilfe benötigen, wenden Sie sich an den Firebase-Support.
Allgemeine Fehlerbehebung/FAQs
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. Bei einigen Problemen sehen Sie möglicherweise auch das Feature „Varianten“. Hier erfährst du, warum.
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 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 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 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 es keine Übereinstimmung gibt, wenden wir automatisch unseren intelligenteren 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,
erstellen Sie bitte einen Bericht.
Keine Navigationspfad-Logs
Wenn Sie keine Breadcrumb-Logs sehen, empfehlen wir, die Konfiguration Ihrer App auf Google Analytics zu prüfen.
Sie müssen die folgenden Anforderungen erfüllen:
Prüfen Sie insbesondere, ob Sie mindestens die folgende Version des Firebase SDK für Google Analytics verwenden: Android: v17.2.3+(BoM v24.7.1+).
Keine Geschwindigkeitswarnungen
Wenn Sie keine Geschwindigkeitswarnungen sehen, achten Sie darauf, dass Sie die folgenden Versionen verwenden:
Crashlytics SDK v18.6.0 oder höher (oder Firebase BoM v32.6.0 oder höher).
Messwerte ohne Abstürze werden nicht angezeigt oder sind unzuverlässig
Wenn Sie keine Messwerte zu Abstürzen (z. B. Nutzer ohne Abstürze und Sitzungen ohne Abstürze) sehen oder die Messwerte unzuverlässig sind, prüfen Sie Folgendes:
Achten Sie darauf, dass Sie das
Crashlytics SDK v18.6.0 oder höher (oder Firebase BoM v32.6.0 oder höher).
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 weniger zuverlässig sind und die Gesamtstabilität Ihrer App weniger genau widerspiegeln.
Wenn Sie die automatische Datenerhebung deaktiviert haben, können Sie mit sendUnsentReports zwischengespeicherte Berichte auf dem Gerät 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 absturzfreie Messwerte angezeigt.
Wie wird der Anteil der nicht von einem Absturz betroffenen Nutzer berechnet?
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 ANRs für 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:
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 ANRs 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 BuildIds nicht versehentlich entfernt haben, um die APK-Größe zu verringern.
Wenn Sie sowohl eine gestrippte als auch eine nicht gestrippte Version einer Bibliothek haben, 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. Das ist aufgrund des Unterschieds beim Erfassen und Melden von ANR-Daten zu erwarten. Crashlytics meldet ANRs beim nächsten Start der App, während Android Vitals ANR-Daten nach dem Auftreten des ANR sendet.
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 mit Google Play-Diensten angezeigt, bei denen die Einwilligung zur Datenerhebung erteilt wurde.
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 executablesymbolGeneratorType="breakpad"breakpadBinary=file("/PATH/TO/BREAKPAD/DUMP_SYMS")}}}}
niedrigere Plug-in-Versionen
android{// ...buildTypes{// ...release{// ...firebaseCrashlytics{// existing; required for either symbol file generatornativeSymbolUploadEnabledtrue// Add this optional new block to specify the path to the executablesymbolGenerator{breakpad{binaryfile("/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-Attributdatei manuell oder über die Befehlszeile aktualisieren. Wenn Sie beispielsweise den Pfad über die Befehlszeile angeben möchten, verwenden Sie einen Befehl wie den folgenden:
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:
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.
Wenn Sie Ihre DexGuard-Version nicht ändern möchten, fügen Sie den folgenden Code in Ihre Verschleierungsregeln (in Ihrer DexGuard-Konfigurationsdatei) ein:
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:
Nach dem Update auf die oben beschriebene Einrichtung werden möglicherweise neue .kt-Probleme angezeigt, die Duplikate vorhandener .java-Probleme sind. Weitere Informationen zu diesem Fall 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 Verschleierungstools 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.
Wer kann Anmerkungen zu einem Problem ansehen, verfassen und löschen?
Mit Notizen können Projektmitglieder bestimmte Probleme kommentieren, z. B. mit Fragen oder Statusaktualisierungen.
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.
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?
Nachdem Sie Crashlytics mit BigQuery verknüpft haben, werden neu erstellte Datasets automatisch in den USA gespeichert, unabhängig vom Standort Ihres Firebase-Projekts.
Plattformunterstützung
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.
Wieder aufgetretene Probleme
Was ist ein Problem, das sich verschlechtert hat?
Ein Problem ist zurückgegangen, wenn Sie es zuvor geschlossen haben, aber Crashlytics einen neuen Bericht erhält, dass das Problem 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:
Zum ersten Mal erhält Crashlytics einen Absturzbericht zu „Crash A“. Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem A).
Sie beheben diesen Fehler schnell, schließen Problem „A“ und veröffentlichen dann eine neue Version Ihrer App.
Crashlytics erhält einen weiteren Bericht zu Problem „A“, nachdem Sie das Problem geschlossen haben.
Wenn der Bericht von einer App-Version stammt, die Crashlyticsbekannt 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 Crashlyticsnicht kannte, als Sie das Problem geschlossen haben (d. h., die Version hat 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 mit Regressionen für ältere 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 weiterhin ältere Versionen ohne die Fehlerkorrektur verwenden. Wenn zufällig bei einer dieser älteren Versionen nie Absturzberichte gesendet wurden, als Sie das Problem geschlossen haben, und diese Nutzer auf den Fehler stoßen, 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.
