Fehlerbehebung und FAQs zu Crashlytics


Auf dieser Seite finden Sie Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte 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

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 ist der Grund dafür:

Anfang 2023 haben wir eine verbesserte Analyse-Engine zur Gruppierung von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme eingeführt (z. B. Varianten). 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 in diesen Problemen zu gruppieren, berücksichtigt die verbesserte Analyse-Engine jetzt viele Aspekte des Ereignisses, einschließlich der Frames im Stack-Trace, der Ausnahmemeldung, des Fehlercodes und anderer Plattform- oder Fehlertypmerkmale.

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 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 bringen folgende Vorteile:

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

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

  • Leistungsstärkere Suche
    Jedes Problem enthält mehr suchbare Metadaten, z. B. 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 Algorithmus zur Ereignisgruppierung auf das Ereignis an und erstellen ein neues Problem mit dem überarbeiteten Metadatendesign.

Dies ist die erste große Aktualisierung unserer Ereignisgruppierung. Wenn du Feedback hast oder Probleme auftreten, kannst du dich jederzeit gern an uns wenden. Hier kannst du eine Meldung senden.

Wenn keine Brotkrummenprotokolle angezeigt werden, sollten Sie in der Konfiguration Ihrer App nach Google Analytics suchen. Sie müssen die folgenden Anforderungen erfüllen:

Wenn Sie keine Geschwindigkeitswarnungen sehen, verwenden Sie das Crashlytics SDK 10.8.0 oder höher.

Wenn Sie keine Messwerte zu Nutzern und Sitzungen ohne Abstürze sehen oder die Messwerte unzuverlässig sind, prüfen Sie Folgendes:

  • Verwenden Sie das Crashlytics SDK 10.8.0 oder höher.

  • Achten Sie darauf, dass die Einstellungen für die Datenerhebung nicht die Qualität Ihrer fehlerfreien Messwerte beeinträchtigen:

    • Wenn Sie die Berichterstellung aktivieren, indem Sie die automatische Absturzberichte deaktivieren, können Absturzinformationen nur von Nutzern an Crashlytics gesendet werden, die die Datenerhebung ausdrücklich zugestimmt haben. Die Genauigkeit der fehlerfreien Messwerte wird dadurch beeinträchtigt, da Crashlytics nur Absturzinformationen von diesen Nutzern enthält, die die Funktion aktiviert haben, und nicht von allen Ihren Nutzern. Das bedeutet, dass die Messwerte für die Anzahl der Abstürze möglicherweise weniger zuverlässig sind und die Gesamtstabilität Ihrer App weniger widerspiegeln.

    • Wenn Sie die automatische Datenerhebung deaktiviert haben, können Sie mitsendUnsentReports Berichte, die auf dem Gerät im Cache gespeichert sind, an Crashlytics senden. Bei dieser Methode werden Absturzdaten an Crashlytics gesendet, aber keine Sitzungsdaten. In den Console-Diagrammen werden daher für fehlerfreie Messwerte niedrige oder Nullwerte angezeigt.

Weitere Informationen finden Sie unter Messwerte ohne Abstürze.

Wenn Sie die DSYMs Ihres Projekts hochladen und eine ausführliche Ausgabe erhalten möchten, prüfen Sie Folgendes:

  1. Die Build-Phase Ihres Projekts muss das Crashlytics-Ausführungsskript enthalten, damit Xcode die DSYMs Ihres Projekts zur Buildzeit hochladen kann. Eine Anleitung zum Hinzufügen des Scripts finden Sie unter Crashlytics initialisieren. Nachdem Sie Ihr Projekt aktualisiert haben, erzwingen Sie einen Absturz und prüfen Sie, ob der Absturz im Crashlytics-Dashboard angezeigt wird.

  2. Wenn in der Firebase-Konsole die Warnung „Missing dSYM“ (Fehlender dSYM) angezeigt wird, prüfen Sie in Xcode, ob dSYMs für den Build richtig erstellt werden.

  3. Wenn Xcode korrekt dSYMs erstellt und trotzdem dSYMs fehlen, hängt das Run Script Tool beim Hochladen der dSYMs wahrscheinlich fest. Versuchen Sie in diesem Fall Folgendes:

    • Achten Sie darauf, dass Sie die neueste Version von Crashlytics verwenden.

    • Laden Sie die fehlenden dSYM-Dateien manuell hoch:

      • Option 1:Verwenden Sie die konsolenbasierte Option „Drag-and-drop“ auf dem Tab dSYMs, um ein ZIP-Archiv mit den fehlenden dSYM-Dateien hochzuladen.
      • Option 2:Verwenden Sie das upload-symbols-Script, um die fehlenden dSYM-Dateien für die angegebenen UUIDs auf dem Tab dSYMs hochzuladen.

  4. Wenn weiterhin dSYMs fehlen oder Uploads weiterhin fehlschlagen, wenden Sie sich an den Firebase-Support und senden Sie Ihre Protokolle.

Wenn Ihre Stack-Traces anscheinend nicht richtig symbolisiert sind, prüfen Sie Folgendes:

  • Wenn Frames aus der Bibliothek Ihrer App keine Verweise auf den Code Ihrer App enthalten, prüfen Sie, ob -fomit-frame-pointer nicht als Kompilierungsflag festgelegt ist.

  • Wenn Sie mehrere (Missing)-Frames für die Bibliothek Ihrer App sehen, prüfen Sie, ob optionale dSYMs (für die betroffene App-Version) auf dem Tab Crashlytics dSYMs der Firebase-Konsole als fehlend aufgeführt sind. Folgen Sie in diesem Fall der Anleitung zur Fehlerbehebung unter „Fehlende dSYM-Warnung“ in den häufig gestellten Fragen zu fehlenden oder nicht hochgeladenen dSYMs auf dieser Seite. Durch das Hochladen dieser dSYMs werden bereits aufgetretene Abstürze nicht symbolisiert. Dies trägt jedoch dazu bei, dass zukünftige Abstürze symbolisiert werden.

Mit Notizen können Projektmitglieder bestimmte Probleme mit Fragen, Statusaktualisierungen usw. 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 Zugriff darauf haben.

Im Folgenden wird der Zugriff beschrieben, der zum Ansehen, Schreiben und Löschen von Notizen erforderlich ist:

Integrationen

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

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

Plattformunterstützung

Ja, Sie können Crashlytics in macOS- und tvOS-Projekten implementieren. Verwenden Sie Version 8.9.0 oder höher des Firebase SDK für Google Analytics, damit bei Abstürzen auf Messwerte zu Google Analytics zugegriffen werden kann (Nutzer ohne Abstürze, neueste Version, Geschwindigkeitswarnungen und Breadcrumb-Logs).

Sie können jetzt Abstürze für mehrere Apps in einem einzigen Firebase-Projekt melden, auch wenn die Apps für verschiedene Apple-Plattformen (z.B. iOS, tvOS und Mac Catalyst) erstellt wurden. Bisher mussten Sie die Apps in einzelne Firebase-Projekte aufteilen, wenn sie dieselbe Bundle-ID enthielten.

Wieder auftretende Probleme

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

Im folgenden Beispiel 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 Sie das Problem geschlossen haben (d. h. für die Version wurde ein Absturzbericht für einen beliebigen Absturz gesendet), wird das Problem von Crashlytics nicht als wiederaufgetreten eingestuft. 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.

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.

Wenn ein Bericht von einer alten App-Version stammt, von der zu dem Zeitpunkt, als Sie das Problem geschlossen haben, noch nie Absturzberichte gesendet wurden, betrachtet Crashlytics das Problem als wieder aufgetreten und öffnet es noch einmal.

Das kann in folgenden Fällen passieren: Sie haben einen Fehler behoben und eine neue Version Ihrer App veröffentlicht, aber es gibt immer noch Nutzer, die ältere Versionen ohne Fehlerbehebung verwenden. 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.