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
Wenn Sie keine absturzfreien Benutzer, Breadcrumb-Protokolle und/oder Geschwindigkeitswarnungen sehen, empfehlen wir Ihnen, die Konfiguration Ihrer App für Google Analytics zu überprüfen.
Stellen Sie sicher, dass Sie Google Analytics in Ihrem Firebase-Projekt aktiviert haben.
Stellen Sie sicher, dass die Datenfreigabe für Google Analytics auf der Seite „Integrationen“ > „Google Analytics“ der Firebase-Konsole aktiviert ist. Beachten Sie, dass die Datenfreigabeeinstellungen in der Firebase-Konsole angezeigt, aber in der Google Analytics-Konsole verwaltet werden.
Stellen Sie sicher, dass Sie zusätzlich zum Firebase Crashlytics SDK das Firebase SDK für Google Analytics zu Ihrer App hinzugefügt haben ( iOS+ | Android ).
Stellen Sie sicher, dass Sie die neuesten Versionen für alle Ihre Firebase SDKs ( iOS+ | Android ) verwenden.
Überprüfen Sie insbesondere, ob Sie mindestens die folgenden Versionen 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+) .
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, wie 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.
Der Wert „Absturzfrei“ stellt den Prozentsatz der Benutzer dar, die mit Ihrer App interagiert haben, aber über einen bestimmten Zeitraum hinweg keinen Absturz hatten.
Hier ist die Formel zur Berechnung des Prozentsatzes absturzfreier Benutzer. Die Eingabewerte werden von Google Analytics bereitgestellt.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Wenn ein Absturz auftritt, sendet Google Analytics einen Ereignistyp
app_exceptionund CRASHED_USERS stellt die Anzahl der Benutzer dar, die diesem Ereignistyp zugeordnet sind.ALL_USERS stellt die Gesamtzahl der Benutzer dar, die in dem Zeitraum, den Sie aus dem Dropdown-Menü oben rechts im Crashlytics-Dashboard ausgewählt haben, mit Ihrer App interagiert haben.
Der Prozentsatz absturzfreier Benutzer ist eine Aggregation im Zeitverlauf und kein Durchschnitt.
Stellen Sie sich zum Beispiel vor, Ihre App hat drei Benutzer; Wir nennen sie Benutzer A, Benutzer B und Benutzer C. Die folgende Tabelle zeigt, welche Benutzer jeden Tag mit Ihrer App interagierten und welcher dieser Benutzer an diesem Tag einen Absturz hatte:
| Montag | Dienstag | Mittwoch | |
|---|---|---|---|
| Benutzer, die mit Ihrer App interagiert haben | A, B, C | A, B, C | A, B |
| Benutzer, der einen Absturz hatte | C | B | A |
Am Mittwoch liegt Ihr Prozentsatz absturzfreier Benutzer bei 50 % (1 von 2 Benutzern war absturzfrei).
Zwei Ihrer Benutzer haben am Mittwoch mit Ihrer App interagiert, aber nur einer von ihnen (Benutzer B) hatte keine Abstürze.Für die letzten 2 Tage beträgt Ihr Prozentsatz absturzfreier Benutzer 33,3 % (1 von 3 Benutzern war absturzfrei).
Drei Ihrer Benutzer haben in den letzten zwei Tagen mit Ihrer App interagiert, aber nur einer von ihnen (Benutzer C) hatte keine Abstürze.In den letzten 3 Tagen lag der Prozentsatz Ihrer absturzfreien Benutzer bei 0 % (0 von 3 Benutzern waren absturzfrei).
Drei Ihrer Benutzer haben in den letzten drei Tagen mit Ihrer App interagiert, aber keiner von ihnen hatte keine Abstürze.
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.