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:
Wenn Sie keine Geschwindigkeitswarnungen sehen, achten Sie darauf, dass Sie die folgenden Versionen verwenden:
Crashlytics SDK 11.7.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 11.7.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?
Unsichtbare Stacktraces für Android-Apps im Crashlytics-Dashboard
Wenn Sie IL2CPP von Unity verwenden und unsymbolisierte Stacktraces sehen, gehen Sie so vor:
Achten Sie darauf, dass Sie Version 8.6.1 oder höher des Crashlytics Unity SDK verwenden.
Achten Sie darauf, dass Sie die Firebase-Befehlszeile eingerichtet haben und den Befehl crashlytics:symbols:upload ausführen, um die Symboldatei zu generieren und hochzuladen.
Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen anderen Build erstellen, für den Sie symbolisierte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen
Kann Crashlytics mit Apps verwendet werden, die IL2CPP verwenden?
Ja, Crashlytics kann symbolisierte Stacktraces für Ihre Apps anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die auf Android- oder Apple-Plattformen veröffentlicht wurden. So gehts:
Sie müssen Version 8.6.0 oder höher des Crashlytics Unity SDK verwenden.
Führen Sie die erforderlichen Aufgaben für Ihre Plattform aus:
Apps für Apple-Plattformen: Es sind keine besonderen Maßnahmen erforderlich. Bei Apps für Apple-Plattformen konfiguriert das Firebase Unity Editor-Plug-in Ihr Xcode-Projekt automatisch für das Hochladen von Symbolen.
Für Android-Apps: Achten Sie darauf, dass Sie die Firebase-Befehlszeile eingerichtet haben und den crashlytics:symbols:upload-Befehl ausführen, um Ihre Symboldatei zu generieren und hochzuladen.
Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen anderen Build erstellen, für den Sie symbolisierte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen
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.
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.
Nicht erfasste Ausnahmen als schwerwiegend melden
Crashlytics kann nicht erfasste Ausnahmen als schwerwiegend melden (ab Version 10.4.0 des Unity-SDK). In den folgenden FAQs werden die Gründe für die Verwendung dieses Features und Best Practices erläutert.
Warum sollten nicht erfasste Ausnahmen in einer App als schwerwiegende Fehler gemeldet werden?
Wenn Sie nicht abgefangene Ausnahmen als schwerwiegend melden, erhalten Sie einen realistischeren Hinweis darauf, welche Ausnahmen dazu führen können, dass das Spiel nicht spielbar ist – auch wenn die App weiter ausgeführt wird.
Wenn Sie mit der Meldung von schwerwiegenden Fehlern beginnen, sinkt der Prozentsatz der Nutzer ohne Abstürze wahrscheinlich. Der Messwert „Nutzer ohne Abstürze“ ist dann aber repräsentativer für die Erfahrungen der Endnutzer mit Ihrer App.
Welche Ausnahmen werden als schwerwiegend gemeldet?
Damit Crashlytics eine nicht abgefangene Ausnahme als schwerwiegend meldet, müssen beide der folgenden Bedingungen erfüllt sein:
Ihre App (oder eine enthaltene Bibliothek) löst eine Ausnahme aus, die nicht abgefangen wird. Eine Ausnahme, die erstellt, aber nicht ausgelöst wird, gilt nicht als nicht abgefangen.
Nachdem ich das Melden nicht abgefangener Ausnahmen als schwerwiegende Fehler aktiviert habe, erhalte ich jetzt viele neue schwerwiegende Fehler. Wie gehe ich richtig mit diesen Ausnahmen um?
Wenn Sie Berichte zu Ihren nicht abgefangenen Ausnahmen als schwerwiegend erhalten, haben Sie folgende Möglichkeiten, diese nicht abgefangenen Ausnahmen zu behandeln:
Ausnahmen werden erstellt und ausgelöst, um unerwartete oder außergewöhnliche Zustände zu kennzeichnen.
Um die Probleme zu beheben, die durch eine ausgelöste Ausnahme widergespiegelt werden, muss das Programm in einen bekannten Zustand zurückversetzt werden. Dieser Vorgang wird als Ausnahmebehandlung bezeichnet.
Es wird empfohlen, alle vorhersehbaren Ausnahmen abzufangen und zu behandeln, es sei denn, das Programm kann nicht in einen bekannten Zustand zurückversetzt werden.
Ausnahmen in Unity oder Crashlytics protokollieren
Es gibt mehrere Möglichkeiten, Ausnahmen in Unity oder Crashlytics aufzuzeichnen, um das Problem zu beheben.
Wenn Sie Crashlytics verwenden, sind die folgenden beiden Optionen am häufigsten und werden empfohlen:
Option 1: In der Unity-Konsole ausgeben, aber während der Entwicklung oder Fehlerbehebung nicht an Crashlytics senden
Geben Sie mit Debug.Log(exception), Debug.LogWarning(exception) und Debug.LogError(exception) in der Unity-Konsole aus. Dadurch wird der Inhalt der Ausnahme in der Unity-Konsole ausgegeben und die Ausnahme wird nicht noch einmal ausgelöst.
Option 2: In den folgenden Fällen in Crashlytics hochladen, um konsolidierte Berichte im Crashlytics-Dashboard zu erhalten:
Wenn eine Ausnahme protokolliert werden soll, um ein mögliches nachfolgendes Crashlytics-Ereignis zu debuggen, verwenden Sie Crashlytics.Log(exception.ToString()).
Wenn eine Ausnahme trotz des Abfangens und der Verarbeitung weiterhin an Crashlytics gemeldet werden soll, verwenden Sie Crashlytics.LogException(exception), um sie als nicht schwerwiegendes Ereignis zu protokollieren.
Wenn Sie jedoch ein schwerwiegendes Ereignis manuell an Unity Cloud Diagnostics melden möchten, können Sie Debug.LogException verwenden. Bei dieser Option wird die Ausnahme wie bei Option 1 in der Unity-Konsole ausgegeben, sie wird aber auch ausgelöst (unabhängig davon, ob sie bereits ausgelöst oder abgefangen wurde). Der Fehler wird nicht lokal ausgegeben. Das bedeutet, dass auch ein umgebender Debug.LogException(exception)-Block mit try-catch-Blöcken zu einer nicht abgefangenen Ausnahme führt.
Rufen Sie Debug.LogException daher nur auf, wenn Sie alle der folgenden Aktionen ausführen möchten:
Gibt die Ausnahme in der Unity-Konsole aus.
Die Ausnahme wird als schwerwiegendes Ereignis in Crashlytics hochgeladen.
Wenn die Ausnahme ausgelöst werden soll, muss sie als nicht abgefangen behandelt und an Unity Cloud Diagnostics gemeldet werden.
Wenn Sie eine abgefangene Ausnahme in der Unity-Konsole ausgeben und als nicht schwerwiegendes Ereignis in Crashlytics hochladen möchten, gehen Sie so vor:
try{methodThatThrowsMyCustomExceptionType();}catch(MyCustomExceptionTypeexception){// Print the exception to the Unity console at the error level.Debug.LogError(exception);// Upload the exception to Crashlytics as a non-fatal event.Crashlytics.LogException(exception);// not Debug.LogException//// Code that handles the exception//}
