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 das Gesuchte nicht finden oder weitere Unterstützung 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.

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 eingeführt. Außerdem haben wir das Design aktualisiert und einige erweiterte Funktionen für neue Probleme hinzugefügt, 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 Ereignisgruppierungsalgorithmus auf das Ereignis an und erstellen ein neues Problem mit dem überarbeiteten Metadatendesign.

Dies ist die erste große Änderung an unserer Ereignisgruppierung. Wenn du Feedback hast oder Probleme auftreten, kannst du uns 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 18.6.0 oder höher (oder Firebase BoM 32.6.0 oder höher).

Navigationspfad-Logs werden nicht angezeigt

Wenn keine Brotkrummenprotokolle angezeigt werden, empfehlen wir Ihnen, in der Konfiguration Ihrer App nach Google Analytics zu suchen. 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 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.

  Achten Sie darauf, dass Sie mindestens die folgende Version des Firebase SDK für Google Analytics verwenden:
  Android – Version 17.2.3 und höher (BoM Version 24.7.1 und höher).

Warum werden ANRs nur für Android 11 und höher gemeldet?

Crashlytics unterstützt ANR-Meldungen für Android-Apps von Geräten mit Android 11 und höher. Die zugrunde liegende API, mit der wir ANRs erfassen (getHistoricalProcessExitReasons), ist zuverlässiger als SIGQUIT- oder Watchdog-basierte Ansätze. Diese API ist nur auf Geräten mit Android 11 oder höher verfügbar.

Why are some ANRs missing their BuildIds?

Wenn bei einigen ANRs die BuildId fehlen, gehen Sie so vor:

• Sie müssen die aktuelle Version des Crashlytics Android SDK und des Crashlytics Gradle-Plug-ins verwenden.

  Wenn BuildIds für Android 11 und einige ANRs für Android 12 fehlen, verwenden Sie wahrscheinlich ein veraltetes SDK, ein veraltetes Gradle-Plug-in oder beides. Damit BuildIds für diese ANRs korrekt erfasst werden können, müssen Sie die folgenden Versionen verwenden:

  • Crashlytics Android SDK Version 18.3.5 und höher (Firebase BoM Version 31.2.2 und höher)
  • Crashlytics Gradle-Plug-in v2.9.4 oder höher

• Prüfen Sie, ob Sie einen nicht standardmäßigen Speicherort für Ihre freigegebenen Bibliotheken verwenden.

  Wenn nur BuildIds für die gemeinsam genutzten Bibliotheken Ihrer App fehlen, verwenden Sie wahrscheinlich nicht den Standardspeicherort für gemeinsam genutzte Bibliotheken. In diesem Fall kann Crashlytics die zugehörigen BuildId möglicherweise nicht finden. Wir empfehlen, den Standardspeicherort für freigegebene Bibliotheken zu verwenden.

• Achten Sie darauf, dass Sie während des Build-Prozesses keine BuildIds entfernen.

  Die folgenden Tipps zur Fehlerbehebung gelten sowohl für ANRs als auch für native Abstürze.

  • Prüfen Sie, ob die BuildId vorhanden sind, indem Sie readelf -n auf Ihren Binärdateien ausführen. Wenn die BuildIds fehlen, fügen Sie den Flags für Ihr Build-System -Wl,--build-id hinzu.

  • Achten Sie darauf, dass Sie die BuildId nicht versehentlich entfernen, um die APK-Größe zu reduzieren.

  • Wenn Sie entfernbare und nicht entfernbare Versionen einer Bibliothek beibehalten, müssen Sie in Ihrem Code auf die richtige Version verweisen.

Unterschiede zwischen ANR-Berichten im Crashlytics-Dashboard und in der Google Play Console

Die Anzahl der ANRs kann bei Google Play und Crashlytics abweichen. Das ist aufgrund der unterschiedlichen Erfassungs- und Berichtsmechanismen für ANR-Daten zu erwarten. Crashlytics meldet ANRs beim nächsten Start der App, während Android Vitals ANR-Daten nach dem Auftreten des ANR sendet.

Außerdem werden in Crashlytics nur ANRs angezeigt, die auf Geräten mit Android 11 oder höher auftreten. Google Play zeigt dagegen ANRs von Geräten mit Google Play-Diensten und erteilter Einwilligung zur Datenerhebung an.

Unterschiede zwischen NDK-Stack-Traces im Crashlytics-Dashboard und in logcat

LLVM- und GNU-Toolchains haben unterschiedliche Standardeinstellungen und Verarbeitungen für das nur-Lese-Segment der Binärdateien Ihrer App. Dies kann zu inkonsistenten Stack-Traces in der Firebase-Konsole führen. Fügen Sie Ihrem Build-Prozess die folgenden Linker-Flags hinzu, um dieses Problem zu vermeiden:

• Wenn Sie den lld-Linker aus der LLVM-Toolchain verwenden, fügen Sie Folgendes hinzu:

  -Wl,--no-rosegment

• Wenn Sie den ld.gold-Linker aus der GNU-Toolchain verwenden, fügen Sie Folgendes hinzu:

  -Wl,--rosegment

Wenn weiterhin Inkonsistenzen im Stack-Trace auftreten (oder keines der Flags für Ihre Toolchain relevant ist), fügen Sie Ihrem Build-Prozess stattdessen Folgendes hinzu:

-fno-omit-frame-pointer

Wie verwende ich meine eigene Breakpad-Symboldatei-Generator-Binärdatei für das NDK?

Das Crashlytics-Plug-in enthält einen benutzerdefinierten Breakpad-Symboldateigenerator. Wenn Sie zum Generieren von Breakpad-Symboldateien lieber Ihre eigene Binärdatei verwenden möchten (z. B. wenn Sie alle nativen ausführbaren Dateien in Ihrer Build-Kette aus der Quelle erstellen möchten), verwenden Sie das optionale Erweiterungsattribut symbolGeneratorBinary, um den Pfad zur ausführbaren Datei anzugeben.

Hinweis: Die Linux-Version des Breakpad-Symboldateigenerators ist für Android-Binärdateien erforderlich.

Sie haben zwei Möglichkeiten, den Pfad zum Breakpad-Symboldateigenerator anzugeben:

• Option 1: Pfad über die firebaseCrashlytics-Erweiterung in der build.gradle-Datei angeben

  Fügen Sie der Datei build.gradle.kts auf App-Ebene Folgendes hinzu:

  Gradle-Plug-in Version 3.0.0 oder höher

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  niedrigere Plug-in-Versionen

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• Option 2: Pfad über eine Property-Zeile in der Gradle-Properties-Datei angeben

  Mit der Property com.google.firebase.crashlytics.breakpadBinary können Sie den Pfad zur ausführbaren Datei angeben.

  Sie können die Gradle-Attributdatei manuell oder über die Befehlszeile aktualisieren. Wenn Sie den Pfad beispielsweise über die Befehlszeile angeben möchten, verwenden Sie einen Befehl wie diesen:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Keine Abstürze mit Dexguard

Wenn die folgende Ausnahme angezeigt wird, verwenden Sie wahrscheinlich eine Version von DexGuard, die nicht mit dem Firebase Crashlytics SDK kompatibel ist:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Diese Ausnahme führt nicht zu einem Absturz Ihrer App, verhindert aber das Senden von Absturzberichten. So lösen Sie das Problem:

1. Achten Sie darauf, dass Sie die neueste Version von DexGuard 8.x verwenden. Die neueste Version enthält Regeln, die vom Firebase Crashlytics SDK benötigt werden.

2. Wenn Sie die DexGuard-Version nicht ändern möchten, fügen Sie Ihren Obfuscation-Regeln (in der DexGuard-Konfigurationsdatei) die folgende Zeile hinzu:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Warum werden Abstürze durch .kt-Dateien verursacht, die als .java-Probleme gekennzeichnet sind?

Wenn eine App einen Obfuscator verwendet, der die Dateiendung nicht preisgibt, generiert Crashlytics standardmäßig jedes Problem mit der Dateiendung .java.

Damit Crashlytics Probleme mit der richtigen Dateiendung generieren kann, muss Ihre App die folgende Konfiguration verwenden:

• Android Gradle 4.2.0 oder höher verwendet
• Verwendet R8 mit aktivierter Verschleierung. Folgen Sie dieser Anleitung, um Ihre App auf R8 zu aktualisieren.

Hinweis: Nach der Umstellung auf die oben beschriebene Einrichtung werden möglicherweise neue .kt-Probleme angezeigt, die Duplikate vorhandener .java-Probleme sind. Weitere Informationen finden Sie in den häufig gestellten Fragen.

Warum sehe ich .kt-Probleme, die Duplikate vorhandener .java-Probleme sind?

Seit Mitte Dezember 2021 bietet Crashlytics eine verbesserte Unterstützung für Anwendungen, die Kotlin verwenden.

Bis vor Kurzem haben die verfügbaren Obfuscatoren die Dateiendung nicht offengelegt. Daher hat Crashlytics jedes Problem standardmäßig mit der Dateiendung .java generiert. Ab Android Gradle 4.2.0 unterstützt R8 jedoch Dateiendungen.

Mit diesem Update kann Crashlytics jetzt feststellen, ob jede in der App verwendete Klasse in Kotlin geschrieben ist, und den richtigen Dateinamen in die Problemsignatur aufnehmen. Abstürze werden jetzt .kt-Dateien korrekt zugeordnet, sofern Ihre App die folgende Konfiguration hat:

• Ihre App verwendet Android Gradle 4.2.0 oder höher.
• Ihre App verwendet R8 mit aktivierter Verschleierung.

Da neue Abstürze jetzt die richtige Dateiendung in ihren Problemsignaturen enthalten, sehen Sie möglicherweise neue .kt-Probleme, die eigentlich nur Duplikate vorhandener Probleme mit der Kennzeichnung .java sind. In der Firebase-Konsole versuchen wir, festzustellen, ob ein neues .kt-Problem möglicherweise ein Duplikat eines vorhandenen Problems mit dem Label .java ist.

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, 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:

• 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 sich die zu einem Problem geposteten Notizen ansehen, sie aber nicht löschen oder verfassen.

  • Project Viewer, Firebase-Betrachter, Quality-Betrachter 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, 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:

• 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 sich die zu einem Problem geposteten Notizen ansehen, sie aber nicht löschen oder verfassen.

  • 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 dazu 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, automatisch in den USA gespeichert, unabhängig vom Standort Ihres Firebase-Projekts.

Plattformunterstützung

Unterstützt Crashlytics armeabi?

Das Firebase Crashlytics NDK unterstützt ARMv5 (armeabi) nicht. Die Unterstützung für diese ABI wurde mit NDK r17 entfernt.

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 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 wieder aufgetreten 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.

Hinweis: Vor Februar 2022 hat Crashlytics ein Problem als Regression kategorisiert, wenn es in einer beliebigen App-Version wieder aufgetreten ist, auch in App-Versionen, die uns bekannt waren, als Sie das Problem geschlossen haben. 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 zu dem Zeitpunkt, als Sie das Problem geschlossen haben, noch keine 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 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 von App-Versionen wussten, die Sie geschlossen hatten. 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.