Fehlerbehebung und häufig gestellte Fragen zu Crashlytics

Absturzfreie Benutzer, Breadcrumb-Protokolle und/oder Geschwindigkeitswarnungen werden nicht angezeigt

Wenn Sie keine absturzfreien Benutzer, Breadcrumb-Protokolle und/oder Geschwindigkeitswarnungen sehen, empfehlen wir, die Konfiguration Ihrer App für Google Analytics zu überprüfen.

• Stellen Sie sicher, dass Sie Google Analytics in Ihrem Firebase-Projekt aktiviert haben.

• Stellen Sie sicher, dass die Datenfreigabe für Google Analytics auf der Seite Integrationen > Google Analytics der Firebase-Konsole aktiviert ist. Beachten Sie, dass die Datenfreigabeeinstellungen in der Firebase-Konsole angezeigt, aber in der Google Analytics-Konsole verwaltet werden.

• Stellen Sie neben dem Firebase Crashlytics SDK sicher, dass Sie Ihrer App ( iOS+ | Android ) das Firebase SDK für Google Analytics hinzugefügt haben.

• Stellen Sie sicher, dass Sie die neuesten Versionen für alle Ihre Firebase SDKs ( iOS+ | Android ) verwenden.
  Stellen Sie insbesondere sicher, dass Sie mindestens die folgenden Versionen des Firebase SDK für Google Analytics verwenden: iOS+ – v6.3.1+ (v8.9.0+ für macOS und tvOS) | Android – v17.2.3+ (BoM v24.7.1+) .

Es werden zwei verschiedene Formate in der Problemtabelle angezeigt

Möglicherweise bemerken Sie zwei verschiedene Formate für Probleme, die in Ihrer Problemtabelle in der Firebase-Konsole aufgeführt sind. Hier ist der Grund!

Crashlytics analysiert alle Ereignisse aus Ihrer App – Abstürze, nicht schwerwiegende und ANRs – und gruppiert ähnliche Ereignisse in separate Probleme. Im Januar 2023 haben wir eine verbesserte Analyse-Engine zum Gruppieren von Ereignissen basierend auf dem Code Ihrer App und ein aktualisiertes Design zum Anzeigen neuer Probleme eingeführt.

Hier ist, was Sie mit diesen Verbesserungen erleben werden:

• Überarbeitete Metadaten, die in der Problemzeile angezeigt werden
  Es ist jetzt einfacher, Probleme in Ihrer App zu verstehen und zu selektieren.

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

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

• Leistungsfähigere 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 mit einem bestehenden Problem übereinstimmen.

• Wenn es keine Übereinstimmung gibt, 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 Event-Gruppierung vornehmen. Wenn Sie Feedback haben oder auf Probleme stoßen, teilen Sie uns dies bitte mit, indem Sie einen Bericht einreichen.

Warum werden ANRs nur für Android 11+ gemeldet?

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

Warum fehlen einigen ANRs ihre BuildId ?

Wenn einigen Ihrer ANRs ihre BuildId fehlen, gehen Sie wie folgt vor:

• Stellen Sie sicher, dass Sie eine aktuelle Version des Crashlytics Android SDK und des Crashlytics Gradle-Plugins verwenden.

  Wenn Ihnen BuildId s für Android 11 und einige ANRs für Android 12 fehlen, verwenden Sie wahrscheinlich ein veraltetes SDK, Gradle-Plugin oder beides. Um BuildId für diese ANRs ordnungsgemäß zu erfassen, müssen Sie die folgenden Versionen verwenden:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle-Plugin v2.9.4+

• Überprüfen Sie, ob Sie einen nicht standardmäßigen Speicherort für Ihre gemeinsam genutzten Bibliotheken verwenden.

  Wenn Ihnen nur BuildId s für die gemeinsam genutzten Bibliotheken Ihrer App fehlen, verwenden Sie wahrscheinlich nicht den standardmäßigen Standardspeicherort für gemeinsam genutzte Bibliotheken. Wenn dies der Fall ist, kann Crashlytics die zugehörigen BuildId möglicherweise nicht finden. Wir empfehlen Ihnen, den Standardspeicherort für gemeinsam genutzte Bibliotheken zu verwenden.

• Stellen Sie sicher, dass Sie BuildId während des Erstellungsprozesses nicht entfernen.

  Beachten Sie, dass die folgenden Tipps zur Fehlerbehebung sowohl für ANRs als auch für native Abstürze gelten.

  • Überprüfen Sie, ob die BuildId vorhanden sind, indem Sie readelf -n für Ihre Binärdateien ausführen. Wenn die BuildId s fehlen, fügen Sie -Wl,--build-id zu den Flags für Ihr Build-System hinzu.

  • Stellen Sie sicher, dass Sie die BuildId nicht versehentlich entfernen, um Ihre APK-Größe zu reduzieren.

  • Wenn Sie gestrippte und nicht gestrippte Versionen einer Bibliothek aufbewahren, stellen Sie sicher, dass Sie in Ihrem Code auf die richtige Version verweisen.

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

Es kann eine Diskrepanz zwischen der Anzahl der ANRs zwischen Google Play und Crashlytics geben. Dies ist aufgrund des unterschiedlichen Mechanismus zum Sammeln und Melden von ANR-Daten zu erwarten. Crashlytics meldet ANRs beim nächsten Start der App, während Android Vitals ANR-Daten sendet, nachdem die ANR auftritt.

Darüber hinaus zeigt Crashlytics nur ANRs an, die auf Geräten mit Android 11+ auftreten, im Vergleich zu Google Play, das ANRs von Geräten mit akzeptierten Google Play-Diensten und einer Einwilligung zur Datenerfassung anzeigt.

Unterschiede zwischen NDK-Stack-Traces im Crashlytics-Dashboard und Logcat

LLVM- und GNU-Toolchains haben unterschiedliche Standardwerte und Behandlungen für das schreibgeschützte Segment der Binärdateien Ihrer App, die möglicherweise inkonsistente Stacktraces in der Firebase-Konsole erzeugen. Um dies abzumildern, fügen Sie Ihrem Build-Prozess die folgenden Linker-Flags hinzu:

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

  -Wl,--no-rosegment
  

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

  -Wl,--rosegment
  

Wenn Sie immer noch Stack-Trace-Inkonsistenzen sehen (oder wenn keines der Flags für Ihre Toolchain relevant ist), versuchen Sie stattdessen, Folgendes zu Ihrem Build-Prozess hinzuzufügen:

-fno-omit-frame-pointer

Wie verwende ich meine eigene Breakpad-Symboldateigenerator-Binärdatei für NDK?

Das Crashlytics-Plugin bündelt einen angepassten Generator für Breakpad-Symboldateien . Wenn Sie es vorziehen, Ihre eigene Binärdatei zum Generieren von Breakpad-Symboldateien zu verwenden (z. B. wenn Sie es vorziehen, alle nativen ausführbaren Dateien in Ihrer Build-Kette aus der Quelle zu erstellen), verwenden Sie die optionale symbolGeneratorBinary Erweiterungseigenschaft, um den Pfad zur ausführbaren Datei anzugeben.

Sie können den Pfad zur Binärdatei des Breakpad-Symboldateigenerators auf zwei Arten angeben:

• Option 1 : Geben Sie den Pfad über die firebaseCrashlytics -Erweiterung in Ihrer build.gradle Datei an

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

  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 : Geben Sie den Pfad über eine Eigenschaftszeile in Ihrer Gradle-Eigenschaftendatei an

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

  Sie können Ihre Gradle-Eigenschaftendatei manuell aktualisieren oder die Datei über die Befehlszeile aktualisieren. Um beispielsweise den Pfad über die Befehlszeile anzugeben, verwenden Sie einen Befehl wie den folgenden:

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

Keine Abstürze mit Dexguard

Wenn Sie die folgende Ausnahme sehen, 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 zum Absturz Ihrer App, verhindert jedoch das Senden von Absturzberichten. Um dies zu beheben:

1. Stellen Sie sicher, dass Sie die neueste Version von DexGuard 8.x verwenden. Die neueste Version enthält Regeln, die für das Firebase Crashlytics SDK erforderlich sind.

2. Wenn Sie Ihre DexGuard-Version nicht ändern möchten, versuchen Sie, die folgende Zeile zu Ihren Verschleierungsregeln (in Ihrer DexGuard-Konfigurationsdatei) hinzuzufügen:

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

Warum sehe ich Abstürze von .kt Dateien, die als .java Probleme gekennzeichnet sind?

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

Damit Crashlytics Probleme mit der richtigen Dateierweiterung generieren kann, stellen Sie sicher, dass Ihre App das folgende Setup verwendet:

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

Beachten Sie, dass Sie nach der Aktualisierung auf das oben beschriebene Setup möglicherweise neue .kt Probleme sehen, die Duplikate vorhandener .java Probleme sind. Weitere Informationen zu diesem Umstand finden Sie in den häufig gestellten Fragen .

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

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

Bis vor kurzem haben die verfügbaren Obfuscatoren die Dateierweiterung nicht offengelegt, sodass Crashlytics jedes Problem standardmäßig mit einer .java Dateierweiterung generiert hat. Ab Android Gradle 4.2.0 unterstützt R8 jedoch Dateierweiterungen.

Mit diesem Update kann Crashlytics jetzt feststellen, ob jede in der App verwendete Klasse in Kotlin geschrieben ist, und den korrekten Dateinamen in die Issue-Signatur aufnehmen. Abstürze werden jetzt korrekt .kt Dateien zugeordnet (sofern zutreffend), wenn Ihre App wie folgt eingerichtet ist:

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

Da neue Abstürze jetzt die korrekte Dateierweiterung in ihren Problemsignaturen enthalten, sehen Sie möglicherweise neue .kt Probleme, die eigentlich nur Duplikate vorhandener Probleme mit der Bezeichnung .java sind. In der Firebase-Konsole versuchen wir zu identifizieren und Ihnen mitzuteilen, ob ein neues .kt Problem ein mögliches Duplikat eines vorhandenen Problems mit der Bezeichnung .java ist.

Wie werden absturzfreie Benutzer berechnet?

Der absturzfreie Wert stellt den Prozentsatz der Benutzer dar, die mit Ihrer App interagiert haben, aber über einen bestimmten Zeitraum keinen Absturz hatten.

Hier ist die Formel zur Berechnung des Prozentsatzes der absturzfreien Benutzer. Seine Eingabewerte werden von Google Analytics bereitgestellt.

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• Wenn ein Absturz auftritt, sendet Google Analytics einen Ereignistyp app_exception und CRASHED_USERS stellt die Anzahl der Benutzer dar, die diesem Ereignistyp zugeordnet sind.

• ALL_USERS stellt die Gesamtzahl der Benutzer dar, die mit Ihrer App in dem Zeitraum interagiert haben, den Sie aus dem Dropdown-Menü oben rechts im Crashlytics-Dashboard ausgewählt haben.

Der Prozentsatz der absturzfreien Nutzer ist eine Aggregation im Laufe der Zeit , kein Durchschnitt.

Stellen Sie sich beispielsweise vor, Ihre App hat drei Benutzer. wir nennen sie Benutzer A, Benutzer B und Benutzer C. Die folgende Tabelle zeigt, welche Benutzer jeden Tag mit Ihrer App interagiert haben und welche dieser Benutzer an diesem Tag abgestürzt sind:

• Am Mittwoch beträgt der Prozentsatz Ihrer absturzfreien Benutzer 50 % (1 von 2 Benutzern war absturzfrei).
  Zwei Ihrer Benutzer haben sich am Mittwoch mit Ihrer App beschäftigt, aber nur einer von ihnen (Benutzer B) hatte keine Abstürze.

• In den letzten 2 Tagen betrug der Prozentsatz Ihrer absturzfreien Benutzer 33,3 % (1 von 3 Benutzern war absturzfrei).
  Drei Ihrer Benutzer haben sich in den letzten zwei Tagen mit Ihrer App beschäftigt, aber nur einer von ihnen (Benutzer C) hatte keine Abstürze.

• In den letzten 3 Tagen beträgt der Prozentsatz Ihrer absturzfreien Benutzer 0 % (0 von 3 Benutzern waren absturzfrei).
  Drei Ihrer Benutzer haben in den letzten drei Tagen mit Ihrer App interagiert, aber keiner von ihnen hatte keine Abstürze.

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

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

Wenn ein Projektmitglied eine Notiz postet, wird diese 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 auf die Notiz haben.

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

• Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen anzeigen und löschen und neue Notizen zu einem Problem schreiben.

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

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

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

Die App verwendet auch das Google Mobile Ads SDK, stürzt jedoch nicht ab

Wenn Ihr Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet, ist es wahrscheinlich, dass die Crash-Melder beim Registrieren von Ausnahmehandlern stören. Um das Problem zu beheben, deaktivieren Sie die Absturzberichte im Mobile Ads SDK, indem Sie disableSDKCrashReporting aufrufen.

Wo befindet sich mein BigQuery-Dataset?

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

Unterstützt Crashlytics Armeabi?

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

Was ist ein regressiertes Problem?

Ein Problem hat eine Regression erfahren, wenn Sie das Problem zuvor geschlossen haben, Crashlytics jedoch einen neuen Bericht erhält, dass das Problem erneut aufgetreten ist. Crashlytics öffnet diese rückgängig gemachten Probleme automatisch erneut, damit Sie sie entsprechend Ihrer App angehen können.

Hier ist ein Beispielszenario, das erklärt, wie Crashlytics ein Problem als Regression kategorisiert:

1. Zum allerersten Mal erhält Crashlytics einen Absturzbericht über Crash "A". Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem "A").
2. Sie beheben diesen Fehler schnell, schließen Problem „A“ und veröffentlichen dann eine neue Version Ihrer App.
3. Crashlytics erhält einen weiteren Bericht zu Problem „A“, nachdem Sie das Problem geschlossen haben.
   • Wenn der Bericht von einer App-Version stammt, von der Crashlytics wusste, als Sie das Problem geschlossen haben (was bedeutet, dass die Version einen Absturzbericht für jeden Absturz gesendet hat), dann betrachtet Crashlytics das Problem nicht als rückgängig gemacht. Das Thema bleibt geschlossen.
   • Wenn der Bericht von einer App-Version stammt, von der Crashlytics beim Schließen des Problems nichts wusste (was bedeutet, dass die Version überhaupt keinen Absturzbericht für einen Absturz gesendet hat), betrachtet Crashlytics das Problem als rückgängig gemacht und öffnet das Problem erneut .

Wenn ein Problem zurückgeht, senden wir eine Regressionserkennungswarnung und fügen dem Problem ein Regressionssignal hinzu, um Sie darüber zu informieren, dass Crashlytics das Problem erneut geöffnet hat. Wenn Sie nicht möchten, dass ein Vorgang aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie den Vorgang „stumm“, anstatt ihn zu schließen.

Warum sehe ich Regressionsprobleme für ältere App-Versionen?

Wenn ein Bericht von einer alten App-Version stammt, die überhaupt keine Absturzberichte gesendet hat, als Sie das Problem geschlossen haben, betrachtet Crashlytics das Problem als rückgängig gemacht und öffnet das Problem erneut.

Diese Situation kann in der folgenden Situation auftreten: Sie haben einen Fehler behoben und eine neue Version Ihrer App veröffentlicht, aber Sie haben immer noch Benutzer mit älteren Versionen ohne die Fehlerbehebung. Wenn eine dieser älteren Versionen zufällig überhaupt keine Absturzberichte gesendet hatte, als Sie das Problem geschlossen haben, und diese Benutzer anfangen, auf den Fehler zu stoßen, würden diese Absturzberichte ein regressiertes Problem auslösen.

Wenn Sie nicht möchten, dass ein Vorgang aufgrund unseres Regressionsalgorithmus erneut geöffnet wird, schalten Sie den Vorgang „stumm“, anstatt ihn zu schließen.