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 das
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 habenzu Ihrer App hinzugefügt. Dieses SDK muss zusätzlich zum Crashlytics SDK hinzugefügt werden.
Sie verwenden diefür alle Produkte, die Sie in Ihrer App verwenden.
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
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.