Diese Seite bietet Hilfe bei der Fehlerbehebung und Antworten auf häufig gestellte Fragen zur Verwendung von Crashlytics. Wenn Sie nicht finden, wonach Sie suchen, 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, 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 neben dem Firebase Crashlytics SDK sicher, dass Sie Ihrer App ( iOS+ | Android ) das Firebase SDK für Google Analytics hinzugefügt haben.
Stellen Sie sicher, dass Sie die neuesten Versionen für alle Ihre Firebase SDKs ( iOS+ | Android ) verwenden.
Stellen Sie insbesondere sicher, dass 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 verschiedene Formate für Probleme, die in Ihrer Problemtabelle in der Firebase-Konsole aufgeführt sind. Hier ist der Grund!
Crashlytics analysiert alle Ereignisse aus Ihrer App – Abstürze, nicht schwerwiegende und ANRs – und gruppiert ähnliche Ereignisse in separate Probleme. Im Januar 2023 haben wir eine verbesserte Analyse-Engine zum Gruppieren von Ereignissen basierend auf dem Code Ihrer App und ein aktualisiertes Design zum Anzeigen neuer Probleme eingeführt.
Hier ist, was Sie mit diesen Verbesserungen erleben werden:
Überarbeitete Metadaten, die in der Problemzeile angezeigt werden
Es ist jetzt einfacher, Probleme in Ihrer App zu verstehen und zu selektieren.Weniger doppelte Ausgaben
Eine Änderung der Zeilennummer führt nicht zu einem neuen Problem.Aussagekräftigere Warnungen und Signale
Ein neues Problem stellt eigentlich einen neuen Fehler dar.Leistungsfähigere Suche
Jede Ausgabe enthält mehr durchsuchbare Metadaten wie 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 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 absturzfreie Wert stellt den Prozentsatz der Benutzer dar, die mit Ihrer App interagiert haben, aber über einen bestimmten Zeitraum keinen Absturz hatten.
Hier ist die Formel zur Berechnung des Prozentsatzes der absturzfreien Benutzer. Seine 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 mit Ihrer App in dem Zeitraum interagiert haben, den Sie aus dem Dropdown-Menü oben rechts im Crashlytics-Dashboard ausgewählt haben.
Der Prozentsatz der absturzfreien Nutzer ist eine Aggregation im Laufe der Zeit , kein Durchschnitt.
Stellen Sie sich beispielsweise 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 interagiert haben und welche dieser Benutzer an diesem Tag abgestürzt sind:
| 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 beträgt der Prozentsatz Ihrer absturzfreien Benutzer 50 % (1 von 2 Benutzern war absturzfrei).
Zwei Ihrer Benutzer haben sich am Mittwoch mit Ihrer App beschäftigt, aber nur einer von ihnen (Benutzer B) hatte keine Abstürze.In den letzten 2 Tagen betrug der Prozentsatz Ihrer absturzfreien Benutzer 33,3 % (1 von 3 Benutzern war absturzfrei).
Drei Ihrer Benutzer haben sich in den letzten zwei Tagen mit Ihrer App beschäftigt, aber nur einer von ihnen (Benutzer C) hatte keine Abstürze.In den letzten 3 Tagen beträgt der Prozentsatz Ihrer absturzfreien Benutzer 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.
Notizen ermöglichen es Projektmitgliedern, bestimmte Probleme mit Fragen, Statusaktualisierungen usw. zu 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 und neue Notizen zu einem Problem schreiben.
- Projektinhaber oder -bearbeiter , Firebase-Administrator , Qualitätsadministrator oder Crashlytics-Administrator
Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem geposteten Notizen anzeigen, aber keine Notizen löschen oder schreiben.
- Project Viewer , Firebase Viewer , Quality Viewer oder Crashlytics Viewer
Integrationen
Wenn Ihr Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet, ist es wahrscheinlich, dass die Crash-Melder beim Registrieren 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, befinden sich neu erstellte Datasets automatisch in den USA, unabhängig vom Standort Ihres Firebase-Projekts.
Plattformunterstützung
Zurückgegangene Probleme
Ein Problem hat eine Regression erfahren, wenn Sie das Problem zuvor geschlossen haben, Crashlytics jedoch einen neuen Bericht erhält, dass das Problem erneut aufgetreten ist. Crashlytics öffnet diese rückgängig gemachten Probleme automatisch erneut, damit Sie sie entsprechend Ihrer App angehen können.
Hier ist ein Beispielszenario, das erklärt, wie Crashlytics ein Problem als Regression kategorisiert:
- Zum allerersten Mal erhält Crashlytics einen Absturzbericht über 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, von der Crashlytics wusste, als Sie das Problem geschlossen haben (was bedeutet, dass die Version einen Absturzbericht für jeden Absturz gesendet hat), dann betrachtet Crashlytics das Problem nicht als rückgängig gemacht. Das Thema 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ückgängig gemacht und öffnet das Problem erneut .
Wenn ein Problem zurückgeht, 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 Vorgang aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie den Vorgang „stumm“, anstatt ihn zu schließen.
Wenn ein Bericht von einer alten App-Version stammt, die überhaupt keine Absturzberichte gesendet hat, als Sie das Problem geschlossen haben, betrachtet Crashlytics das Problem als rückgängig gemacht 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, aber Sie haben immer noch Benutzer mit älteren Versionen ohne die Fehlerbehebung. Wenn eine dieser älteren Versionen zufällig überhaupt keine Absturzberichte gesendet hatte, als Sie das Problem geschlossen haben, und diese Benutzer anfangen, auf den Fehler zu stoßen, würden diese Absturzberichte ein zurückgegangenes Problem auslösen.
Wenn Sie nicht möchten, dass ein Vorgang aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie den Vorgang „stumm“, anstatt ihn zu schließen.