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 18.6.0 oder höher bzw. Firebase BoM Version 32.6.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.

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

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:

• Verwende ein aktuelles Crashlytics Android SDK und Crashlytics-Version des Gradle-Plug-ins.

  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 die BuildIds für diese ANR-Fehler ordnungsgemäß erfasst werden, müssen Sie Folgendes verwenden: Versionen:

  • Crashlytics Android SDK Version 18.3.5 oder höher (Firebase BoM Version 31.2.2 oder 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. Wenn kann Crashlytics den Schlüssel möglicherweise nicht finden, verknüpfte BuildIds. Wir empfehlen Ihnen, die Standard- Speicherort für geteilte Fotogalerien.

• 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 dann -Wl,--build-id zu den Flags für Ihre zu erstellen.

  • 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 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 ANR-Fehler, wenn die App während Android Vitals nach dem ANR-Fehler ANR-Daten 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 die folgenden Verknüpfungs-Flags hinzu, um dieses Problem zu umgehen zu Ihrem Build-Prozess hinzufügen:

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

  -Wl,--no-rosegment
  

• Wenn Sie die ld.gold-Verknüpfung 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 mein eigenes Binärprogramm für den Breakpad-Symboldateigenerator für NDK verwenden?

Das Crashlytics-Plug-in enthält einen benutzerdefinierten Breakpad-Symboldateigenerator. Wenn Sie zum Generieren von Breakpad-Symboldateien (für Wenn Sie es vorziehen, alle nativen ausführbaren Dateien in Ihrer Build-Kette aus Quelle), verwenden Sie zum Angeben das optionale Erweiterungsattribut symbolGeneratorBinary Pfad zur ausführbaren Datei.

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

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

• Option 1: Pfad über firebaseCrashlytics angeben Dateiendung in der Datei build.gradle

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

  Gradle-Plug-in ab Version 3.0.0

  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

  Sie können die com.google.firebase.crashlytics.breakpadBinary verwenden , um den Pfad zur ausführbaren Datei anzugeben.

  Du kannst die Datei mit den Gradle-Attributen manuell oder manuell aktualisieren. über die Befehlszeile ausführen. Um den Pfad beispielsweise über den Befehl führen Sie einen Befehl wie den folgenden aus:

  ./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, dass Absturzberichte gesendet werden. 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 Ihre DexGuard-Version nicht ändern möchten, fügen Sie Folgendes hinzu: zu Ihren Verschleierungsregeln (in Ihrer DexGuard-Konfigurationsdatei):

   -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 Verschleierungsmechanismus verwendet, der die Dateiendung nicht offenlegt, Crashlytics generiert jedes Problem standardmäßig mit der Dateiendung .java.

Damit Crashlytics Probleme mit der richtigen Dateiendung erzeugen kann, Achten Sie darauf, dass Ihre App die folgende Konfiguration verwendet:

• Android Gradle 4.2.0 oder höher verwendet
• Verwendet R8 mit aktivierter Verschleierung. So aktualisieren Sie Ihre App auf R8: Dokumentation.

Nach der Aktualisierung auf die oben beschriebene Einrichtung sehen Sie möglicherweise neue .kt Probleme, die Duplikate vorhandener .java Probleme sind. Weitere Informationen finden Sie in den häufig gestellten Fragen.

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

Ab Mitte Dezember 2021 hat Crashlytics die Unterstützung für Anwendungen verbessert 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 die einzelnen Klassen in Die App ist in Kotlin geschrieben und enthält den korrekten Dateinamen. Signatur. Abstürze werden jetzt .kt-Dateien korrekt zugeordnet, wenn Ihre App die folgende Konfiguration hat:

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

Da neue Abstürze jetzt die richtige Dateiendung enthalten Signaturen erhalten Sie möglicherweise neue .kt-Probleme, die eigentlich nur Duplikate von vorhandene Probleme mit dem Label „.java“. In der Firebase-Konsole versuchen wir, und informieren Sie Sie, wenn ein neues Problem mit der Sicherheitslücke (.kt) ein mögliches Duplikat eines bestehendes Problem mit dem Label .java.

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

Plattformsupport

Unterstützt Crashlytics Armeabi?

Das Firebase Crashlytics NDK unterstützt ARMv5 (armeabi) nicht. Ab NDK r17 wird dieses ABI nicht mehr unterstützt.

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.