Diese Seite bietet Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte Fragen zur Verwendung von Crashlytics. Wenn Sie das Gesuchte nicht finden oder zusätzliche Hilfe benötigen, wenden Sie sich an den Firebase-Support .
Allgemeine Fehlerbehebung/FAQ
Möglicherweise bemerken Sie zwei unterschiedliche Formate für Probleme, die in Ihrer Problemtabelle in der Firebase-Konsole aufgeführt sind. Und vielleicht fällt Ihnen in einigen Ihrer Ausgaben auch eine Funktion namens „Varianten“ auf. Hier ist der Grund!
Anfang 2023 haben wir eine verbesserte Analyse-Engine zum Gruppieren von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme (wie Varianten!) eingeführt. Schauen Sie sich unseren aktuellen Blog-Beitrag für alle Details an, aber Sie können unten die Highlights lesen.
Crashlytics analysiert alle Ereignisse Ihrer App (wie Abstürze, nicht tödliche Unfälle und ANRs) und erstellt Gruppen von Ereignissen, die als Probleme bezeichnet werden – alle Ereignisse in einem Problem haben eine gemeinsame Fehlerquelle.
Um Ereignisse in diese Probleme einzuteilen, untersucht die verbesserte Analyse-Engine nun viele Aspekte des Ereignisses, einschließlich der Frames im Stack-Trace, der Ausnahmemeldung, des Fehlercodes und anderer Plattform- oder Fehlertypmerkmale.
Innerhalb dieser Ereignisgruppe können die Stack-Traces, die zum Fehler führen, jedoch unterschiedlich sein. Ein anderer Stack-Trace könnte eine andere Grundursache bedeuten. 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 Fehlerpunkt und einen ähnlichen Stack-Trace aufweisen. Mit Varianten können Sie die häufigsten Stack-Traces innerhalb eines Problems debuggen und feststellen, ob verschiedene Grundursachen zum Fehler führen.
Folgendes werden Sie mit diesen Verbesserungen erleben:
Überarbeitete Metadaten werden in der Problemzeile angezeigt
Es ist jetzt einfacher, Probleme in Ihrer App zu verstehen und zu selektieren.Weniger doppelte Probleme
Eine Änderung der Zeilennummer führt nicht zu einem neuen Problem.Einfacheres Debuggen komplexer Probleme mit verschiedenen Grundursachen
Verwenden Sie Varianten, um die häufigsten Stack-Traces innerhalb eines Problems zu debuggen.Aussagekräftigere Warnungen und Signale
Ein neues Problem stellt tatsächlich einen neuen Fehler dar.Leistungsstärkere Suche
Jedes Problem enthält weitere durchsuchbare Metadaten, z. B. Ausnahmetyp und Paketname.
So werden diese Verbesserungen umgesetzt:
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 Ereignisgruppierungsalgorithmus auf das Ereignis an und erstellen ein neues Problem mit dem überarbeiteten Metadatendesign.
Dies ist das erste große Update, das wir an unserer Event-Gruppierung vornehmen. Wenn Sie Feedback haben oder auf Probleme stoßen, teilen Sie uns dies bitte mit, indem Sie einen Bericht einreichen.
Wenn Sie keine absturzfreien Metriken (z. B. absturzfreie Benutzer und Sitzungen) und/oder Geschwindigkeitswarnungen sehen, stellen Sie sicher, dass Sie dasCrashlytics SDK v18.6.0+ (oder Firebase BoM v32.6.0+).
Wenn Sie keine Breadcrumb-Protokolle sehen, empfehlen wir Ihnen, die Konfiguration Ihrer App für Google Analytics zu überprüfen. Stellen Sie sicher, dass Sie 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 finden Sie unter Verwalten Ihrer Analytics-Datenfreigabeeinstellungen
Sie habendas Firebase SDK für Google Analytics hinzugefügt,zu Ihrer App hinzugefügt. Dieses SDK muss zusätzlich zum Crashlytics SDK hinzugefügt werden.
Sie verwenden dieneuesten Firebase SDK- Versionen l10nfür alle Produkte, die Sie in Ihrer App verwenden.
Überprü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+) .
Crashlytics unterstützt ANR-Berichte für Android-Apps von Geräten, auf denen Android 11 und höher ausgeführt wird. Die zugrunde liegende API, die wir zum Sammeln von ANRs verwenden ( getHistoricalProcessExitReasons ), ist zuverlässiger als SIGQUIT oder Watchdog-basierte Ansätze. Diese API ist nur auf Geräten mit Android 11+ verfügbar.
Wenn bei einigen Ihrer ANRs die BuildId fehlen, führen Sie die Fehlerbehebung wie folgt durch:
Stellen Sie sicher, dass Sie eine aktuelle Version des Crashlytics Android SDK und des Crashlytics Gradle-Plugins verwenden.
Wenn Ihnen
BuildIdfür Android 11 und einige ANRs für Android 12 fehlen, verwenden Sie wahrscheinlich ein veraltetes SDK, Gradle-Plugin oder beides. UmBuildIdfür diese ANRs ordnungsgemäß zu erfassen, müssen Sie die folgenden Versionen verwenden:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Crashlytics Gradle-Plugin v2.9.4+
Überprüfen Sie, ob Sie einen nicht standardmäßigen Speicherort für Ihre gemeinsam genutzten Bibliotheken verwenden.
Wenn Ihnen nur
BuildIds für die gemeinsam genutzten Bibliotheken Ihrer App fehlen, verwenden Sie wahrscheinlich nicht den standardmäßigen Standardspeicherort für gemeinsam genutzte Bibliotheken. Wenn dies der Fall ist, kann Crashlytics die zugehörigenBuildIds möglicherweise nicht finden. Wir empfehlen Ihnen, die Verwendung des Standardspeicherorts für gemeinsam genutzte Bibliotheken in Betracht zu ziehen.Stellen Sie sicher, dass Sie
BuildIds während des Build-Prozesses nicht entfernen.Beachten Sie, dass die folgenden Tipps zur Fehlerbehebung sowohl für ANRs als auch für native Abstürze gelten.
Überprüfen Sie, ob die
BuildIds vorhanden sind, indem Siereadelf -nfür Ihre Binärdateien ausführen. Wenn dieBuildIds fehlen, fügen Sie-Wl,--build-idzu den Flags für Ihr Build-System hinzu.Stellen Sie sicher, dass Sie die
BuildIdnicht unbeabsichtigt entfernen, um Ihre APK-Größe zu reduzieren.Wenn Sie gestrippte und nicht gestrippte Versionen einer Bibliothek behalten, stellen Sie sicher, dass Sie in Ihrem Code auf die richtige Version verweisen.
Es kann eine Diskrepanz zwischen der Anzahl der ANRs zwischen Google Play und Crashlytics geben. 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 die ANR auftritt.
Darüber hinaus zeigt Crashlytics nur ANRs an, die auf Geräten mit Android 11+ auftreten, während Google Play ANRs von Geräten mit Google Play-Diensten und akzeptierter Einwilligung zur Datenerfassung anzeigt.
LLVM- und GNU-Toolchains haben unterschiedliche Standardeinstellungen und Behandlungen für das schreibgeschützte Segment der Binärdateien Ihrer App, was möglicherweise zu inkonsistenten Stack-Traces in der Firebase-Konsole führt. Um dies zu mildern, fügen Sie Ihrem Build-Prozess die folgenden Linker-Flags hinzu:
Wenn Sie den
lldLinker aus der LLVM-Toolchain verwenden, fügen Sie Folgendes hinzu:-Wl,--no-rosegmentWenn Sie den
ld.goldLinker aus der GNU-Toolchain verwenden, fügen Sie Folgendes hinzu:-Wl,--rosegment
Wenn immer noch Stack-Trace-Inkonsistenzen auftreten (oder wenn keines der Flags für Ihre Toolchain relevant ist), versuchen Sie stattdessen, Folgendes zu Ihrem Build-Prozess hinzuzufügen:
-fno-omit-frame-pointer
Das Crashlytics-Plugin bündelt einen angepassten Breakpad-Symboldateigenerator . Wenn Sie lieber Ihre eigene Binärdatei zum Generieren von Breakpad-Symboldateien verwenden möchten (wenn Sie beispielsweise lieber alle nativen ausführbaren Dateien in Ihrer Build-Kette aus dem Quellcode erstellen möchten), verwenden Sie die optionale Erweiterungseigenschaft 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
firebaseCrashlytics-Erweiterung in Ihrerbuild.gradleDatei anFügen Sie Ihrer
build.gradleDatei auf App-Ebene Folgendes hinzu: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 Eigenschaftszeile in Ihrer Gradle-Eigenschaftendatei an
Sie können die Eigenschaft
com.google.firebase.crashlytics.symbolGeneratorBinaryverwenden, um den Pfad zur ausführbaren Datei anzugeben.Sie können Ihre Gradle-Eigenschaftendatei manuell aktualisieren oder die Datei über die Befehlszeile aktualisieren. Um beispielsweise den Pfad über die Befehlszeile anzugeben, verwenden Sie einen Befehl wie den folgenden:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
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 jedoch das Senden von Absturzberichten. Um dies zu beheben:
Stellen Sie sicher, dass Sie die neueste Version von DexGuard 8.x 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, versuchen Sie, die folgende Zeile zu Ihren Verschleierungsregeln (in Ihrer DexGuard-Konfigurationsdatei) hinzuzufügen:
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Wenn eine App einen Obfuscator verwendet, der die Dateierweiterung nicht offenlegt, generiert Crashlytics jedes Problem standardmäßig mit der Dateierweiterung .java .
Damit Crashlytics Probleme mit der richtigen Dateierweiterung generieren kann, stellen Sie sicher, dass Ihre App das folgende Setup verwendet:
- Verwendet Android Gradle 4.2.0 oder höher
- Verwendet R8 mit aktivierter Verschleierung. Um Ihre App auf R8 zu aktualisieren, befolgen Sie diese Dokumentation .
Beachten Sie, dass nach der Aktualisierung auf das oben beschriebene Setup möglicherweise neue .kt Probleme auftreten, bei denen es sich um Duplikate bestehender .java Probleme handelt. Weitere Informationen zu diesem Umstand finden Sie in den FAQ .
Ab Mitte Dezember 2021 verbesserte Crashlytics die Unterstützung für Anwendungen, die Kotlin verwenden.
Bis vor kurzem machten die verfügbaren Verschleierer die Dateierweiterung nicht sichtbar, daher generierte Crashlytics jedes Problem standardmäßig mit der Dateierweiterung .java . Ab Android Gradle 4.2.0 unterstützt R8 jedoch Dateierweiterungen.
Mit diesem Update kann Crashlytics nun feststellen, ob jede in der App verwendete Klasse in Kotlin geschrieben ist, und den korrekten Dateinamen in die Problemsignatur aufnehmen. Abstürze werden jetzt korrekt .kt Dateien zugeordnet (sofern zutreffend), wenn Ihre App über das folgende Setup verfügt:
- Ihre App verwendet Android Gradle 4.2.0 oder höher.
- Ihre App verwendet R8 mit aktivierter Verschleierung.
Da neue Abstürze jetzt die korrekte Dateierweiterung in ihren Problemsignaturen enthalten, werden möglicherweise neue .kt Probleme angezeigt, bei denen es sich eigentlich nur um Duplikate vorhandener Probleme mit der Bezeichnung .java handelt. In der Firebase-Konsole versuchen wir, ein neues .kt Problem zu identifizieren und Ihnen mitzuteilen, ob es sich um ein mögliches Duplikat eines vorhandenen .java gekennzeichneten Problems handelt.
Mithilfe von Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.
Wenn ein Projektmitglied eine Notiz postet, wird diese 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 Anzeigen, Schreiben und Löschen von Notizen erforderlich ist:
Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen anzeigen und löschen sowie neue Notizen zu einem Problem schreiben.
- Projektinhaber oder -editor , Firebase-Administrator , Qualitätsadministrator oder Crashlytics-Administrator
Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem veröffentlichten Notizen anzeigen, aber sie können keine Notizen löschen oder schreiben.
- Projekt- Viewer , Firebase-Viewer , Qualitäts-Viewer oder Crashlytics-Viewer
Siehe Absturzfreie Metriken verstehen .
Mithilfe von Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.
Wenn ein Projektmitglied eine Notiz postet, wird diese 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 Anzeigen, Schreiben und Löschen von Notizen erforderlich ist:
Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen anzeigen und löschen sowie neue Notizen zu einem Problem schreiben.
- Projektinhaber oder -editor , Firebase-Administrator , Qualitätsadministrator oder Crashlytics-Administrator
Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem veröffentlichten Notizen anzeigen, aber sie können keine Notizen löschen oder schreiben.
- Projekt- Viewer , Firebase-Viewer , Qualitäts-Viewer oder Crashlytics-Viewer
Integrationen
Wenn Ihr Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet, ist es wahrscheinlich, dass die Crash-Reporter bei der Registrierung von Ausnahmehandlern stören. Um das Problem zu beheben, deaktivieren Sie die Absturzberichte im Mobile Ads SDK, indem Sie disableSDKCrashReporting aufrufen.
Nachdem Sie Crashlytics mit BigQuery verknüpft haben, werden neue Datensätze, die Sie erstellen, automatisch in den Vereinigten Staaten gespeichert, unabhängig vom Standort Ihres Firebase-Projekts.
Plattformunterstützung
Das Firebase Crashlytics NDK unterstützt ARMv5 (armeabi) nicht. Die Unterstützung für dieses ABI wurde ab NDK r17 entfernt.
Regressierte Probleme
Bei einem Problem ist ein Rückgang aufgetreten, wenn Sie das Problem zuvor geschlossen haben, Crashlytics jedoch einen neuen Bericht erhält, dass das Problem erneut aufgetreten ist. Crashlytics öffnet diese zurückgegangenen Probleme automatisch erneut, sodass Sie sie entsprechend Ihrer App beheben können.
Hier ist ein Beispielszenario, das erklärt, wie Crashlytics ein Problem als Regression kategorisiert:
- Zum ersten Mal überhaupt erhält Crashlytics einen Absturzbericht über Absturz „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, von der Crashlytics wusste, als Sie das Problem geschlossen haben (was bedeutet, dass die Version überhaupt einen Absturzbericht für einen Absturz gesendet hat), betrachtet Crashlytics das Problem nicht als rückläufig. Das Problem bleibt geschlossen.
- Wenn der Bericht von einer App-Version stammt, von der Crashlytics beim Schließen des Problems nichts wusste (was bedeutet, dass die Version überhaupt keinen Absturzbericht für einen Absturz gesendet hat), betrachtet Crashlytics das Problem als rückläufig und öffnet das Problem erneut .
Wenn sich ein Problem zurückbildet, senden wir eine Regressionserkennungswarnung und fügen dem Problem ein Regressionssignal hinzu, um Sie darüber zu informieren, dass Crashlytics das Problem erneut geöffnet hat. Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie das Problem „stumm“, anstatt es zu schließen.
Wenn ein Bericht von einer alten App-Version stammt, die zum Zeitpunkt des Schließens des Problems überhaupt keine Absturzberichte gesendet hat, geht Crashlytics davon aus, dass das Problem zurückgegangen ist, und öffnet das Problem erneut.
Diese Situation kann in der folgenden Situation auftreten: Sie haben einen Fehler behoben und eine neue Version Ihrer App veröffentlicht, haben aber immer noch Benutzer mit älteren Versionen ohne die Fehlerbehebung. Wenn eine dieser älteren Versionen zufällig überhaupt keine Absturzberichte gesendet hätte, als Sie das Problem geschlossen haben, und diese Benutzer auf den Fehler stoßen, würden diese Absturzberichte ein zurückgebildetes Problem auslösen.
Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie das Problem „stumm“, anstatt es zu schließen.