Fehlerbehebung und FAQs zu Crashlytics

iOS+ Android Flutter Unity

Auf dieser Seite finden Sie Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte Fragen zur Verwendung von Crashlytics. Wenn Sie darin nicht finden oder zusätzliche Hilfe benötigen, wenden Sie sich an den Firebase-Support.

Allgemeine Fehlerbehebung/FAQs

Für einige Probleme in der Tabelle Probleme werden unterschiedliche Formate (und manchmal „Varianten“) angezeigt.

Möglicherweise sehen Sie zwei verschiedene Formate für Probleme, die in der Tabelle Probleme in der Firebase-Konsole aufgeführt sind. Möglicherweise sehen Sie bei einigen Problemen auch eine Funktion namens „Varianten“. Hier ist der Grund dafür:

Anfang 2023 haben wir ein verbessertes Analysemodul zum Gruppieren von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme (z. B. Varianten!) eingeführt. Alle Details findest du in unserem aktuellen Blogpost. Im Folgenden findest du die wichtigsten Informationen.

Crashlytics analysiert alle Ereignisse in Ihrer App (z. B. Abstürze, nicht fatale Fehler und ANRs) und erstellt Ereignisgruppen, die als Probleme bezeichnet werden. Alle Ereignisse in einem Problem haben einen gemeinsamen Point of Failure.

Um Ereignisse nach diesen Problemen zu gruppieren, prüft die verbesserte Analyse-Engine jetzt viele Aspekte des Ereignisses, einschließlich der Frames im Stacktrace, der Ausnahmemeldung, des Fehlercodes und anderer Plattform- oder Fehlertypeigenschaften.

Innerhalb dieser Gruppe von Ereignissen können sich die Stacktraces, die zum Fehler führen, jedoch unterscheiden. Ein anderer Stacktrace kann eine andere Ursache bedeuten. Um diesen möglichen Unterschied innerhalb eines Problems darzustellen, erstellen wir jetzt Varianten innerhalb von Problemen. Jede Variante ist eine Teilgruppe 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 beheben und feststellen, ob ein Problem verschiedene Ursachen hat.

Diese Verbesserungen bringen folgende Vorteile:

• Überarbeitete Metadaten in der Problemzeile
  Probleme in deiner App sind jetzt einfacher zu verstehen und zu erkennen.

• 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 die häufigsten Stacktraces in einem Problem beheben.

• Aussagekräftigere Warnungen und Signale
  Ein neues Problem deutet eigentlich auf einen neuen Fehler hin.

• Leistungsstärkere Suche
  Jedes Problem enthält mehr durchsuchbare Metadaten wie den Ausnahmetyp und den Paketnamen.

So werden diese Verbesserungen eingeführt:

• Wenn wir neue Ereignisse von Ihrer App erhalten, prüfen wir, ob sie zu einem vorhandenen Problem passen.

• Wenn keine Übereinstimmung gefunden wird, 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 Ereignisgruppierung vornehmen. Wenn du Feedback hast oder Probleme auftreten, kannst du dich jederzeit an uns wenden. Hier kannst du eine Meldung senden.

Messwerte für Sitzungen ohne Abstürze und/oder Geschwindigkeitswarnungen werden nicht angezeigt

Wenn Sie keine fehlerfreien Messwerte (z. B. fehlerfreie Nutzer und Sitzungen) und/oder Geschwindigkeitswarnungen sehen, verwenden Sie das Crashlytics SDK 11.7.0 oder höher.

Navigationspfad-Logs werden nicht angezeigt

Wenn Sie keine Navigationspfade sehen, sollten Sie die Konfiguration Ihrer Anwendung auf Google Analytics prüfen. Sie müssen die folgenden Anforderungen erfüllen:

• Sie haben in Ihrem Firebase-Projekt Google Analytics aktiviert.

• Sie haben die Datenfreigabe für Google Analytics aktiviert. Weitere Informationen zu dieser Einstellung

• Sie haben Ihrer App das Firebase SDK für Google Analytics hinzugefügt. Dieses SDK muss zusätzlich zum Crashlytics SDK hinzugefügt werden.

• Sie verwenden die aktuellen Firebase SDK-Versionen für alle Produkte, die Sie in Ihrer App verwenden.

Nicht symbolisch dargestellte Stacktraces für Android-Apps im Crashlytics-Dashboard werden angezeigt

Wenn Sie Unity IL2CPP verwenden und nicht symbolisierte Stack-Traces sehen, versuchen Sie Folgendes:

1. Sie benötigen Version 8.6.1 oder höher des Crashlytics Unity SDK.

2. Prüfen Sie, ob der Befehl crashlytics:symbols:upload der Firebase-Befehlszeile zum Generieren und Hochladen Ihrer Symboldatei eingerichtet ist und ausgeführt wird.

   Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen Build erstellen, für den Sie symbolisch dargestellte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen finden Sie auf der Seite Lesbare Absturzberichte abrufen.

Kann Crashlytics mit Apps verwendet werden, die IL2CPP verwenden?

Ja, Crashlytics kann symbolisch dargestellte Stacktraces für Ihre Anwendungen anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die auf Android- oder Apple-Plattformen veröffentlicht werden. Gehen Sie dazu so vor:

1. Sie müssen Version 8.6.0 oder höher des Crashlytics Unity SDK verwenden.

2. Führen Sie die erforderlichen Aufgaben für Ihre Plattform aus:

   • Apps für die Apple-Plattform: 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 den Upload von Symbolen.

   • Android-Apps: Sie müssen den Befehl Firebase CLI crashlytics:symbols:upload eingerichtet und ausgeführt haben, um die Symboldatei zu generieren und hochzuladen.

     Sie müssen diesen Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen Build erstellen, für den Sie symbolische Stack-Traces in der Firebase-Konsole sehen möchten. Weitere Informationen finden Sie auf der Seite Lesbare Absturzberichte abrufen.

Wie werden Nutzer ohne Abstürze berechnet?

Der Wert „Ohne Abstürze“ gibt den Prozentsatz der Nutzer an, die in einem bestimmten Zeitraum mit Ihrer App interagiert haben, aber keine Abstürze aufgetreten sind.

Hier ist die Formel zur Berechnung des Prozentsatzes der Nutzer ohne Abstürze. Die Eingabewerte werden von Google Analytics bereitgestellt.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• Bei einem Absturz sendet Google Analytics den Ereignistyp app_exception und CRASHED_USERS steht für die Anzahl der Nutzer, die diesem Ereignistyp zugeordnet sind.

• ALL_USERS entspricht der Gesamtzahl der Nutzer, die im ausgewählten Zeitraum mit Ihrer App interagiert haben. Den Zeitraum können Sie oben rechts im Dashboard für Crashlytics im Drop-down-Menü auswählen.

Hinweis: Wenn Sie den Prozentsatz der Nutzer Ihrer App berechnen möchten, die keine Abstürze erlebt haben, finden Sie die Anzahl der app_exception-Ereignisse für Ihre App im Dashboard Analytics. Aufgrund kleiner Unterschiede bei der Verarbeitung von Abstürzen kann sich der im Dashboard Analytics angezeigte Wert für app_exception manchmal vom Wert unterscheiden, den wir für die Berechnung des Prozentsatzes der fehlerfreien Nutzer verwenden.

Der Prozentsatz der Nutzer ohne Abstürze ist eine Aggregation im Zeitverlauf, kein Durchschnittswert.

Angenommen, Ihre App hat drei Nutzer, die wir Nutzer A, Nutzer B und Nutzer C nennen. In der folgenden Tabelle sehen Sie, welche Nutzer täglich mit Ihrer App interagiert haben und bei welchen dieser Nutzer es an diesem Tag zu einem Absturz gekommen ist:

	Montag	Dienstag	Mittwoch
Nutzer, die mit Ihrer App interagiert haben	A, B, C	A, B, C	A, B
Nutzer, bei dem ein Absturz aufgetreten ist	C	B	A

• Am Mittwoch beträgt der Prozentsatz der Nutzer ohne Abstürze 50 % (1 von 2 Nutzern).
  Zwei deiner Nutzer haben am Mittwoch mit deiner App interagiert, aber nur bei einem von Nutzer B gab es keine Abstürze.

• In den letzten zwei Tagen lag der Prozentsatz der Nutzer ohne Abstürze bei 33,3 % (1 von 3 Nutzern).
  Drei Ihrer Nutzer haben in den letzten zwei Tagen mit Ihrer App interagiert, aber nur bei einem von Nutzern (Nutzer C) gab es keine Abstürze.

• In den letzten drei Tagen lag der Prozentsatz der Nutzer ohne Abstürze bei 0 % (0 von 3 Nutzern hatten keine Abstürze).
  Drei Ihrer Nutzer haben in den letzten drei Tagen mit Ihrer App interagiert, bei keinem davon gab es jedoch keine Abstürze.

Der Wert für die Anzahl der Nutzer ohne Abstürze sollte nicht über verschiedene Zeiträume hinweg verglichen werden. Die Wahrscheinlichkeit, dass ein einzelner Nutzer einen Absturz erleidet, steigt mit der Häufigkeit, mit der er Ihre App verwendet. Daher ist der Wert für die Anzahl der Nutzer ohne Abstürze für längere Zeiträume wahrscheinlich geringer.

Hinweis: Wenn Sie den Ereignistyp nur auf nicht kritische Probleme filtern, wird die Karte Statistiken zu Abstürzen vermeiden leer angezeigt. Der Prozentsatz der nicht von einem Absturz betroffenen Nutzer wird nur für fatale Ereignisse berechnet.

Wer kann Notizen zu einem Problem ansehen, schreiben und löschen?

Notizen ermöglichen es Projektmitgliedern, bestimmte Probleme mit Fragen, Statusaktualisierungen usw. zu kommentieren.

Wenn ein Projektmitglied eine Notiz 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 zum Ansehen der Notiz berechtigt sind.

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 erstellen.

  • Projektinhaber oder -bearbeiter, Firebase-Administrator, Qualitätsadministrator oder Crashlytics-Administrator

• Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem geposteten Notizen ansehen, aber keine Hinweise löschen oder schreiben.

  • Projektbetrachter, Firebase-Betrachter, Qualitätsbetrachter oder Crashlytics-Betrachter

Wie werden Nutzer ohne Abstürze berechnet?

Weitere Informationen finden Sie unter Messwerte ohne Abstürze.

Wer kann Notizen zu einem Problem ansehen, schreiben und löschen?

Notizen ermöglichen es Projektmitgliedern, bestimmte Probleme mit Fragen, Statusaktualisierungen usw. zu kommentieren.

Wenn ein Projektmitglied eine Notiz 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 zum Ansehen der Notiz berechtigt sind.

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.

  • Projektinhaber oder -bearbeiter, Firebase-Administrator, Quality-Administrator oder Crashlytics-Administrator

• Projektmitglieder mit einer der folgenden Rollen können die zu einem Problem geposteten Notizen ansehen, aber keine Hinweise löschen oder schreiben.

  • Project Viewer, Firebase-Betrachter, Quality-Betrachter oder Crashlytics-Betrachter

Integrationen

Die App verwendet auch das Google Mobile Ads-SDK, aber es kommt nicht zu Abstürzen.

Wenn in Ihrem Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet wird, stören die Absturzmelder wahrscheinlich die Registrierung von Ausnahmebehandlungen. Deaktiviere zum Beheben des Problems die Absturzberichte im Mobile Ads SDK, indem du disableSDKCrashReporting aufrufst.

Wo befindet sich mein BigQuery-Dataset?

Nachdem Sie Crashlytics mit BigQuery verknüpft haben, werden neue Datasets, die Sie erstellen, unabhängig vom Standort Ihres Firebase-Projekts automatisch in den USA gespeichert.

Wieder auftretende Probleme

Was ist ein regressiertes Problem?

Ein Problem ist wieder aufgetreten, nachdem du es zuvor geschlossen hast. Crashlytics erhält jedoch eine neue Meldung, dass das Problem wieder aufgetreten ist. Crashlytics öffnet diese wiederkehrenden Probleme automatisch wieder, damit Sie sie entsprechend Ihrer App beheben können.

Im folgenden Beispielszenario wird erläutert, wie Crashlytics ein Problem als Regression kategorisiert:

1. Zum ersten Mal erhält Crashlytics einen Absturzbericht zu „Absturz A“. Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem „A“).
2. Sie beheben diesen Fehler schnell, schließen das Problem „A“ und veröffentlichen dann eine neue Version Ihrer App.
3. Crashlytics erhält eine weitere Meldung zu Problem A, nachdem Sie das Problem geschlossen haben.
   • Wenn der Bericht von einer App-Version stammt, die Crashlytics bekannt war, als du das Problem geschlossen hast (die Version hat also einen Absturzbericht für einen Absturz gesendet), betrachtet Crashlytics das Problem nicht als behoben. Das Problem bleibt geschlossen.
   • Wenn der Bericht von einer App-Version stammt, von der Crashlytics nicht wusste, als Sie das Problem geschlossen haben (d. h., für die Version wurde nie ein Absturzbericht gesendet), betrachtet Crashlytics das Problem als wieder aufgetreten und öffnet es noch einmal.

Hinweis :Vor Februar 2022 hat Crashlytics ein Problem als Regression kategorisiert, wenn es in jeder App-Version noch einmal auftrat, selbst bei App-Versionen, von denen wir beim Schließen des Problems wussten. Dies führte dazu, dass Crashlytics manchmal Regressionen falsch erkannte. Wir verwenden jetzt die oben beschriebene Konvention.

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, können Sie es stummschalten, anstatt es zu schließen.

Warum treten bei älteren App-Versionen wieder Probleme auf?

Wenn ein Bericht von einer alten App-Version stammt, von der zum Zeitpunkt der Behebung des Problems noch keine Absturzberichte gesendet wurden, betrachtet Crashlytics das Problem als behoben und öffnet es wieder.

Diese Situation kann in folgenden Situationen eintreten: Du hast einen Fehler behoben und eine neue Version deiner App veröffentlicht, aber du hast noch Nutzer mit älteren Versionen ohne Fehlerkorrektur. Wenn bei einer dieser älteren Versionen zufällig nie Absturzberichte gesendet wurden, als Sie das Problem geschlossen haben, und diese Nutzer den Fehler dann wieder sehen, lösen diese Absturzberichte ein wiederaufgetretenes Problem aus.

Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus wieder geöffnet wird, können Sie es stummschalten, anstatt es zu schließen.

Hinweis :Vor Februar 2022 hat Crashlytics ein Problem als Regression kategorisiert, wenn es in einer App-Version wieder aufgetreten ist, auch wenn wir bereits von App-Versionen wussten, bei denen das Problem geschlossen wurde. Dies führte dazu, dass Crashlytics manchmal Regressionen falsch erkannte. Wir verwenden jetzt die oben beschriebene Konvention.

Wenn Sie viele fälschlicherweise als Regressionen identifizierte Probleme vor Februar 2022 sehen, können Sie sie wieder schließen, damit sie nicht wieder geöffnet werden.

Nicht erfasste Ausnahmen als schwerwiegende Ereignisse melden

Crashlytics kann nicht erfasste Ausnahmen als schwerwiegend melden (ab Version 10.4.0 des Unity SDK). Die folgenden häufig gestellten Fragen enthalten Begründungen und Best Practices für die Verwendung dieser Funktion.

Warum sollten nicht erfasste Ausnahmen in einer App als schwerwiegend gemeldet werden?

Wenn Sie nicht erfasste Ausnahmen als schwerwiegend melden, erhalten Sie eine realistischere Angabe dazu, welche Ausnahmen dazu führen können, dass das Spiel nicht mehr spielbar ist – auch wenn die App weiter ausgeführt wird.

Wenn Sie fehlerhafte Abstürze melden, sinkt der Prozentsatz der Nutzer ohne Abstürze wahrscheinlich. Der Messwert ist dann jedoch repräsentativer für die Nutzererfahrung mit Ihrer App.

Wichtig: Wenn Sie nicht abgefangene Ausnahmen als fatal melden, hat das keine Auswirkungen auf Ihre Android Vitals-Daten. Die in Crashlytics gemeldeten fatalen Fehler sind nur für Sie sichtbar, damit Sie Probleme in Ihren Apps und Spielen erkennen und beheben können.

Welche Ausnahmen werden als schwerwiegend gemeldet?

Damit Crashlytics eine nicht erfasste Ausnahme als schwerwiegend meldet, müssen beide der folgenden Bedingungen erfüllt sein:

• Während der Initialisierung in Ihrer App muss das Attribut ReportUncaughtExceptionsAsFatal auf true gesetzt werden.

• Ihre App (oder eine enthaltene Bibliothek) gibt eine nicht erfasste Ausnahme aus. Eine erstellte, aber nicht ausgelöste Ausnahme gilt nicht als nicht abgefangen.

Nachdem ich die Meldung nicht erfasster Ausnahmen als schwerwiegende Fehler aktiviert habe, habe ich jetzt viele neue schwerwiegende Fehler. Wie gehe ich mit diesen Ausnahmen richtig um?

Wenn Sie Berichte zu nicht abgefangenen Ausnahmen als fatale Fehler erhalten, haben Sie folgende Möglichkeiten, mit diesen Ausnahmen umzugehen:

• Überlegen Sie, wie Sie diese nicht abgefangenen Ausnahmen abfangen und behandeln können.
• Es gibt verschiedene Optionen, um Ausnahmen in der Unity-Debugkonsole und in Crashlytics zu protokollieren.

Ausgelöste Ausnahmen abfangen und verarbeiten

Ausnahmen werden erstellt und ausgelöst, um unerwartete oder außergewöhnliche Status widerzuspiegeln. Um die durch eine ausgelöste Ausnahme ausgelösten Probleme zu beheben, müssen Sie das Programm in einen bekannten Zustand zurückversetzen. 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.

Wenn Sie steuern möchten, welche Arten von Ausnahmen von welchem Code abgefangen und verarbeitet werden, fassen Sie Code, der eine Ausnahme generieren könnte, in einem try-catch-Block zusammen. Die Bedingungen in den catch-Anweisungen sollten so eng wie möglich gefasst sein, damit die jeweiligen Ausnahmen angemessen behandelt werden.

Ausnahmen in Unity oder Crashlytics protokollieren

Es gibt mehrere Möglichkeiten, Ausnahmen in Unity oder Crashlytics aufzuzeichnen, um das Problem zu beheben.

Bei der Verwendung von Crashlytics gibt es zwei gängige und empfohlene Optionen:

• Option 1: Während der Entwicklung oder Fehlerbehebung in der Unity-Konsole drucken, aber nicht an Crashlytics senden

  • Mit Debug.Log(exception), Debug.LogWarning(exception) und Debug.LogError(exception) können Sie den Inhalt der Ausnahme in die Unity-Konsole drucken und die Ausnahme nicht noch einmal werfen.

• Option 2: In folgenden Fällen können Sie Daten in Crashlytics hochladen, um konsolidierte Berichte im Crashlytics-Dashboard zu erhalten:

  • Wenn eine Ausnahme protokolliert werden sollte, um ein mögliches nachfolgendes Crashlytics-Ereignis zu beheben, verwenden Sie Crashlytics.Log(exception.ToString()).
  • Wenn eine Ausnahme dennoch an Crashlytics gemeldet werden soll, obwohl sie erfasst und verarbeitet wurde, verwenden Sie Crashlytics.LogException(exception), um sie als nicht schwerwiegendes Ereignis zu protokollieren.

Wenn Sie ein fatales Ereignis jedoch manuell in Unity Cloud Diagnostics melden möchten, können Sie Debug.LogException verwenden. Bei dieser Option wird die Ausnahme wie bei Option 1 in die Unity-Konsole ausgegeben, aber auch ausgelöst (unabhängig davon, ob sie bereits ausgelöst oder abgefangen wurde). Der Fehler wird nicht lokal ausgelöst. Das bedeutet, dass selbst ein umschließender 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:

• Die Ausnahme in der Unity-Konsole ausgeben
• Sie können die Ausnahme als schwerwiegendes Ereignis in Crashlytics hochladen.
• Damit die Ausnahme ausgelöst wird, muss sie als nicht erfasste Ausnahme 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 stattdessen so vor:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // 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
    //
}