Fehlerbehebung und FAQs zu Crashlytics

iOS oder höher Android Flutter Unity

Diese Seite enthält Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte Fragen. Fragen zur Verwendung von Crashlytics. Wenn Sie das Gesuchte nicht finden oder weitere Unterstützung benötigen, wenden Sie sich an den Firebase-Support.

Allgemeine Fehlerbehebung/FAQs

Unterschiedliche Formate sehen (und manchmal „Varianten“) bei einigen Problemen in der Tabelle Probleme

In der Tabelle Probleme in der Firebase Console werden möglicherweise zwei verschiedene Formate für Probleme aufgeführt. Außerdem sehen Sie bei einigen Problemen möglicherweise die Funktion „Varianten“. Hier erfährst du, warum.

Anfang 2023 haben wir ein verbessertes Analysemodul zum Gruppieren von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme (wie Varianten!). Sehen Sie sich unsere aktuellen Blogpost . Hier findest du die wichtigsten Informationen.

Crashlytics analysiert alle Ereignisse in deiner App, z. B. Abstürze, nicht schwerwiegende und ANR-Fehler) und erstellt Gruppen von Ereignissen, sogenannte Probleme – alle Ereignisse in einem einen gemeinsamen Point of Failure haben.

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

Innerhalb dieser Gruppe von Ereignissen können sich die Stacktraces, die zum Fehler führen, jedoch unterscheiden. Ein anderer Stacktrace kann auf eine andere Ursache hinweisen. 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 beheben und feststellen, ob ein Problem verschiedene Ursachen hat.

Diese Verbesserungen erwarten Sie:

• Überarbeitete Metadaten, die in der Problemzeile angezeigt werden
  Probleme in deiner App lassen sich jetzt noch einfacher verstehen und einordnen.

• Weniger doppelte Probleme
  Eine Änderung der Zeilennummer führt nicht zu einem neuen Problem.

• Einfachere Fehlerbehebung bei komplexen Problemen mit verschiedenen Ursachen
  Mit Varianten Fehler in den häufigsten Stacktraces innerhalb eines Problems beheben.

• Aussagekräftigere Warnungen und Signale
  Ein neues Problem stellt tatsächlich einen neuen Fehler dar.

• Leistungsstärkere 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 zu einem vorhandenen Problem passen.

• Wenn es keine Übereinstimmung gibt, wenden wir automatisch unsere intelligentere Ereignisgruppierung an. Algorithmus auf das Ereignis hinzu und erstellen ein neues Problem mit den überarbeiteten Metadaten. Design.

Dies ist das erste große Update, das wir an unserer Ereignisgruppierung vornehmen. Wenn du Feedback hast oder Probleme auftreten, kannst du dich jederzeit gern 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 Messwerte ohne Abstürze sehen (z. B. zu Nutzern und Sitzungen ohne Abstürze) und/oder Geschwindigkeitswarnungen aktiviert haben, Crashlytics SDK 11.7.0 oder höher.

Navigationspfad-Logs werden nicht angezeigt

Wenn Sie nicht Navigationspfade empfehlen wir, die Konfiguration deiner App auf Google Analytics zu prüfen. Sie müssen 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 über diese Einstellung in Einstellungen für die Freigabe von Analytics-Daten verwalten

• 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 den neueste Firebase SDK-Versionen für alle Produkte, die Sie in Ihrer App nutzen.

Nicht symbolisch dargestellt Stacktraces für Android-Apps im Crashlytics-Dashboard

Wenn Sie Unity IL2CPP verwenden und Stacktraces ohne Symbol angezeigt werden, versuchen Sie Folgendes:

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

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

Kann Crashlytics mit Apps verwendet werden, die IL2CPP verwenden?

Ja, Crashlytics kann symbolische Stack-Traces für Ihre Apps anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die unter Android oder Apple-Plattformen. Gehen Sie dazu so vor:

1. Sie benötigen Version 8.6.0 oder höher von Crashlytics Unity SDK.

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

   • Apple-Plattform-Apps: Es sind keine besonderen Maßnahmen erforderlich. Für Apple werden vom Firebase Unity Editor-Plug-in automatisch Xcode-Projekt hochladen, um Symbole hochzuladen.

   • Android-Apps: Vergewissern Sie sich, dass die App für Android-Apps richtig eingerichtet ist und ausgeführt wird. Firebase CLI crashlytics:symbols:upload-Befehl zum Generieren und laden Sie Ihre Symboldatei hoch.

     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 in der Lesbare Absturzberichte erhalten Seite.

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.

Mit der folgenden Formel wird der Prozentsatz der Nutzer ohne Abstürze berechnet. 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 den Ereignistyp app_exception. CRASHED_USERS steht für die Anzahl der Nutzer, die mit diesem Ereignistyp verknüpft sind.

• ALL_USERS steht für die Gesamtzahl der Nutzer, die mit für den Zeitraum, den Sie im Drop-down-Menü oben rechts im Crashlytics-Dashboard.

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 geringfügiger Unterschiede bei der Art und Weise, wie Abstürze auftreten, verarbeitet, der im Analytics-Dashboard angezeigte Wert für app_exception kann gelegentlich von dem Wert abweichen, den wir für unsere Berechnung der Häufigkeit ohne Abstürze verwenden. Prozentsatz der Nutzer

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

Angenommen, Ihre App hat drei Nutzer: Nutzer A, Nutzer B und Nutzer C. 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 liegt der Prozentsatz der Nutzer ohne Abstürze bei 50% (1 von 2 Nutzern war ohne Abstürze).
  Zwei Ihrer Nutzer haben am Mittwoch mit Ihrer App interagiert, aber nur bei einem von ihnen (Nutzer B) kam es zu keinen Abstürzen.

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

• In den letzten 3 Tagen lag der Prozentsatz der Nutzer ohne Abstürze bei 0% (0 von 3 ohne Abstürze).
  Drei Ihrer Nutzer haben in den letzten drei Tagen mit Ihrer App interagiert, bei keiner von ihnen gab es 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 bei längeren Zeiträumen wahrscheinlich geringer.

Hinweis: Wenn du die Karte Ereignis für Statistiken zu Abstürzen ohne Abstürze filterst, siehst du eine leere Karte. nur nicht schwerwiegende Probleme. Der Prozentsatz der Nutzer ohne Abstürze für schwerwiegende Ereignisse berechnet.

Wer kann Notizen zu einem Problem aufrufen, erstellen und löschen?

Mit Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.

Wenn ein Projektmitglied eine Notiz postet, ist sie mit der E-Mail-Adresse seines Google Konto. Diese E-Mail-Adresse ist zusammen mit der Notiz für alle Projekte sichtbar Mitglieder mit Leseberechtigung für die Notiz.

Im Folgenden werden die erforderlichen Zugriffsrechte zum Anzeigen, Schreiben und Löschen beschrieben. Hinweise:

• 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, Quality-Administrator oder Crashlytics-Administrator

• Projektmitglieder mit einer der folgenden Rollen können die Notizen ansehen, die auf Probleme auftreten, aber sie können 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 aufrufen, erstellen und löschen?

Mit Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. kommentieren.

Wenn ein Projektmitglied eine Notiz postet, ist sie mit der E-Mail-Adresse seines Google Konto. Diese E-Mail-Adresse ist zusammen mit der Notiz für alle Projekte sichtbar Mitglieder mit Leseberechtigung für die Notiz.

Im Folgenden werden die erforderlichen Zugriffsrechte zum Anzeigen, Schreiben und Löschen beschrieben. Hinweise:

• Projektmitglieder mit einer der folgenden Rollen können vorhandene und neue Notizen zu einem Problem zu verfassen.

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

• Projektmitglieder mit einer der folgenden Rollen können sich die zu einem Problem geposteten Notizen ansehen, sie aber nicht löschen oder verfassen.

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

Integrationen

Die App verwendet auch die Google Mobile Ads SDK kommt aber 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. Deaktivieren Sie zum Beheben des Problems die Absturzberichte in das Mobile Ads SDK durch Aufrufen von disableSDKCrashReporting.

Wo befindet sich mein BigQuery-Dataset?

Nachdem Sie Crashlytics mit BigQuery verknüpft haben, werden neu erstellte Datasets sich automatisch in den USA befinden, unabhängig vom Standort Ihres Firebase-Projekt

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.

Hier ist ein Beispielszenario, in dem erläutert wird, wie Crashlytics ein als Regressionsproblem:

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 Sie das Problem geschlossen haben, d. h., die Version hat einen Absturz ausgelöst. irgendeinen Absturz melden, berücksichtigt Crashlytics den Fehler bereits behoben. Das Problem bleibt geschlossen.
   • Wenn der Bericht von einer App-Version stammt, die Crashlytics nichtnicht nicht wissen, wann Sie das Problem geschlossen haben, d. h., nie keinen Absturzbericht für einen Absturz gesendet, dann Crashlytics betrachtet das Problem als bereits behoben und öffnet den Problem.

Hinweis :Vor Februar 2022 hat Crashlytics ein Problem als wenn das Problem in irgendeiner App-Version wieder auftrat, selbst bei Versionen, die uns bekannt waren, als Sie das Problem behoben haben. Dies führte zu Crashlytics identifiziert Regressionen manchmal falsch. Wir verwenden jetzt die oben beschriebene Konvention.

Wenn ein Problem wieder auftritt, senden wir eine Benachrichtigung zur Regressionserkennung und fügen Regressionssignal für das Problem, das Sie darüber informiert, dass Crashlytics haben das Problem wieder geöffnet. 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 noch nie unter folgendem Link keine Absturzberichte gesendet wurden: Wenn du das Problem geschlossen hast, wird es von Crashlytics geprüft und das Problem wird wieder geöffnet.

Diese Situation kann in folgenden Situationen eintreten: Sie haben einen Fehler behoben und Eine neue Version deiner App wurde veröffentlicht, du hast aber noch Nutzer mit älteren Versionen ohne den Fehler zu beheben. Wenn bei einer dieser älteren Versionen nie Absturzberichte gesendet wurden, als Sie das Problem geschlossen haben, und diese Nutzer den Fehler jetzt 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 der App-Version wussten, als Sie das Problem geschlossen haben. Das Ergebnis: Crashlytics und manchmal Regressionen fälschlicherweise identifiziert. 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). In den folgenden FAQs werden die Hintergründe und Best Practices für die Verwendung dieser Funktion erläutert.

Warum sollte eine App nicht abgefangene Ausnahmen als schwerwiegend melden?

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 schiefgelaufene Abläufe melden, sinkt der Prozentsatz der Nutzer ohne Abstürze wahrscheinlich. Der Messwert ist dann aber repräsentativer für die Nutzererfahrung mit Ihrer App.

Wichtig :Wenn Sie nicht abgefangene Ausnahmen als schwerwiegende Ausnahmen melden, hat dies keine Auswirkungen deine Android Vitals. Die in Crashlytics gemeldeten schwerwiegenden Todesfälle sind nur für Sie sichtbar, damit Sie um Probleme in deinen Apps und Spielen zu erkennen und zu beheben.

Welche Ausnahmen als tödlich gemeldet?

Damit Crashlytics eine nicht abgefangene Ausnahme als schwerwiegend melden kann, müssen beide müssen die folgenden beiden Bedingungen erfüllt sein:

• Während der Initialisierung in deiner App wird der ReportUncaughtExceptionsAsFatal muss auf true

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

Nachdem ich die Meldung von nicht abgefangenen Ausnahmen als schwerwiegend aktiviert habe, gibt es jetzt viele neue schwerwiegende Fehler. Wie gehe ich mit diesen Ausnahmen ordnungsgemäß um?

Wenn Sie Berichte für Ihre nicht abgefangenen Ausnahmen als schwerwiegende Ausnahmen erhalten, gehen Sie so vor: einige Optionen für den Umgang mit diesen nicht abgefangenen Ausnahmen:

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

Ausgewürfelte Ausnahmen abfangen und behandeln

Ausnahmen werden erstellt und ausgelöst, um unerwartete oder außergewöhnliche Bundesländer. Um die durch eine geworfene Ausnahme verursachten Probleme zu beheben, muss das Programm in einen bekannten Zustand zurückversetzt werden. Dieser Vorgang wird als Ausnahmebehandlung bezeichnet.

Als Best Practice wird empfohlen, alle vorhersehbaren Ausnahmen abzufangen und zu bearbeiten, es sei denn, das Programm kann nicht in einen bekannten Zustand zurückgeführt werden.

Um zu steuern, welche Arten von Ausnahmen von welchem Code abgefangen und verarbeitet werden, verpacken Sie Code, der eine Ausnahme generieren könnte, in einem try-catch-Block. Achten Sie darauf, dass die Bedingungen in den catch-Anweisungen so eng wie möglich gefasst sind, damit die jeweiligen Ausnahmen angemessen behandelt werden.

Ausnahmen in Unity oder Crashlytics protokollieren

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

Im Folgenden werden die beiden häufigsten und empfohlenen Crashlytics Optionen:

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

  • Über Debug.Log(exception) an die Unity-Konsole senden Debug.LogWarning(exception) und Debug.LogError(exception), die den Inhalt der Ausnahme in der Unity-Konsole ausgeben Ausnahme noch einmal auslösen.

• 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 trotz Auffangen und Beheben an Crashlytics gemeldet werden soll, verwenden Sie Crashlytics.LogException(exception), um sie als nicht kritisches Ereignis zu protokollieren.

Wenn Sie jedoch ein schwerwiegendes Ereignis manuell an Unity Cloud melden möchten, Diagnose-Tool: Sie können Debug.LogException verwenden. Mit dieser Option wird die Ausnahme wie Option 1 an die Unity-Konsole, wirft aber auch die Ausnahme (ob sie noch geworfen oder gefangen wurde). Der Fehler wird nicht lokal ausgelöst. Das bedeutet, dass selbst eine umgebende Debug.LogException(exception) mit try-catch-Blöcken führt immer noch zu einer nicht abgefangenen Ausnahme.

Rufen Sie Debug.LogException daher nur auf, wenn Sie alle der folgenden Aktionen ausführen möchten:

• Um die Ausnahme in der Unity-Konsole auszugeben.
• 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 erfasste Ausnahme in der Unity-Konsole ausgeben und als nicht kritisches 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
    //
}