Fehlerbehebung und häufig gestellte Fragen zu Crashlytics

Auf dieser Seite finden Sie Hilfe zur Fehlerbehebung und Antworten auf häufig gestellte Fragen zur Verwendung von Crashlytics. Wenn Sie nicht finden, wonach Sie suchen, oder zusätzliche Hilfe benötigen, wenden Sie sich an den Firebase-Support.

Auf dieser Seite finden Sie Informationen zu folgenden Themen:

• Allgemeine Fehlerbehebung, einschließlich Fragen zur Anzeige von Daten oder zur Arbeit mit Daten in der Firebase-Konsole und Fragen zu zurückgefallenen Problemen.

• Plattformspezifischer Support, einschließlich Fragen zu Apple-Plattformen, Android, Web und Unity.

• Support für Integrationen, einschließlich Fragen zu BigQuery.

Allgemeine Fehlerbehebung/FAQs

In der Tabelle Probleme werden für einige Probleme unterschiedliche Formate (und manchmal „Varianten“) angezeigt.

In der Tabelle Probleme in der Firebase-Konsole werden Probleme möglicherweise in zwei verschiedenen Formaten aufgeführt. Möglicherweise wird bei einigen Problemen auch eine Funktion namens „Varianten“ angezeigt. Das hat folgende Gründe:

Anfang 2023 haben wir eine verbesserte Analyse-Engine für die Gruppierung von Ereignissen sowie ein aktualisiertes Design und einige erweiterte Funktionen für neue Probleme (z. B. Varianten) eingeführt. Alle Details finden Sie in unserem aktuellen Blogpost. Die wichtigsten Informationen haben wir unten für Sie zusammengefasst.

Crashlytics analysiert alle Ereignisse in Ihrer App (z. B. Abstürze, nicht schwerwiegende 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 diese Probleme zu gruppieren, berücksichtigt die verbesserte Analyse-Engine jetzt viele Aspekte des Ereignisses, einschließlich der Frames im Stacktrace, der Ausnahmemeldung, des Fehlercodes und anderer Plattform- oder Fehlertypmerkmale.

Innerhalb dieser Gruppe von Ereignissen können sich die Stacktraces, die zu dem 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 innerhalb eines Problems beheben und feststellen, ob verschiedene Ursachen zum Fehler führen.

Das sind die Vorteile dieser Verbesserungen:

• Überarbeitete Metadaten in der Problemzeile
  Probleme in Ihrer App lassen sich jetzt leichter verstehen 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 Fehler in den häufigsten Stacktraces innerhalb eines Problems beheben.

• Aussagekräftigere Benachrichtigungen und Signale
  Ein neues Problem ist tatsächlich ein neuer Fehler.

• Leistungsstärkere Suche
  Jedes Problem enthält mehr suchbare Metadaten, z. B. Ausnahmetyp und Paketname.

Die Verbesserungen werden folgendermaßen eingeführt:

• Wenn wir neue Ereignisse aus Ihrer App erhalten, prüfen wir, ob sie mit einem vorhandenen Problem übereinstimmen.

• Wenn es keine Übereinstimmung gibt, wenden wir automatisch unseren intelligenteren Algorithmus für die Ereignisgruppierung auf das Ereignis an und erstellen ein neues Problem mit dem überarbeiteten Metadatendesign.

Dies ist das erste große Update für unsere Ereignisgruppierung. Wenn Sie Feedback haben oder Probleme auftreten, können Sie uns dies durch Einreichen eines Berichts mitteilen.

Navigationspfad-Logs werden nicht angezeigt

Wenn Sie keine Navigationspfad-Logs sehen (iOS+ | Android | Flutter | Unity), sollten Sie die Konfiguration Ihrer App für Google Analytics prüfen. Sie müssen die folgenden Anforderungen erfüllen:

• Sie haben Google Analytics in Ihrem Firebase-Projekt aktiviert.

• Sie haben die Datenweitergabe für Google Analytics aktiviert. Weitere Informationen zu dieser Einstellung finden Sie unter Einstellungen für die Freigabe von Analytics-Daten verwalten.

• Sie haben das Firebase SDK für Google Analytics zu Ihrer App hinzugefügt: iOS+ | Android | Flutter | Unity.
  Dieses SDK muss zusätzlich zum Crashlytics SDK hinzugefügt werden.

• Sie verwenden die neuesten Firebase SDK-Versionen für alle Produkte, die Sie in Ihrer App verwenden (iOS+ | Android | Flutter | Unity).

  Prüfen Sie bei Apple-Plattformen und Android-Apps insbesondere, ob Sie mindestens die folgende Version des Firebase SDK für Google Analytics verwenden: iOS+ – Version 6.3.1 oder höher (Version 8.9.0 oder höher für macOS und tvOS) | Android – Version 17.2.3 oder höher (BoM Version 24.7.1 oder höher).

Geschwindigkeitswarnungen werden nicht angezeigt

Wenn Sie keine Geschwindigkeitswarnungen sehen, prüfen Sie, ob Sie die folgenden Versionen verwenden:

Ich erhalte keine Crashlytics-Benachrichtigungen (Berechtigungen)

Damit Projektmitglieder Crashlytics-Benachrichtigungen erhalten oder konfigurieren können, müssen sie die erforderlichen IAM-Berechtigungen haben. Sie können die Benachrichtigungseinstellungen in der Firebase Console auf der Seite Einstellungen > Benachrichtigungen verwalten und die Benachrichtigungseinstellungen für Ihr Konto festlegen.

Hinweis: E‑Mail-Benachrichtigungen werden nur an einzelne E‑Mail-Adressen gesendet (nicht an Google Groups- oder Google Workspace-Konten). Sie können Benachrichtigungen für Ihr eigenes Konto aktivieren oder deaktivieren, ohne dass sich dies auf andere Projektmitglieder auswirkt.

In der folgenden Tabelle sind die erforderlichen Berechtigungen und die vordefinierten Rollen aufgeführt, die diese Berechtigungen standardmäßig enthalten:

Funktion	Erforderliche Berechtigung zum Erhalt von Benachrichtigungen	Rollen, die die erforderliche Berechtigung standardmäßig enthalten
Crashlytics – Benachrichtigungen in der mobilen App	firebase.projects.update	Inhaber Bearbeiter Firebase-Administrator
Crashlytics – Benachrichtigungen in der Web-App	monitoring.alertPolicies.create monitoring.alertPolicies.update monitoring.notificationChannels.create	Inhaber Bearbeiter Monitoring-Editor

Weitere Informationen zum Konfigurieren von Benachrichtigungen finden Sie unter Crashlytics-Benachrichtigungen konfigurieren und empfangen. Weitere Informationen zu IAM-Rollen und -Berechtigungen finden Sie unter Berechtigungen und Zugriff auf Firebase.

Messwerte ohne Abstürze werden nicht angezeigt (oder unzuverlässige Messwerte werden angezeigt)

Wenn Sie keine Messwerte für absturzfreie Nutzer und Sitzungen oder unzuverlässige Messwerte sehen, prüfen Sie Folgendes:

• Achten Sie darauf, dass Sie die folgenden Versionen verwenden:

• Achten Sie darauf, dass die Einstellungen für die Datenerhebung die Qualität der Messwerte zu Nutzern ohne Abstürze nicht beeinträchtigen:

  • Wenn Sie die Berichterstellung mit Einwilligung aktivieren, indem Sie die automatische Absturzberichterstellung deaktivieren, können Absturzinformationen nur von Nutzern an Crashlytics gesendet werden, die der Datenerhebung ausdrücklich zugestimmt haben. Dies wirkt sich auf die Genauigkeit der Messwerte zu absturzfreien Sitzungen aus, da Crashlytics nur Absturzinformationen von diesen Nutzern (und nicht von allen Nutzern) hat. Das bedeutet, dass die Messwerte zu Nutzern ohne Abstürze möglicherweise weniger zuverlässig sind und die Gesamtstabilität Ihrer App weniger gut widerspiegeln.

  • Wenn Sie die automatische Datenerhebung deaktiviert haben, können Sie mit sendUnsentReports auf dem Gerät im Cache gespeicherte Berichte an Crashlytics senden. Bei dieser Methode werden Absturzdaten an Crashlytics gesendet, aber keine Sitzungsdaten. Dadurch werden in den Console-Diagrammen niedrige oder Nullwerte für absturzfreie Messwerte angezeigt.

Wie wird der Anteil der nicht von einem Absturz betroffenen Nutzer berechnet?

Weitere Informationen finden Sie unter Messwerte ohne Abstürze.

Wer kann Notizen zu einem Problem ansehen, schreiben 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 auf die Notiz haben.

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

• Projektmitglieder mit einer der folgenden Rollen können vorhandene Notizen aufrufen und löschen sowie 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 aufrufen, aber keine Notiz löschen oder schreiben.

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

Was ist ein Problem mit Regression?

Eine Regression liegt vor, wenn Sie ein Problem zuvor geschlossen haben, Crashlytics aber einen neuen Bericht erhält, dass das Problem wieder aufgetreten ist. Crashlytics öffnet diese Probleme automatisch wieder, damit Sie sie entsprechend Ihrer App beheben können.

Hier ist ein Beispielszenario, in dem erklärt wird, wie Crashlytics ein Problem als Regression kategorisiert:

1. Crashlytics erhält zum ersten Mal einen Absturzbericht zu Absturz A. Crashlytics öffnet ein entsprechendes Problem für diesen Absturz (Problem „A“).
2. Du behebst diesen Fehler schnell, schließt Problem „A“ und veröffentlichst dann eine neue Version deiner 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, die Crashlytics bekannt war, als Sie das Problem geschlossen haben (d. h., die Version hat einen Absturzbericht für irgendeinen Absturz gesendet), betrachtet Crashlytics das Problem nicht als Regression. Das Problem bleibt geschlossen.
   • Wenn der Bericht von einer App-Version stammt, die Crashlytics nicht bekannt war, als Sie das Problem geschlossen haben (d. h., die Version hatte noch nie einen Absturzbericht für einen Absturz gesendet), betrachtet Crashlytics das Problem als Regression und öffnet es wieder.

Hinweis: Vor Februar 2022 hat Crashlytics ein Problem als Regression kategorisiert, wenn es in irgendeiner 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 fälschlicherweise Regressionen identifizierte. Wir verwenden jetzt die oben beschriebene Konvention.

Wenn ein Problem erneut 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, „ignorieren“ Sie das Problem, anstatt es zu schließen.

Warum sehe ich Probleme, die in älteren App-Versionen wieder aufgetreten sind?

Wenn ein Bericht von einer alten App-Version stammt, die beim Schließen des Problems noch keine Absturzberichte gesendet hatte, wird das Problem von Crashlytics als wieder aufgetreten eingestuft und erneut geöffnet.

Das kann passieren, wenn Sie einen Fehler behoben und eine neue Version Ihrer App veröffentlicht haben, aber noch Nutzer mit früheren Versionen ohne die Fehlerkorrektur vorhanden sind. Wenn eine dieser früheren Versionen nie Absturzberichte gesendet hat, als Sie das Problem geschlossen haben, und diese Nutzer auf den Fehler stoßen, lösen diese Absturzberichte ein Problem mit Regression aus.

Wenn Sie nicht möchten, dass ein Problem aufgrund unseres Regressionsalgorithmus wieder geöffnet wird, „ignorieren“ Sie das Problem, anstatt es zu schließen.

Hinweis: Vor Februar 2022 hat Crashlytics ein Problem als Regression kategorisiert, wenn es in einer beliebigen App-Version erneut aufgetreten ist, auch in App-Versionen, die uns bekannt waren, als Sie das Problem geschlossen haben. Dies führte dazu, dass Crashlytics manchmal fälschlicherweise Regressionen identifizierte. Wir verwenden jetzt die oben beschriebene Konvention.

Wenn Sie viele falsch identifizierte Regressionen von vor Februar 2022 sehen, können Sie sie wieder schließen, um zu verhindern, dass sie wieder geöffnet werden.

---

Plattformspezifischer Support

In den folgenden Abschnitten finden Sie Unterstützung für die plattformspezifische Fehlerbehebung und FAQs: iOS+ | Android | Web | Unity.

Unterstützung für Apple-Plattformen

dSYM-Dateien fehlen oder werden nicht hochgeladen

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

1. Achten Sie darauf, dass die Build-Phase Ihres Projekts das Ausführungsskript Crashlytics enthält, mit dem Xcode die dSYMs Ihres Projekts während des Builds hochladen kann. Eine Anleitung zum Hinzufügen des Skripts 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 Meldung „Missing dSYM“ (dSYM fehlt) angezeigt wird, prüfen Sie in Xcode, ob dSYMs für den Build ordnungsgemäß erstellt werden.

3. Wenn Xcode dSYMs korrekt erstellt und Sie trotzdem fehlende dSYMs sehen, bleibt das Run-Script-Tool wahrscheinlich beim Hochladen der dSYMs hängen. Versuchen Sie in diesem Fall Folgendes:

   • Achten Sie darauf, dass Sie die aktuelle 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-Skript, um die fehlenden dSYM-Dateien für die angegebenen UUIDs auf dem Tab dSYMs hochzuladen.

4. Wenn weiterhin dSYMs fehlen oder Uploads immer noch fehlschlagen, wenden Sie sich an den Firebase-Support und fügen Sie Ihre Protokolle bei.

Abstürze werden schlecht symbolisch dargestellt

Wenn Ihre Stacktraces schlecht symbolisch dargestellt werden, prüfen Sie Folgendes:

• Wenn Frames aus der Bibliothek Ihrer App keine Verweise auf den Code Ihrer App enthalten, achten Sie darauf, dass -fomit-frame-pointer nicht als Kompilierungs-Flag festgelegt ist.

• Wenn du mehrere (Missing)-Frames für die Bibliothek deiner App siehst, prüfe, ob auf dem Tab Crashlytics dSYMs der Firebase-Konsole optionale dSYMs als fehlend aufgeführt sind (für die betroffene App-Version). Wenn ja, folgen Sie dem Schritt zur Fehlerbehebung „Benachrichtigung über fehlende dSYM-Datei“ in den FAQs zu fehlenden/nicht hochgeladenen dSYM-Dateien auf dieser Seite. Beachten Sie, dass durch das Hochladen dieser dSYMs Abstürze, die bereits aufgetreten sind, nicht symbolisiert werden. Dies hilft jedoch, die Symbolisierung für zukünftige Abstürze sicherzustellen.

Kann ich Crashlytics für macOS oder tvOS verwenden?

Ja, Sie können Crashlytics in macOS- und tvOS-Projekten implementieren. Achten Sie darauf, dass Sie Version 8.9.0 oder höher des Firebase SDK für Google Analytics verwenden, damit bei Abstürzen auf die von Google Analytics erfassten Messwerte zugegriffen werden kann (Nutzer ohne Abstürze, neuester Release, Benachrichtigungen zur Geschwindigkeit und Navigationspfad-Logs).

Kann ich Crashlytics in einem Firebase-Projekt mit mehreren Apps auf verschiedenen Apple-Plattformen verwenden?

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) entwickelt wurden. Bisher mussten Sie die Apps in einzelne Firebase-Projekte aufteilen, wenn sie dieselbe Paket-ID hatten.

---

Android-Support

Warum werden ANR-Fehler nur für Android 11 und höher 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 Erfassen von ANRs verwenden (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.

Warum fehlen bei einigen ANRs die BuildIds?

Wenn bei einigen Ihrer ANRs die BuildIds fehlen, können Sie das Problem so beheben:

• Achten Sie darauf, dass Sie eine 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, Gradle-Plug-in oder beides. Damit BuildIds für diese ANRs richtig erfasst werden, müssen Sie die folgenden Versionen verwenden:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle-Plug-in, Version 2.9.4 oder höher

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

  Wenn nurBuildIds für die gemeinsam genutzten Bibliotheken deiner App fehlen, verwendest du wahrscheinlich nicht den standardmäßigen Speicherort für gemeinsam genutzte Bibliotheken. In diesem Fall kann Crashlytics die zugehörigen BuildIds möglicherweise nicht finden. Wir empfehlen, den Standardspeicherort für gemeinsam genutzte Bibliotheken zu verwenden.

• Achten Sie darauf, dass BuildIds während des Build-Prozesses nicht entfernt werden.

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

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

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

  • Wenn du sowohl die bereinigte als auch die unbereinigte Version einer Bibliothek behältst, musst du darauf achten, dass du in deinem Code auf die richtige Version verweist.

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

Die Anzahl der ANR-Fehler kann zwischen Google Play und Crashlytics abweichen. Dies ist aufgrund der unterschiedlichen Mechanismen zur Erfassung und Meldung von ANR-Daten zu erwarten. Crashlytics meldet ANRs beim nächsten Start der App, während Android Vitals ANR-Daten sendet, nachdem der ANR aufgetreten ist.

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

Warum werden Abstürze aus .kt-Dateien als .java-Probleme gekennzeichnet?

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

Damit Crashlytics Probleme mit der richtigen Dateiendung generieren kann, muss Ihre Anwendung so eingerichtet sein:

• Android Gradle 4.2.0 oder höher wird verwendet.
• Verwendet R8 mit aktivierter Verschleierung. In dieser Dokumentation wird beschrieben, wie Sie Ihre App auf R8 aktualisieren.

Nach der Aktualisierung auf die oben beschriebene Einrichtung werden möglicherweise neue .kt-Probleme angezeigt, die Duplikate vorhandener .java-Probleme sind. Weitere Informationen zu diesem Umstand finden Sie in den FAQs.

Warum werden mir .kt-Probleme angezeigt, 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 Obfuskierungstools die Dateiendung nicht offengelegt. Daher hat Crashlytics jedes Problem standardmäßig mit der Dateiendung .java generiert. Seit 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 korrekt .kt-Dateien zugeordnet (sofern zutreffend), wenn Ihre App die folgende Einrichtung hat:

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

Da neue Abstürze jetzt die richtige Dateiendung in ihren Problemsignaturen enthalten, werden möglicherweise neue .kt-Probleme angezeigt, die eigentlich nur Duplikate vorhandener Probleme mit der Bezeichnung .java sind. In der Firebase-Konsole versuchen wir, zu erkennen und Ihnen mitzuteilen, ob ein neues .kt-Problem möglicherweise ein Duplikat eines vorhandenen Problems mit dem Label .java ist.

Keine Abstürze mit Dexguard

Wenn die folgende Ausnahme auftritt, 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 aber, dass sie Absturzberichte sendet. So lösen Sie das Problem:

1. Achten Sie darauf, dass Sie die aktuelle DexGuard 8.x-Version verwenden. Die aktuelle Version enthält Regeln, die für das Firebase Crashlytics SDK erforderlich sind.

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

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

Wie führe ich ein Upgrade auf das Crashlytics-Gradle-Plug-in, Version 3, durch?

Die neueste Version des Crashlytics-Gradle-Plug-ins ist eine Hauptversion (v3.0.0) und modernisiert das SDK, indem die Unterstützung für ältere Versionen von Gradle und dem Android-Gradle-Plug-in eingestellt wird. Außerdem werden mit den Änderungen in diesem Release Probleme mit dem Android-Gradle-Plug-in ab Version 8.1 behoben und die Unterstützung für systemeigene Apps und benutzerdefinierte Builds verbessert.

Mindestanforderungen

Für das Crashlytics-Gradle-Plug-in v3 gelten die folgenden Mindestanforderungen:

• Android-Gradle-Plug-in 8.1 oder höher
  Aktualisieren Sie dieses Plug-in mit dem Android-Gradle-Plug-in-Upgrade-Assistenten in der aktuellen Version von Android Studio.

• google-services-Gradle-Plug-in von Firebase, Version 4.4.1 oder höher
  Aktualisieren Sie dieses Plug-in, indem Sie die aktuelle Version in der Gradle-Build-Datei Ihres Projekts angeben, z. B. so:

Kotlin

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.5.0" apply false
  ...
}

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' apply false
  ...
}

Änderungen an der Erweiterung „Crashlytics“

In Version 3 des Crashlytics-Gradle-Plug-ins gibt es die folgenden funktionsgefährdenden Änderungen an der Crashlytics-Erweiterung:

• Die Erweiterung wurde aus dem Android-Block defaultConfig entfernt. Stattdessen sollten Sie jede Variante konfigurieren.

• Das verworfene Feld mappingFile wurde entfernt. Stattdessen wird die zusammengeführte Zuordnungsdatei jetzt automatisch bereitgestellt.

• Das verworfene Feld strippedNativeLibsDir wurde entfernt. Verwenden Sie stattdessen unstrippedNativeLibsDir für alle nativen Bibliotheken.

• Das Feld unstrippedNativeLibsDir wurde in kumulativ geändert.

  Beispiel mit mehreren Verzeichnissen ansehen

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  Mit der Aufgabe uploadCrashlyticsSymbolFilesBasicRelease werden nur die Symbole in MY/NATIVE/LIBS hochgeladen, mit uploadCrashlyticsSymbolFilesFeatureXRelease werden jedoch Symbole in MY/NATIVE/LIBS und MY/FEATURE_X/LIBS hochgeladen.

• Das Feld symbolGenerator für die Schließung wurde durch zwei neue Felder auf oberster Ebene ersetzt:

  • symbolGeneratorType, ein String mit entweder "breakpad" (Standard) oder "csym".
  • breakpadBinary, eine Datei mit einer lokalen binären dump_syms-Überschreibung.

Beispiel für das Upgrade der Erweiterung

Kotlin

Vorher	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } }
Jetzt in v3	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Groovy

Vorher	buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
Jetzt in v3	buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Android-NDK-spezifischer Support

Unterschiede zwischen NDK-Stacktraces im Crashlytics-Dashboard und Logcat

LLVM- und GNU-Toolchains haben unterschiedliche Standardeinstellungen und Behandlungen für das schreibgeschützte Segment der Binärdateien Ihrer App, was zu inkonsistenten Stacktraces in der Firebase-Konsole führen kann. Fügen Sie Ihrem Build-Prozess die folgenden Linker-Flags hinzu, um dieses Problem zu beheben:

• Wenn Sie den Linker lld 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 Sie weiterhin Inkonsistenzen im Stacktrace sehen oder keines der Flags für Ihre Toolchain relevant ist, fügen Sie stattdessen Folgendes zu Ihrem Build-Prozess hinzu:

-fno-omit-frame-pointer

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

Das Crashlytics-Plug-in enthält einen angepassten Breakpad-Symboldateigenerator. Wenn Sie lieber Ihre eigene Binärdatei zum Generieren von Breakpad-Symboldateien 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: Für Android-Binärdateien ist die Linux-Version des Breakpad-Symbol-Dateigenerators erforderlich.

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

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

  Fügen Sie der Datei build.gradle.kts auf Anwendungsebene Folgendes hinzu:

  Gradle-Plug-in v3.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: Geben Sie den Pfad über eine Attributzeile in Ihrer Gradle-Attributdatei an.

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

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

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

Unterstützt Crashlytics armeabi?

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

---

Web support

Fehler „Component crashlytics has not been registered yet“ wird angezeigt

Wenn Sie das @firebase/crashlytics-Paket verwenden, sollten Sie in Ihren Importen keine modularen Namespaces mischen. Wenn Sie initializeApp aus firebase/app importieren und gleichzeitig getCrashlytics aus @firebase/crashlytics, laden Bundler zwei separate interne Registries. Das führt zu Fehlern wie Component crashlytics has not been registered yet.

So vermeiden Sie Konflikte bei der Registrierung von Dual-Packages:

1. Standardisieren Sie alle Firebase-Importe in Ihrem Projekt, um den Namespace @firebase/ zu verwenden (z. B. @firebase/app und @firebase/crashlytics).

2. Wenn Ihre App Vite verwendet, müssen Sie @firebase/app in der Datei vite.config.ts explizit deduplizieren:

   // vite.config.ts
   import { defineConfig } from 'vite';
   
   export default defineConfig({
     resolve: {
       dedupe: ['@firebase/app']
     }
   });
   

TypeScript-Kompilierungsfehler bei aktiviertem verbatimModuleSyntax

In modernen TypeScript-Konfigurationen (z. B. Vite- und Angular-Vorlagen) ist "verbatimModuleSyntax": true in tsconfig.json oft aktiviert. Wenn dieses Flag aktiviert ist, wird beim Importieren einer TypeScript-Schnittstelle mit einem Standardwertimport ein Kompilierungsfehler ausgegeben.

Verwenden Sie explizite type-Importe, wenn Sie TypeScript-Schnittstellen wie FirebaseApp oder Crashlytics importieren:

import { initializeApp, type FirebaseApp } from '@firebase/app';
import { getCrashlytics, type Crashlytics } from '@firebase/crashlytics';

---

Unity-Unterstützung

Nicht symbolisierte Stacktraces für Android-Apps im Crashlytics-Dashboard sehen

Wenn Sie Unity IL2CPP verwenden und nicht symbolisierte Stacktraces angezeigt werden, versuchen Sie Folgendes:

1. Sie müssen Version 8.6.1 oder höher des Crashlytics Unity SDK verwenden.

2. Achten Sie darauf, dass Sie die Firebase-Befehlszeile eingerichtet haben und den Befehl crashlytics:symbols:upload ausführen, um Ihre Symboldatei zu generieren und hochzuladen.

   Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen anderen Build erstellen, für den Sie symbolisierte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen findest du unter Lesbare Absturzberichte erhalten.

Kann Crashlytics mit Apps verwendet werden, die IL2CPP nutzen?

Ja, Crashlytics kann symbolisierte Stacktraces für Ihre Apps anzeigen, die IL2CPP verwenden. Diese Funktion ist für Apps verfügbar, die auf Android- oder Apple-Plattformen veröffentlicht wurden. So gehts:

1. Sie müssen Version 8.6.0 oder höher des Crashlytics Unity SDK verwenden.

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

   • Für Apple-Plattform-Apps: Es sind keine besonderen Maßnahmen erforderlich. Bei Apple-Plattform-Apps konfiguriert das Firebase Unity Editor-Plug-in Ihr Xcode-Projekt automatisch so, dass Symbole hochgeladen werden.

   • Für Android-Apps: Achten Sie darauf, dass Sie für die Ausführung des Firebase-Befehlszeilenbefehls crashlytics:symbols:upload eingerichtet sind, um Ihre Symboldatei zu generieren und hochzuladen.

     Sie müssen diesen CLI-Befehl jedes Mal ausführen, wenn Sie einen Release-Build oder einen anderen Build erstellen, für den Sie symbolisierte Stacktraces in der Firebase-Konsole sehen möchten. Weitere Informationen findest du unter Lesbare Absturzberichte erhalten.

Nicht erfasste Ausnahmen als schwerwiegende Ereignisse melden

Crashlytics kann nicht erfasste Ausnahmen als schwerwiegende Fehler melden (ab v10.4.0 des Unity SDK). In den folgenden FAQs werden die Gründe für die Verwendung dieser Funktion und die Best Practices dafür erläutert.

Warum sollten nicht erfasste Ausnahmen in einer App als schwerwiegende Fehler gemeldet werden?

Wenn du nicht abgefangene Ausnahmen als schwerwiegende Fehler meldest, erhältst du einen realistischeren Hinweis darauf, welche Ausnahmen dazu führen können, dass das Spiel nicht mehr spielbar ist – auch wenn die App weiterhin ausgeführt wird.

Wenn Sie mit dem Melden schwerwiegender Fehler beginnen, sinkt wahrscheinlich der Prozentsatz der absturzfreien Nutzer (CFU). Der CFU-Messwert ist dann jedoch repräsentativer für die Erfahrungen der Endnutzer mit Ihrer App.

Wichtig: Das Melden nicht abgefangener Ausnahmen als schwerwiegende Fehler hat keine Auswirkungen auf Ihre Android Vitals. Die in Crashlytics gemeldeten schwerwiegenden Fehler sind nur für dich sichtbar, damit du Probleme in deinen Apps und Spielen finden und beheben kannst.

Welche Ausnahmen werden als schwerwiegende Fehler gemeldet?

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

• Während der Initialisierung in Ihrer App muss das Attribut ReportUncaughtExceptionsAsFatal auf true gesetzt werden.

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

Nachdem ich die Meldung nicht erfasster Ausnahmen als schwerwiegende Fehler aktiviert habe, habe ich jetzt viele neue schwerwiegende Fehler. Wie gehe ich mit diesen Ausnahmen richtig um?

Wenn Sie Berichte zu nicht abgefangenen Ausnahmen als schwerwiegende Fehler erhalten, haben Sie folgende Möglichkeiten, diese nicht abgefangenen Ausnahmen zu behandeln:

• Überlegen Sie, wie Sie diese nicht abgefangenen Ausnahmen abfangen und verarbeiten können.
• Verschiedene Optionen zum Protokollieren von Ausnahmen in der Unity-Debugging-Konsole und in Crashlytics in Betracht ziehen.

Ausgelöste Ausnahmen abfangen und verarbeiten

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

Es empfiehlt sich, alle vorhersehbaren Ausnahmen abzufangen und zu behandeln, es sei denn, das Programm kann nicht in einen bekannten Zustand zurückversetzt werden.

Wenn Sie steuern möchten, welche Arten von Ausnahmen von welchem Code abgefangen und verarbeitet werden, schließen Sie Code, der eine Ausnahme generieren könnte, in einen try-catch-Block ein. Achten Sie darauf, dass die Bedingungen in den catch-Anweisungen so eng wie möglich gefasst sind, damit die spezifischen Ausnahmen angemessen behandelt werden.

Ausnahmen in Unity oder Crashlytics protokollieren

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

Wenn Sie Crashlytics verwenden, sind dies die beiden gängigsten und empfohlenen Optionen:

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

  • Geben Sie die Ausnahme in der Unity-Konsole mit Debug.Log(exception), Debug.LogWarning(exception) und Debug.LogError(exception) aus. Dadurch wird der Inhalt der Ausnahme in der Unity-Konsole ausgegeben und die Ausnahme wird nicht noch einmal ausgelöst.

• Option 2: In den folgenden Situationen 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 debuggen, verwenden Sie Crashlytics.Log(exception.ToString()).
  • Wenn eine Ausnahme trotz Abfangen und Behandeln an Crashlytics gemeldet werden soll, verwenden Sie Crashlytics.LogException(exception), um sie als nicht schwerwiegendes Ereignis zu protokollieren.

Wenn Sie ein schwerwiegendes Ereignis manuell an Unity Cloud Diagnostics melden möchten, können Sie Debug.LogException verwenden. Bei dieser Option wird die Ausnahme wie bei Option 1 in der Unity-Konsole ausgegeben, aber es wird auch die Ausnahme ausgelöst (unabhängig davon, ob sie bereits ausgelöst oder abgefangen wurde). Der Fehler wird nicht lokal ausgegeben. Das bedeutet, dass selbst ein umgebender Debug.LogException(exception) mit try-catch-Blöcken zu einer nicht abgefangenen Ausnahme führt.

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

• Um die Ausnahme in der Unity-Konsole auszugeben.
• Um die Ausnahme als schwerwiegendes Ereignis in Crashlytics hochzuladen.
• Wenn Sie die Ausnahme auslösen möchten, lassen Sie sie als nicht abgefangene Ausnahme behandeln und an Unity Cloud Diagnostics melden.

Wenn Sie eine abgefangene Ausnahme in der Unity-Konsole ausgeben und als nicht schwerwiegendes 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
    //
}

---

Unterstützung bei der Integration

Die App verwendet auch das Google Mobile Ads SDK, es kommt jedoch nicht zu Abstürzen.

Wenn Ihr Projekt Crashlytics zusammen mit dem Google Mobile Ads SDK verwendet, ist es wahrscheinlich, dass die Absturzberichterstatter bei der Registrierung von Ausnahme-Handlern interferieren. Um das Problem zu beheben, deaktivieren Sie die Absturzberichte im Mobile Ads SDK, indem Sie disableSDKCrashReporting aufrufen.

Wo befindet sich mein BigQuery-Dataset?

Firebase exportiert Daten an den Dataset-Speicherort, den Sie beim Einrichten des Datenexports nach BigQuery ausgewählt haben.

• Dieser Speicherort gilt sowohl für das Crashlytics-Dataset als auch für das Firebase-Sitzungs-Dataset (wenn der Export von Sitzungsdaten aktiviert ist).

• Dieser Standort gilt nur für die nach BigQuery exportierten Daten und hat keine Auswirkungen auf den Standort der Daten, die für die Verwendung im Crashlytics-Dashboard der Firebase-Konsole oder in Android Studio gespeichert werden.

• Nachdem ein Dataset erstellt wurde, kann der Standort nicht mehr geändert werden. Sie können aber das Dataset an einen anderen Standort kopieren oder es manuell verschieben, d. h. an einem anderen Standort neu erstellen. Weitere Informationen finden Sie unter Speicherort für vorhandene Exporte ändern.

Probleme nach dem Upgrade auf die neue Exportinfrastruktur für BigQuery?

Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Batch-Export von Crashlytics-Daten nach BigQuery eingeführt.

Alle Firebase-Projekte wurden am 2. März 2026 automatisch auf die neue Infrastruktur für den Batchexport umgestellt.

Hinweis: Dieses Infrastruktur-Upgrade gilt nur für Crashlytics-Batch-Absturzexporte und nicht für Sitzungen oder Streaming-Exporte.

Wichtige Unterschiede zwischen der alten und der neuen Exportinfrastruktur

• Die neue Infrastruktur unterstützt Crashlytics Dataset-Standorte außerhalb der USA.

  • Export vor Mitte Oktober 2024 aktiviert und auf die neue Exportinfrastruktur aktualisiert: Sie können jetzt optional den Speicherort für den Datenexport ändern.

  • Export Mitte Oktober 2024 oder später aktiviert: Sie wurden während der Einrichtung aufgefordert, einen Speicherort für den Datenexport auszuwählen.

• Die neue Infrastruktur unterstützt keine Backfills von Daten, die vor der Aktivierung des Exports erstellt wurden.

  • Die alte Infrastruktur unterstützte Backfills bis zu 30 Tage vor dem Datum, an dem Sie den Export aktiviert haben.

  • Die neue Infrastruktur unterstützt Backfills für die letzten 30 Tage oder für das letzte Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was aktueller ist).

• In der neuen Infrastruktur werden BigQuery-Batchtabellen mit den Kennungen benannt, die für Ihre Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

  • In der alten Infrastruktur wurden Daten in Batchtabellen geschrieben, deren Namen auf den Paket-IDs oder Paketnamen in der Binärdatei Ihrer App basierten.

  • In der neuen Infrastruktur werden Daten in Batchtabellen geschrieben, deren Namen auf den Paket-IDs oder Paketnamen basieren, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

Wenn der Name Ihrer alten Batchtabelle nicht mit Ihrer Firebase-App-ID übereinstimmt

Wenn der Name Ihrer alten Batchtabelle nicht mit der Paket-ID oder dem Paketnamen übereinstimmt, der für Ihre registrierte Firebase-App festgelegt ist, implementieren Sie eine der folgenden Optionen, um weitere Unterbrechungen Ihrer exportierten Batchdaten zu vermeiden.

Verstehen, wie die Exportinfrastruktur Kennungen verwendet, um Daten in BigQuery-Tabellen zu schreiben

So schreiben die beiden Exportinfrastrukturen Crashlytics-Daten in BigQuery-Batchtabellen:

• Legacy-Exportinfrastruktur: Daten wurden in eine Tabelle geschrieben, deren Name auf der Paket-ID oder dem Paketnamen in der Binärdatei Ihrer App basiert.

• Neue Exportinfrastruktur: Daten werden in eine Tabelle geschrieben, deren Name auf der Paket-ID oder dem Paketnamen basiert, der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt ist.

Leider stimmt die Paket-ID oder der Paketname in der Binärdatei Ihrer App manchmal nicht mit der Paket-ID oder dem Paketnamen überein, der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt ist. Das passiert in der Regel, wenn bei der App-Registrierung nicht die tatsächliche Kennung eingegeben wurde.

Was passiert, wenn das Problem vor der Umstellung nicht behoben wurde?

Wenn die Kennungen an diesen beiden Stellen nicht übereinstimmen, ist Folgendes passiert:

• Ihre Crashlytics-Daten werden jetzt in eine neue BigQuery-Batchtabelle geschrieben. Das ist eine neue Tabelle mit einem Namen, der auf der Paket-ID oder dem Paketnamen basiert, der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt ist.

• In vorhandene „Legacy“-Tabellen, deren Name auf der Kennung in der Binärdatei Ihrer App basiert, werden keine Daten mehr geschrieben.

Beispielszenarien für nicht übereinstimmende Kennzeichnungen

Beachten Sie, dass an die Namen der BigQuery-Batchtabellen automatisch _IOS oder _ANDROID angehängt wird, um die Plattform der App anzugeben.

Kennung(en) in der Binärdatei Ihrer App	Für Ihre Firebase-App(s) festgelegte Kennung(en)	Legacy-Verhalten	Verhalten nach dem Upgrade auf die neue Exportinfrastruktur	Lösung
foo	bar	Schreibt in eine einzelne Tabelle, die nach der Kennung in der Binärdatei der App (foo) benannt ist.	Erstellt eine einzelne Tabelle, die nach der für die Firebase-App (bar) festgelegten Kennung benannt ist, und schreibt dann in diese Tabelle.	Implementieren Sie entweder Option 1 oder Option 2, wie unten beschrieben.
foo	bar, qux usw.	Schreibt in eine einzelne Tabelle, die nach der Kennung in der Binärdatei der App (foo) benannt ist.	Erstellt* und schreibt dann in mehrere Tabellen, die nach den für Firebase-Apps festgelegten Kennungen benannt sind (bar, qux usw.)	Implementieren Sie Option 2 (siehe unten).
foo, baz usw.	bar	Schreibt in mehrere Tabellen, die nach den mehreren Kennungen in der Binärdatei der Anwendung benannt sind (foo, baz usw.)	Erstellt** und schreibt dann die Daten jeder App in eine einzelne Tabelle, die nach der für die Firebase-App festgelegten Kennung (bar) benannt ist	Keine der Optionen kann implementiert werden. Sie können die Daten der einzelnen Apps in der Tabelle weiterhin anhand der bundle_identifier der App unterscheiden, die zusammen mit den Daten exportiert wird.

^{* Wenn die Kennung in der Binärdatei Ihrer App mit einer der Kennungen übereinstimmt, die für eine Firebase-App festgelegt wurden, wurde von der neuen Exportinfrastruktur keine neue Tabelle für diese Kennung erstellt. Stattdessen werden weiterhin Daten für diese App dorthin geschrieben. Alle anderen Apps werden in neue Tabellen geschrieben.}

^{** Wenn eine der Kennungen in der Binärdatei Ihrer App mit der für die Firebase-App festgelegten Kennung übereinstimmt, wurde von der neuen Exportinfrastruktur keine neue Tabelle erstellt. Stattdessen wird diese Tabelle beibehalten und es werden Daten für alle Apps in sie geschrieben.}

Optionen zur Minimierung von Unterbrechungen

Wichtig: Wenn Sie Fragen haben oder sich nicht sicher sind, wie Sie eine dieser Optionen implementieren sollen, wenden Sie sich an den Firebase-Support.

• OPTION 1:
  Verwenden Sie die neue Tabelle, die von der neuen Exportinfrastruktur erstellt wurde. Sie kopieren Daten aus der Legacy-Tabelle in die neue Tabelle.

  1. Kopieren Sie in der Google Cloud-Konsole alle Daten aus der Legacy-Tabelle in die neue Tabelle, die während des Infrastrukturupgrades erstellt wurde.

  2. Wenn Sie nachgelagerte Abhängigkeiten haben, die von Ihrer Batchtabelle abhängen, ändern Sie sie so, dass die neue Tabelle verwendet wird.

  Hinweis: Neue Daten werden nicht in die Legacy-Tabelle geschrieben. Zuvor in die Legacy-Tabelle geschriebene Daten werden nicht gelöscht.

• OPTION 2:
  Konfigurieren Sie die Einstellungen so, dass wieder in die Legacy-Tabelle geschrieben wird. Dazu müssen Sie einige Standardeinstellungen in einer BigQuery-Konfiguration überschreiben.

  1. Suchen Sie in der Firebase-Konsole nach der Firebase-App-ID (z. B. 1:1234567890:ios:321abc456def7890) der App mit dem nicht übereinstimmenden Batchtabellennamen und der Kennung und notieren Sie sie:
     Rufen Sie die Projekteinstellungen auf und rufen Sie dann die Karte Meine Apps auf, um alle Ihre Firebase-Apps und die zugehörigen Informationen zu sehen.

  2. Ändern Sie in der Google Cloud-Konsole die neue „Datenübertragungskonfiguration“, die durch das Infrastruktur-Upgrade erstellt wurde, sodass Daten in Ihre Legacy-Tabelle geschrieben werden:

     1. Rufen Sie BigQuery > Datenübertragungen auf, um Ihre „Datenübertragungskonfiguration“ aufzurufen.

     2. Wählen Sie die Konfiguration mit der Quelle Firebase Crashlytics with Multi-Region Support aus.

     3. Klicken Sie rechts oben auf Bearbeiten.

     4. Im Abschnitt Details zur Datenquelle finden Sie eine Liste für gmp_app_id und eine Liste für client_namespace.

        In BigQuery wird die Firebase-App-ID als gmp_app_id bezeichnet. Standardmäßig ist der Wert client_namespace in BigQuery die entsprechende eindeutige Paket-ID / der entsprechende eindeutige Paketname der App. Sie überschreiben diese Standardkonfiguration jedoch.

        BigQuery verwendet den Wert client_namespace für den Namen der Batchtabelle, in die jede verknüpfte Firebase-App schreibt.

     5. Suchen Sie die gmp_app_id der Firebase-App, für die Sie die Standardeinstellungen überschreiben möchten. Ändern Sie den Wert für client_namespace in den Namen der Tabelle, in die die Firebase-App stattdessen schreiben soll. In der Regel ist dies der Name der Legacy-Tabelle, in die die App mit der Legacy-Exportinfrastruktur geschrieben hat.

        Hinweis: Wenn Sie zuvor in eine einzelne Tabelle geschrieben haben und nach dem Upgrade mehrere Tabellen haben, können Sie für jede entsprechende gmp_app_id die gleiche client_namespace verwenden. BigQuery werden im Wesentlichen alle Tabellen zusammengeführt und alle Daten für alle Firebase-Apps in diese eine Tabelle geschrieben.

     6. Speichern Sie die Konfigurationsänderung.

  3. Planen Sie einen Backfill für die Tage, an denen in Ihrer Legacy-Tabelle Daten fehlen.

  4. Löschen Sie nach Abschluss des Backfills die neue Tabelle, die automatisch von der neuen Exportinfrastruktur erstellt wurde.