Rozwiązywanie problemów z Crashlytics i najczęstsze pytania

Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów i odpowiedzi na najczęstsze pytania dotyczące korzystania z Crashlytics. Jeśli nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, skontaktuj się z zespołem pomocy Firebase.

Na tej stronie znajdziesz informacje o tych typach tematów:

• Ogólne rozwiązywanie problemów, w tym pytania dotyczące wyświetlania danych lub pracy z danymi w konsoli Firebase oraz pytania dotyczące problemów z regresją.

• Pomoc dotycząca konkretnych platform, w tym pytania dotyczące platform Apple, Androida, internetu i Unity.

• Pomoc dotycząca integracji, w tym pytania o BigQuery.

Rozwiązywanie problemów ogólnych / najczęstsze pytania

Wyświetlanie różnych formatów (a czasami „wariantów”) niektórych problemów w tabeli Problemy.

W tabeli Problemy w konsoli Firebase możesz zauważyć 2 różne formaty problemów. W niektórych problemach możesz też zauważyć funkcję „warianty”. Oto dlaczego.

Na początku 2023 r. wprowadziliśmy ulepszony mechanizm analityczny do grupowania zdarzeń, a także zaktualizowany wygląd i kilka funkcji zaawansowanych dotyczących nowych problemów (np. wariantów). Wszystkie szczegóły znajdziesz w naszym niedawnym poście na blogu, ale poniżej możesz przeczytać najważniejsze informacje.

Crashlytics analizuje wszystkie zdarzenia z aplikacji (takie jak awarie, błędy niekrytyczne i błędy ANR) i tworzy grupy zdarzeń nazywane problemami – wszystkie zdarzenia w ramach problemu mają wspólny punkt awarii.

Aby pogrupować zdarzenia w te problemy, ulepszony mechanizm analizy sprawdza teraz wiele aspektów zdarzenia, w tym ramki w zrzucie stosu, komunikat o wyjątku, kod błędu i inne cechy platformy lub typu błędu.

Jednak w tej grupie zdarzeń zrzuty stosu prowadzące do błędu mogą się różnić. Inny zrzut stosu może oznaczać inną główną przyczynę. Aby odzwierciedlić tę możliwą różnicę w ramach problemu, tworzymy teraz warianty w ramach problemów – każdy wariant to podgrupa zdarzeń w ramach problemu, które mają ten sam punkt awarii i podobny zrzut stosu. Dzięki wariantom możesz debugować najczęstsze zrzuty stosu w ramach problemu i ustalić, czy błąd jest spowodowany różnymi głównymi przyczynami.

Oto co zyskasz dzięki tym ulepszeniom:

• Ulepszone metadane wyświetlane w wierszu problemu
  Teraz łatwiej jest zrozumieć i rozwiązać problemy w aplikacji.

• Mniej zduplikowanych problemów
  Zmiana numeru wiersza nie powoduje utworzenia nowego problemu.

• Łatwiejsze debugowanie złożonych problemów o różnych głównych przyczynach
  Używaj wariantów do debugowania najczęstszych zrzutów stosu w ramach problemu.

• Bardziej przydatne alerty i sygnały
  Nowy problem faktycznie oznacza nowy błąd.

• Bardziej zaawansowane wyszukiwanie
  Każdy problem zawiera więcej metadanych, które można wyszukiwać, takich jak typ wyjątku i nazwa pakietu.

Oto jak wprowadzamy te ulepszenia:

• Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują do istniejącego problemu.

• Jeśli nie znajdziemy dopasowania, automatycznie zastosujemy do zdarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.

To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu zdarzeń. Jeśli masz uwagi lub napotkasz problemy, daj nam znać, przesyłając zgłoszenie.

Brak logów działań użytkownika

Jeśli nie widzisz logów działań użytkownika (iOS+ | Android | Flutter | Unity), zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics. Upewnij się, że spełniasz poniższe wymagania:

• W projekcie w Firebase masz włączoną usługę Google Analytics.

• Włączono udostępnianie danych w usłudze Google Analytics. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych w Analytics.

• Do aplikacji dodano pakiet SDK Firebase dla Google Analytics: iOS+ | Android | Flutter | Unity.
  Ten pakiet SDK należy dodać oprócz pakietu SDK Crashlytics.

• Używasz najnowszych wersji pakietu Firebase SDK we wszystkich usługach, z których korzystasz w aplikacji (iOS+ | Android | Flutter | Unity).

  W przypadku platform Apple i aplikacji na Androida sprawdź, czy używasz co najmniej tej wersji pakietu SDK Firebase dla usługi Google Analytics: iOS+ – wersja 6.3.1 lub nowsza (wersja 8.9.0 lub nowsza w przypadku macOS i tvOS) | Android – wersja 17.2.3 lub nowsza (BoM wersja 24.7.1 lub nowsza).

Nie widzę alertów dotyczących szybkości

Jeśli nie widzisz alertów dotyczących szybkości, upewnij się, że używasz:

Nie otrzymuję alertów Crashlytics (uprawnienia)

Aby otrzymywać lub konfigurować alerty Crashlytics, członkowie projektu muszą mieć wymagane uprawnienia. Ustawieniami alertów i preferencjami alertów na koncie możesz zarządzać w konsoli Firebase na stronie Ustawienia > Alerty.

Uwaga: alerty e-mail są wysyłane tylko na indywidualne adresy e-mail (nie na konta Grup dyskusyjnych Google ani Google Workspace). Możesz włączyć lub wyłączyć alerty na swoim koncie bez wpływu na innych członków projektu.

W tabeli poniżej znajdziesz wymagane uprawnienia i role zdefiniowane, które domyślnie je zawierają:

Funkcja	Wymagane uprawnienia do otrzymywania alertów	Role, które domyślnie obejmują wymagane uprawnienia
Crashlytics – alerty w aplikacji mobilnej	firebase.projects.update	Właściciel Edytujący Administrator Firebase
Crashlytics – alerty aplikacji internetowej	monitoring.alertPolicies.create monitoring.alertPolicies.update monitoring.notificationChannels.create	Właściciel Edytujący Edytujący monitorowanie

Więcej informacji o konfigurowaniu alertów znajdziesz w artykule Konfigurowanie i otrzymywanie alertów Crashlytics. Więcej informacji o rolach i uprawnieniach znajdziesz w artykule Uprawnienia i dostęp do Firebase.

Brak danych o braku awarii (lub dane są niewiarygodne)

Jeśli nie widzisz danych dotyczących braku awarii (np. użytkowników i sesji bez awarii) lub widzisz niewiarygodne dane, sprawdź te kwestie:

• Upewnij się, że używasz:

• Upewnij się, że ustawienia zbierania danych nie wpływają na jakość wskaźników dotyczących braku awarii:

  • Jeśli włączysz zgłaszanie awarii po wyrażeniu zgody przez wyłączenie automatycznego zgłaszania awarii, informacje o awariach mogą być wysyłane do usługi Crashlytics tylko od użytkowników, którzy wyraźnie wyrazili zgodę na zbieranie danych. Wpłynie to na dokładność danych o braku awarii, ponieważ Crashlytics będzie mieć informacje o awariach tylko od tych użytkowników, którzy wyrazili zgodę (a nie od wszystkich użytkowników). Oznacza to, że wskaźniki sesji bez awarii mogą być mniej wiarygodne i mniej odzwierciedlać ogólną stabilność aplikacji.

  • Jeśli masz wyłączone automatyczne zbieranie danych, możesz użyć sendUnsentReports, aby wysyłać raporty z pamięci podręcznej na urządzeniu do Crashlytics. Użycie tej metody spowoduje wysłanie danych o awariach do usługi Crashlytics, ale nie danych o sesjach, co spowoduje, że wykresy w konsoli będą pokazywać niskie lub zerowe wartości wskaźników dotyczących sesji bez awarii.

Jak obliczana jest liczba użytkowników, u których nie wystąpiły awarie?

Więcej informacji znajdziesz w artykule Dane o braku awarii.

Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?

Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji stanu itp.

Gdy uczestnik projektu opublikuje notatkę, zostanie ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich członków projektu, którzy mają dostęp do notatki.

Poniżej opisujemy uprawnienia wymagane do wyświetlania, zapisywania i usuwania notatek:

• Użytkownicy projektu z dowolną z tych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki dotyczące problemu.

  • Właściciel lub edytujący projekt, Administrator Firebase, Administrator jakości lub Administrator Crashlytics

• Członkowie projektu z dowolną z tych ról mogą wyświetlać notatki opublikowane w problemie, ale nie mogą ich usuwać ani pisać.

  • Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość lub Wyświetlający Crashlytics

Czym jest problem, który się powtórzył?

Problem ulega regresji, gdy został wcześniej zamknięty, ale Crashlytics otrzymuje nowe zgłoszenie, że problem wystąpił ponownie. Crashlytics automatycznie ponownie otwiera te problemy, aby można było je rozwiązać w odpowiedni sposób.

Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics klasyfikuje problem jako regresję:

1. Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics otwiera odpowiedni problem dotyczący tej awarii (problem „A”).
2. Szybko naprawiasz ten błąd, zamykasz problem A, a następnie publikujesz nową wersję aplikacji.
3. Crashlytics otrzyma kolejne zgłoszenie dotyczące problemu „A” po jego zamknięciu.
   • Jeśli raport pochodzi z wersji aplikacji, o której usługa Crashlytics wiedziała w momencie zamknięcia problemu (co oznacza, że ta wersja wysłała raport o jakiejkolwiek awarii), Crashlytics nie uzna problemu za regresję. Problem pozostanie zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, o której usługa Crashlytics nie wiedziała w momencie zamknięcia problemu (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o żadnej awarii), Crashlytics uzna, że problem powrócił, i ponownie go otworzy.

Uwaga: przed lutym 2022 roku usługa Crashlytics klasyfikowała problem jako regresję, gdy wystąpił on ponownie w dowolnej wersji aplikacji, nawet w tych, o których wiedzieliśmy, gdy problem został zamknięty. W efekcie Crashlytics czasami nieprawidłowo identyfikował regresje. Teraz używamy konwencji opisanej powyżej.

Gdy problem się powtórzy, wysyłamy alert o wykryciu regresji i dodajemy do problemu sygnał regresji, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty przez nasz algorytm regresji, „wycisz” go zamiast zamykać.

Dlaczego widzę problemy, które ponownie wystąpiły w starszych wersjach aplikacji?

Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysłała żadnych raportów o awariach, gdy problem został zamknięty, Crashlytics uzna, że problem powrócił, i ponownie go otworzy.

Taka sytuacja może wystąpić, gdy naprawisz błąd i opublikujesz nową wersję aplikacji, ale niektórzy użytkownicy nadal będą korzystać z jej wcześniejszych wersji, w których błąd nie został naprawiony. Jeśli przypadkowo jedna z tych wcześniejszych wersji nigdy nie wysłała żadnych raportów o awariach, gdy problem został zamknięty, a użytkownicy zaczną napotykać błąd, te raporty o awariach wywołają problem z regresją.

Jeśli nie chcesz, aby problem został ponownie otwarty przez nasz algorytm regresji, „wycisz” go zamiast zamykać.

Uwaga: przed lutym 2022 roku usługa Crashlytics klasyfikowała problem jako regresję, gdy wystąpił on ponownie w dowolnej wersji aplikacji, nawet w tych, o których wiedzieliśmy, gdy problem został zamknięty. W efekcie Crashlytics czasami nieprawidłowo identyfikował regresje. Teraz używamy konwencji opisanej powyżej.

Jeśli widzisz wiele błędnie zidentyfikowanych regresji sprzed lutego 2022 r., możesz je ponownie zamknąć, aby zapobiec ich ponownemu otwarciu.

---

Pomoc dotycząca konkretnej platformy

W sekcjach poniżej znajdziesz informacje o rozwiązywaniu problemów i najczęstsze pytania dotyczące poszczególnych platform: iOS+ | Android | Web | Unity.

Obsługa platform Apple

Brak plików dSYM lub nie można ich przesłać

Aby przesłać pliki dSYM projektu i uzyskać szczegółowe dane wyjściowe, sprawdź te opcje:

1. Upewnij się, że faza kompilacji projektu zawiera skrypt uruchamiania Crashlytics, który umożliwia Xcode przesyłanie dSYM projektu podczas kompilacji (instrukcje dodawania skryptu znajdziesz w artykule Inicjowanie Crashlytics). Po zaktualizowaniu projektu wymuś awarię i sprawdź, czy pojawi się ona w panelu Crashlytics.

2. Jeśli w konsoli Firebase pojawi się alert „Brak dSYM”, sprawdź w Xcode, czy prawidłowo generuje dSYM dla kompilacji.

3. Jeśli Xcode prawidłowo generuje pliki dSYM, ale nadal widzisz brakujące pliki dSYM, prawdopodobnie narzędzie do uruchamiania skryptów zacina się podczas przesyłania plików dSYM. W takim przypadku wypróbuj te rozwiązania:

   • Upewnij się, że używasz najnowszej wersji Crashlytics.

   • Prześlij brakujące pliki dSYM ręcznie:

     • Opcja 1. Użyj opcji „Przeciągnij i upuść” na karcie dSYM w konsoli, aby przesłać plik ZIP zawierający brakujące pliki dSYM.
     • Opcja 2. Użyj skryptu upload-symbols, aby przesłać brakujące pliki dSYM dla identyfikatorów UUID podanych na karcie Pliki dSYM.

4. Jeśli nadal widzisz brakujące pliki dSYM lub przesyłanie nadal się nie udaje, skontaktuj się z zespołem pomocy Firebase i pamiętaj o dołączeniu logów.

Awarie są słabo symbolizowane

Jeśli zrzuty stosu wydają się nieprawidłowo symbolizowane, sprawdź te kwestie:

• Jeśli ramki z biblioteki aplikacji nie zawierają odniesień do kodu aplikacji, upewnij się, że flaga kompilacji nie jest ustawiona na -fomit-frame-pointer.

• Jeśli widzisz kilka klatek (Missing) dla biblioteki aplikacji, sprawdź, czy na karcie Crashlytics dSYMs w konsoli Firebase nie ma opcjonalnych plików dSYM oznaczonych jako brakujące (w przypadku wersji aplikacji, której dotyczy problem). Jeśli tak, wykonaj krok rozwiązywania problemów „Alert o braku dSYM” opisany w sekcji Najczęstsze pytania dotyczące braku lub nieprzesyłania dSYM na tej stronie. Pamiętaj, że przesłanie tych plików dSYM nie spowoduje symbolizacji awarii, które już wystąpiły, ale pomoże zapewnić symbolizację przyszłych awarii.

Czy mogę używać Crashlytics w systemie macOS lub tvOS?

Tak, możesz wdrożyć Crashlytics w projektach na macOS i tvOS. Upewnij się, że używasz pakietu SDK Firebase dla Google Analytics w wersji 8.9.0 lub nowszej, aby w przypadku awarii mieć dostęp do danych zbieranych przez Google Analytics (użytkownicy bez awarii, najnowsza wersja, alerty o częstotliwości i logi działań użytkownika).

Czy mogę używać Crashlytics w projekcie Firebase z wieloma aplikacjami na różnych platformach Apple?

Możesz teraz zgłaszać awarie wielu aplikacji w jednym projekcie w Firebase, nawet jeśli aplikacje są przeznaczone na różne platformy Apple (np. iOS, tvOS i Mac Catalyst). Wcześniej, jeśli aplikacje miały ten sam identyfikator pakietu, trzeba było je rozdzielić na osobne projekty w Firebase.

---

Obsługa Androida

Dlaczego błędy ANR są zgłaszane tylko w przypadku Androida 11 i nowszych wersji?

Crashlytics obsługuje raportowanie raportów ANR w przypadku aplikacji na Androida na urządzeniach z Androidem 11 lub nowszym. Interfejs API, którego używamy do zbierania informacji o błędach ANR (getHistoricalProcessExitReasons), jest bardziej niezawodny niż podejście oparte na SIGQUIT lub watchdogu. Ten interfejs API jest dostępny tylko na urządzeniach z Androidem 11 lub nowszym.

Dlaczego w przypadku niektórych błędów ANR brakuje BuildId?

Jeśli w przypadku niektórych błędów ANR brakuje BuildId, wykonaj te czynności:

• Upewnij się, że używasz aktualnej wersji pakietu Android SDK Crashlytics i wtyczki Gradle Crashlytics.

  Jeśli brakuje Ci BuildId w przypadku błędów ANR na Androidzie 11 i niektórych błędów ANR na Androidzie 12, prawdopodobnie używasz nieaktualnego pakietu SDK lub wtyczki Gradle (albo obu tych rozwiązań). Aby prawidłowo zbierać BuildId dla tych błędów ANR, musisz używać tych wersji:

  • Crashlytics Android SDK w wersji 18.3.5 lub nowszej (Firebase BoM w wersji 31.2.2 lub nowszej)
  • Wtyczka Gradle Crashlytics w wersji 2.9.4 lub nowszej

• Sprawdź, czy nie używasz niestandardowej lokalizacji bibliotek udostępnionych.

  Jeśli brakuje tylko plików BuildId w bibliotekach współdzielonych aplikacji, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek współdzielonych. W takim przypadku Crashlytics może nie być w stanie znaleźć powiązanych BuildId. Zalecamy rozważenie użycia standardowej lokalizacji zasobów wspólnych.

• Upewnij się, że podczas procesu kompilacji nie usuwasz BuildId.

  Pamiętaj, że poniższe wskazówki dotyczące rozwiązywania problemów dotyczą zarówno błędów ANR, jak i awarii systemowych.

  • Sprawdź, czy BuildId istnieją, uruchamiając readelf -n na plikach binarnych. Jeśli nie ma BuildId, dodaj -Wl,--build-id do flag systemu kompilacji.

  • Sprawdź, czy nie usuwasz nieumyślnie plików BuildId, aby zmniejszyć rozmiar pliku APK.

  • Jeśli zachowujesz wersje biblioteki z informacjami i bez informacji o debugowaniu, upewnij się, że w kodzie wskazujesz właściwą wersję.

Różnice między raportami ANR w panelu Crashlytics i Konsoli Google Play

Liczba błędów ANR w Google Play i Crashlytics może się różnić. Jest to spowodowane różnicą w mechanizmie zbierania i raportowania danych o błędach ANR. Crashlytics zgłasza błędy ANR przy następnym uruchomieniu aplikacji, natomiast Android Vitals wysyła dane o błędach ANR po ich wystąpieniu.

Dodatkowo Crashlytics wyświetla tylko błędy ANR, które występują na urządzeniach z Androidem 11 lub nowszym, podczas gdy Google Play wyświetla błędy ANR z urządzeń z Usługami Google Play i zaakceptowaną zgodą na zbieranie danych.

Dlaczego widzę awarie z plików .kt oznaczone jako problemy z .java?

Gdy aplikacja używa zaciemniacza, który nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java.

Aby usługa Crashlytics mogła generować problemy z prawidłowym rozszerzeniem pliku, upewnij się, że aplikacja korzysta z tej konfiguracji:

• używa wtyczki Androida do obsługi Gradle w wersji 4.2.0 lub nowszej,
• używa R8 z włączonym zaciemnianiem kodu; Aby zaktualizować aplikację do R8, postępuj zgodnie z tą dokumentacją.

Pamiętaj, że po przejściu na konfigurację opisaną powyżej możesz zacząć widzieć nowe problemy z .kt, które są duplikatami istniejących problemów z .java. Więcej informacji o takiej sytuacji znajdziesz w najczęstszych pytaniach.

Dlaczego widzę problemy .kt, które są duplikatami istniejących problemów .java?

Od połowy grudnia 2021 r. Crashlytics zapewnia lepszą obsługę aplikacji korzystających z języka Kotlin.

Do niedawna dostępne zaciemniacze nie ujawniały rozszerzenia pliku, więc Crashlytics domyślnie generował każdy numer z rozszerzeniem .java. Jednak od wersji 4.2.0 wtyczki Androida do obsługi Gradle R8 obsługuje rozszerzenia plików.

Dzięki tej aktualizacji Crashlytics może teraz określić, czy każda klasa używana w aplikacji jest napisana w Kotlinie, i uwzględnić prawidłową nazwę pliku w sygnaturze problemu. Awarie są teraz prawidłowo przypisywane do plików .kt (w odpowiednich przypadkach), jeśli Twoja aplikacja ma tę konfigurację:

• Aplikacja używa wtyczki Androida do obsługi Gradle w wersji 4.2.0 lub nowszej.
• Twoja aplikacja używa R8 z włączonym zaciemnianiem kodu.

Nowe awarie zawierają teraz prawidłowe rozszerzenie pliku w sygnaturach problemów, więc możesz zobaczyć nowe problemy .kt, które są w rzeczywistości duplikatami istniejących problemów oznaczonych jako .java. W konsoli Firebase staramy się wykrywać i informować Cię, jeśli nowy problem .kt może być duplikatem istniejącego problemu oznaczonego etykietą .java.

Brak awarii w przypadku Dexguard

Jeśli widzisz ten wyjątek, prawdopodobnie używasz wersji DexGuard, która jest niezgodna z pakietem SDK Firebase Crashlytics:

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

Ten wyjątek nie powoduje awarii aplikacji, ale uniemożliwia jej wysyłanie raportów o awariach. Aby rozwiązać ten problem:

1. Upewnij się, że używasz najnowszej wersji DexGuard 8.x. Najnowsza wersja zawiera reguły wymagane przez pakiet SDK Firebase Crashlytics.

2. Jeśli nie chcesz zmieniać wersji DexGuard, spróbuj dodać ten wiersz do reguł zaciemniania (w pliku konfiguracji DexGuard):

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

Jak przejść na wtyczkę Gradle Crashlytics w wersji 3?

Najnowsza wersja wtyczki Gradle Crashlytics to wersja główna (v3.0.0), która unowocześnia pakiet SDK, wycofując obsługę starszych wersji Gradle i wtyczki Androida do obsługi Gradle. Dodatkowo zmiany w tej wersji rozwiązują problemy z AGP w wersji 8.1 lub nowszej oraz ulepszają obsługę aplikacji natywnych i niestandardowych kompilacji.

Wymagania minimalne

Wtyczka Gradle Crashlytics w wersji 3 ma te wymagania minimalne:

• Wtyczka Androida do obsługi Gradle w wersji 8.1 lub nowszej
  Uaktualnij tę wtyczkę za pomocą asystenta uaktualniania wtyczki Androida do obsługi Gradle w najnowszej wersji Android Studio.

• Wtyczka Firebase google-services do obsługi Gradle w wersji 4.4.1 lub nowszej
  Uaktualnij tę wtyczkę, podając najnowszą wersję w pliku kompilacji Gradle projektu, na przykład:

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
  ...
}

Zmiany w rozszerzeniu Crashlytics

W przypadku wtyczki Gradle Crashlytics w wersji 3 rozszerzenie Crashlytics zawiera te zmiany powodujące niezgodność:

• Usunięto rozszerzenie z bloku Androida defaultConfig. Zamiast tego skonfiguruj każdy wariant.

• Usunięto wycofane pole mappingFile. Zamiast tego scalony plik mapowania jest teraz udostępniany automatycznie.

• Usunięto wycofane pole strippedNativeLibsDir. Zamiast tego używaj unstrippedNativeLibsDir we wszystkich bibliotekach natywnych.

• Zmieniono pole unstrippedNativeLibsDir na skumulowane.

  Wyświetlanie przykładu z wieloma katalogami

  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")
        }
      }
    }
  }

  Zadanie uploadCrashlyticsSymbolFilesBasicRelease prześle tylko symbole z MY/NATIVE/LIBS, ale uploadCrashlyticsSymbolFilesFeatureXRelease prześle symbole zarówno z MY/NATIVE/LIBS, jak i MY/FEATURE_X/LIBS.

• Zastąpiono pole zamknięcia symbolGenerator 2 nowymi polami najwyższego poziomu:

  • symbolGeneratorType, ciąg znaków "breakpad" (domyślny) lub "csym".
  • breakpadBinary, plik lokalnego zastąpienia binarnego dump_syms.

Przykład uaktualniania rozszerzenia

Kotlin

Przed	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } }
Nowości w wersji 3	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Groovy

Przed	buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
Nowości w wersji 3	buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Obsługa Android-NDK

Różnice między zrzutami stosu NDK w panelu Crashlytics i logcat

Zestawy narzędzi LLVM i GNU mają różne ustawienia domyślne i sposoby traktowania segmentu tylko do odczytu plików binarnych aplikacji, co może powodować generowanie niespójnych zrzutów stosu w konsoli Firebase. Aby rozwiązać ten problem, dodaj do procesu kompilacji te flagi łączące:

• Jeśli używasz tagu łączącego lld z zestawu narzędzi LLVM, dodaj:

  -Wl,--no-rosegment

• Jeśli używasz tagu łączącego ld.gold z łańcucha narzędzi GNU, dodaj:

  -Wl,--rosegment

Jeśli nadal widzisz niespójności w zrzucie stosu (lub jeśli żadna flaga nie jest odpowiednia dla Twojego zestawu narzędzi), spróbuj dodać do procesu kompilacji te elementy:

-fno-omit-frame-pointer

Jak używać własnego pliku binarnego generatora plików symboli Breakpad dla NDK?

Wtyczka Crashlytics zawiera niestandardowy generator plików symboli Breakpad. Jeśli wolisz używać własnego pliku binarnego do generowania plików symboli Breakpad (np. jeśli wolisz tworzyć wszystkie natywne pliki wykonywalne w łańcuchu kompilacji z kodu źródłowego), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary, aby określić ścieżkę do pliku wykonywalnego.

Uwaga: w przypadku plików binarnych Androida wymagana jest wersja generatora plików symboli Breakpad na Linuksa.

Ścieżkę do pliku binarnego generatora plików symboli Breakpad możesz określić na 2 sposoby:

• Opcja 1. Określ ścieżkę za pomocą rozszerzenia firebaseCrashlytics w pliku build.gradle.

  Dodaj do pliku build.gradle.kts na poziomie aplikacji te informacje:

  Wtyczka Gradle w wersji 3.0.0 lub nowszej

  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")
        }
      }
    }
  }

  niższe wersje wtyczki

  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")
            }
          }
        }
     }
  }

• Opcja 2. Określ ścieżkę w wierszu właściwości w pliku właściwości Gradle.

  Możesz użyć właściwości com.google.firebase.crashlytics.breakpadBinary, aby określić ścieżkę do pliku wykonywalnego.

  Możesz ręcznie zaktualizować plik właściwości Gradle lub zaktualizować go za pomocą wiersza poleceń. Aby na przykład określić ścieżkę w wierszu poleceń, użyj polecenia podobnego do tego:

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

Czy Crashlytics obsługuje armeabi?

NDK w wersji Firebase Crashlytics nie obsługuje ARMv5 (armeabi). Obsługa tego interfejsu ABI została usunięta w NDK r17.

---

Pomoc przez internet

Wyświetla się błąd Component crashlytics has not been registered yet

Jeśli używasz pakietu @firebase/crashlytics, nie mieszaj modułowych przestrzeni nazw w importach. Importowanie initializeApp z firebase/app podczas importowania getCrashlytics z @firebase/crashlytics powoduje, że bundlery wczytują 2 osobne rejestry wewnętrzne, co prowadzi do błędów takich jak Component crashlytics has not been registered yet.

Aby zapobiec konfliktom rejestru podwójnych pakietów:

1. Ujednolic wszystkie importy Firebase w projekcie, aby używały zakresu przestrzeni nazw @firebase/ (np. @firebase/app i @firebase/crashlytics).

2. Jeśli Twoja aplikacja używa Vite, wyraźnie usuń duplikaty @firebase/app w pliku vite.config.ts:

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

Błąd kompilacji TypeScript przy włączonej opcji verbatimModuleSyntax

Nowoczesne konfiguracje TypeScript (takie jak szablony Vite i Angular) często włączają "verbatimModuleSyntax": true w tsconfig.json. Gdy ta flaga jest włączona, importowanie interfejsu TypeScript za pomocą standardowego importu wartości powoduje błąd kompilacji.

Podczas importowania interfejsów TypeScript, takich jak FirebaseApp lub Crashlytics, używaj jawnych importów type:

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

---

Pomoc dotycząca Unity

W panelu Crashlytics widzisz nieprzetworzone zrzuty stosu aplikacji na Androida

Jeśli używasz Unity IL2CPP i widzisz niesymbolizowane zrzuty stosu, wypróbuj te rozwiązania:

1. Upewnij się, że używasz pakietu SDK Crashlytics Unity w wersji 8.6.1 lub nowszej.

2. Upewnij się, że masz skonfigurowany interfejs wiersza poleceń Firebase i uruchom polecenie crashlytics:symbols:upload, aby wygenerować i przesłać plik symboli.

   To polecenie interfejsu wiersza poleceń musisz uruchamiać za każdym razem, gdy tworzysz kompilację do publikacji lub dowolną kompilację, dla której chcesz wyświetlać zrzuty stosu z symbolami w konsoli Firebase. Więcej informacji znajdziesz w artykule Uzyskiwanie czytelnych raportów o awariach.

Czy Crashlytics można używać z aplikacjami, które korzystają z IL2CPP?

Tak, Crashlytics może wyświetlać zrzuty stosu z symbolami w przypadku aplikacji, które używają IL2CPP. Ta funkcja jest dostępna w przypadku aplikacji opublikowanych na platformach Android lub Apple. Oto co musisz zrobić:

1. Upewnij się, że używasz pakietu SDK Crashlytics Unity w wersji 8.6.0 lub nowszej.

2. Wykonaj niezbędne czynności na swojej platformie:

   • W przypadku aplikacji na platformy Apple: nie musisz nic robić. W przypadku aplikacji na platformy Apple wtyczka Firebase Unity Editor automatycznie konfiguruje projekt Xcode do przesyłania symboli.

   • W przypadku aplikacji na Androida: upewnij się, że masz skonfigurowane i uruchomione polecenie Firebase interfejsu wiersza poleceń crashlytics:symbols:upload, które generuje i przesyła plik symboli.

     To polecenie interfejsu wiersza poleceń musisz uruchamiać za każdym razem, gdy tworzysz kompilację do publikacji lub dowolną kompilację, dla której chcesz wyświetlać zrzuty stosu z symbolami w konsoli Firebase. Więcej informacji znajdziesz w artykule Uzyskiwanie czytelnych raportów o awariach.

Zgłaszanie niewykrytych wyjątków jako błędów krytycznych

Crashlytics może zgłaszać nieobsługiwane wyjątki jako błędy krytyczne (począwszy od wersji 10.4.0 pakietu SDK Unity). Poniżej znajdziesz odpowiedzi na najczęstsze pytania, które wyjaśniają, dlaczego warto korzystać z tej funkcji i jak robić to najlepiej.

Dlaczego aplikacja powinna zgłaszać nieobsługiwane wyjątki jako błędy krytyczne?

Zgłaszanie nieprzechwyconych wyjątków jako błędów krytycznych pozwala uzyskać bardziej realistyczne informacje o tym, które wyjątki mogą uniemożliwić rozgrywkę, nawet jeśli aplikacja nadal działa.

Pamiętaj, że jeśli zaczniesz zgłaszać błędy krytyczne, odsetek użytkowników, u których nie wystąpiła awaria, prawdopodobnie się zmniejszy, ale dane dotyczące tych użytkowników będą lepiej odzwierciedlać wrażenia użytkowników końcowych związane z Twoją aplikacją.

Ważne: zgłaszanie nieprzechwyconych wyjątków jako błędów krytycznych nie wpływa na Android Vitals. Błędy krytyczne zgłoszone w Crashlytics są widoczne tylko dla Ciebie, dzięki czemu możesz wykrywać i rozwiązywać problemy w swoich aplikacjach i grach.

Które wyjątki będą zgłaszane jako błędy krytyczne?

Aby Crashlytics zgłosił nieobsługiwany wyjątek jako błąd krytyczny, muszą być spełnione oba te warunki:

• Podczas inicjowania w aplikacji właściwość ReportUncaughtExceptionsAsFatal musi być ustawiona na true.

• Twoja aplikacja (lub dołączona biblioteka) zgłasza wyjątek, który nie jest przechwytywany. Wyjątek, który został utworzony, ale nie został zgłoszony, nie jest uznawany za nieprzechwycony.

Po włączeniu raportowania nieprzechwyconych wyjątków jako błędów krytycznych mam teraz wiele nowych błędów krytycznych. Jak prawidłowo obsługiwać te wyjątki?

Gdy zaczniesz otrzymywać raporty o nieprzechwyconych wyjątkach jako błędach krytycznych, możesz je obsłużyć na kilka sposobów:

• Zastanów się, jak możesz zacząć przechwytywać i obsługiwać te nieprzechwycone wyjątki.
• Rozważ różne opcje logowania wyjątków w konsoli debugowania Unity i w Crashlytics.

Przechwytywanie i obsługa zgłoszonych wyjątków

Wyjątki są tworzone i zgłaszane, aby odzwierciedlić nieoczekiwane lub wyjątkowe stany. Rozwiązanie problemów, które spowodowały zgłoszenie wyjątku, polega na przywróceniu programu do znanego stanu (proces ten nazywa się obsługą wyjątków).

Zgodnie ze sprawdzonymi metodami należy przechwytywać i obsługiwać wszystkie przewidywane wyjątki, chyba że nie można przywrócić programu do znanego stanu.

Aby kontrolować, jakie rodzaje wyjątków są przechwytywane i obsługiwane przez dany kod, umieść kod, który może wygenerować wyjątek, w bloku try-catch. Upewnij się, że warunki w instrukcjach catch są jak najwęższe, aby odpowiednio obsługiwać konkretne wyjątki.

Rejestrowanie wyjątków w Unity lub Crashlytics

Istnieje kilka sposobów rejestrowania wyjątków w Unity lub Crashlytics, które pomagają w debugowaniu problemu.

Jeśli używasz Crashlytics, oto 2 najczęstsze i zalecane opcje:

• Opcja 1. Wyświetlaj w konsoli Unity, ale nie zgłaszaj do Crashlytics podczas programowania lub rozwiązywania problemów

  • Wyświetlaj wyjątki w konsoli Unity za pomocą metod Debug.Log(exception), Debug.LogWarning(exception) i Debug.LogError(exception), które wyświetlają zawartość wyjątku w konsoli Unity i nie zgłaszają go ponownie.

• Opcja 2. Prześlij do Crashlytics, aby uzyskać skonsolidowane raporty w panelu Crashlytics w tych sytuacjach:

  • Jeśli wyjątek warto zarejestrować, aby debugować możliwe kolejne zdarzenie Crashlytics, użyj Crashlytics.Log(exception.ToString()).
  • Jeśli wyjątek powinien być zgłaszany do usługi Crashlytics, mimo że został przechwycony i obsłużony, użyj metody Crashlytics.LogException(exception), aby zarejestrować go jako zdarzenie niekrytyczne.

Jeśli jednak chcesz ręcznie zgłosić zdarzenie krytyczne do Unity Cloud Diagnostics, możesz użyć Debug.LogException. Ta opcja powoduje wyświetlenie wyjątku w konsoli Unity, podobnie jak opcja 1, ale powoduje też zgłoszenie wyjątku (niezależnie od tego, czy został już zgłoszony lub przechwycony). Błąd jest zgłaszany nielokalnie. Oznacza to, że nawet otaczający blok Debug.LogException(exception) z blokami try-catch nadal powoduje nieprzechwycony wyjątek.

Dlatego wywołaj Debug.LogException tylko wtedy, gdy chcesz wykonać wszystkie te czynności:

• Aby wydrukować wyjątek w konsoli Unity.
• Przesyłanie wyjątku do Crashlytics jako zdarzenia krytycznego.
• Aby zgłosić wyjątek, potraktuj go jako nieprzechwycony i zgłoś do Unity Cloud Diagnostics.

Jeśli chcesz wydrukować przechwycony wyjątek w konsoli Unity oraz przesłać go do Crashlytics jako zdarzenie niekrytyczne, wykonaj te czynności:

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
    //
}

---

Pomoc dotycząca integracji

Aplikacja używa też pakietu SDK Google Mobile Ads, ale nie występują w niej awarie

Jeśli Twój projekt używa Crashlytics razem z pakietem SDK Google Mobile Ads, prawdopodobnie narzędzia do zgłaszania awarii zakłócają rejestrowanie modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz zgłaszanie awarii w pakiecie SDK Mobile Ads, wywołując disableSDKCrashReporting.

Gdzie znajduje się mój zbiór danych BigQuery?

Firebase eksportuje dane do lokalizacji zbioru danych wybranej podczas konfigurowania eksportu danych do BigQuery.

• Ta lokalizacja dotyczy zarówno zbioru danych Crashlytics, jak i zbioru danych sesji Firebase (jeśli włączono eksportowanie danych sesji).

• Ta lokalizacja dotyczy tylko danych wyeksportowanych do BigQuery i nie ma wpływu na lokalizację danych przechowywanych na potrzeby panelu Crashlytics w konsoli Firebase ani w Android Studio.

• Gdy zostanie on utworzony, jego lokalizacji nie można już zmienić. Możesz natomiast skopiować zbiór danych do innej lokalizacji lub go ręcznie przenieść przez ponowne utworzenie tego zbioru w innej lokalizacji. Więcej informacji znajdziesz w artykule Zmienianie lokalizacji istniejących eksportów.

Masz problemy po przejściu na nową infrastrukturę eksportu w przypadku usługi BigQuery?

W połowie października 2024 r. usługa Crashlytics uruchomiła nową infrastrukturę do zbiorczego eksportu danych z Crashlytics do BigQuery.

2 marca 2026 r. wszystkie projekty w Firebase zostały automatycznie uaktualnione do nowej infrastruktury eksportu zbiorczego.

Uwaga: to uaktualnienie infrastruktury dotyczy tylko zbiorczego eksportu informacji o awariach w Crashlytics i nie dotyczy eksportu sesji ani eksportu strumieniowego.

Ważne różnice między starą a nową infrastrukturą eksportu

• Nowa infrastruktura obsługuje Crashlytics lokalizacje zbiorów danych poza Stanami Zjednoczonymi.

  • Eksport włączony przed połową października 2024 r. i uaktualniony do nowej infrastruktury eksportu – możesz teraz opcjonalnie zmienić lokalizację eksportu danych.

  • Eksportowanie włączone w połowie października 2024 r. lub później – podczas konfiguracji pojawiła się prośba o wybranie lokalizacji eksportu danych.

• Nowa infrastruktura nie obsługuje uzupełniania danych sprzed włączenia eksportu.

  • Stara infrastruktura obsługiwała uzupełnianie danych do 30 dni przed datą włączenia eksportu.

  • Nowa infrastruktura obsługuje uzupełnianie danych z ostatnich 30 dni lub od ostatniej daty, kiedy włączono eksport do usługi BigQuery (w zależności od tego, co nastąpiło później).

• Nowa infrastruktura nadaje nazwy tabelom wsadowym BigQuery, używając identyfikatorów ustawionych dla aplikacji w Firebase w projekcie Firebase.

  • Stara infrastruktura zapisywała dane w tabelach zbiorczych o nazwach opartych na identyfikatorach pakietów lub nazwach pakietów w pliku binarnym aplikacji.

  • Nowa infrastruktura zapisuje dane w tabelach zbiorczych o nazwach opartych na identyfikatorach pakietów lub nazwach pakietów ustawionych dla zarejestrowanych aplikacji w Firebase w projekcie w Firebase.

Jeśli nazwa starszej tabeli zbiorczej nie pasowała do identyfikatora aplikacji Firebase

Jeśli nazwa starszej tabeli zbiorczej nie pasowała do identyfikatora pakietu lub nazwy pakietu ustawionej dla zarejestrowanej aplikacji w Firebase, zastosuj jedną z tych opcji, aby uniknąć dalszych zakłóceń w eksportowanych danych zbiorczych.

Dowiedz się, jak infrastruktura eksportu używa identyfikatorów do zapisywania danych w tabelach BigQuery

Oto jak obie infrastruktury eksportu zapisują dane Crashlytics w tabelach zbiorczych BigQuery:

• Starsza infrastruktura eksportu: zapisywała dane w tabeli o nazwie opartej na identyfikatorze pakietu lub nazwie pakietu w pliku binarnym aplikacji.

• Nowa infrastruktura eksportu: zapisuje dane w tabeli o nazwie opartej na identyfikatorze pakietu lub nazwie pakietu ustawionej dla zarejestrowanej aplikacji Firebase w projekcie Firebase.

Czasami identyfikator pakietu w pliku binarnym aplikacji nie pasuje do identyfikatora pakietu ustawionego dla zarejestrowanej aplikacji w Firebase w projekcie w Firebase. Zwykle dzieje się tak, gdy ktoś nie wpisze rzeczywistego identyfikatora podczas rejestracji aplikacji.

Co się stanie, jeśli nie rozwiążę tego problemu przed uaktualnieniem?

Jeśli identyfikatory w tych 2 miejscach nie są zgodne, oznacza to, że:

• Dane Crashlytics są teraz zapisywane w nowej tabeli zbiorczej BigQuery, czyli nowej tabeli o nazwie opartej na identyfikatorze pakietu lub nazwie pakietu ustawionej dla zarejestrowanej aplikacji w Firebase w projekcie w Firebase.

• Do żadnej istniejącej „starszej” tabeli o nazwie opartej na identyfikatorze w pliku binarnym aplikacji nie są już zapisywane dane.

Przykładowe scenariusze niezgodnych identyfikatorów

Pamiętaj, że do nazw tabel zbiorczych BigQuery automatycznie dodawane są ciągi znaków _IOS lub _ANDROID, które wskazują platformę aplikacji.

Identyfikatory w pliku binarnym aplikacji	Identyfikatory ustawione dla aplikacji w Firebase	Starsze działanie	Działanie po uaktualnieniu do nowej infrastruktury eksportu	Rozwiązanie
foo	bar	Zapisuje dane w pojedynczej tabeli, której nazwa pochodzi od identyfikatora w pliku binarnym aplikacji (foo)	Tworzy, a następnie zapisuje dane w pojedynczej tabeli o nazwie odpowiadającej identyfikatorowi ustawionemu dla aplikacji w Firebase (bar).	Zastosuj opcję 1 lub 2 opisaną poniżej.
foo	bar, qux itp.	Zapisuje dane w pojedynczej tabeli, której nazwa pochodzi od identyfikatora w pliku binarnym aplikacji (foo)	Tworzy*, a następnie zapisuje dane w wielu tabelach, których nazwy pochodzą od identyfikatorów ustawionych dla aplikacji w Firebase (bar, qux itd.).	Zastosuj opcję 2 opisaną poniżej.
foo, baz itp.	bar	Zapisuje dane w wielu tabelach, których nazwy pochodzą od wielu identyfikatorów w pliku binarnym aplikacji (foo, baz itd.).	Tworzy**, a następnie zapisuje dane każdej aplikacji w pojedynczej tabeli, której nazwa pochodzi od identyfikatora ustawionego dla aplikacji w Firebase (bar).	Żadnej z tych opcji nie można wdrożyć. Nadal możesz rozróżniać dane z poszczególnych aplikacji w jednej tabeli, używając bundle_identifier aplikacji, który jest eksportowany wraz z danymi.

^{* Jeśli identyfikator w pliku binarnym aplikacji pasował do jednego z identyfikatorów ustawionych dla aplikacji w Firebase, nowa infrastruktura eksportu nie utworzyła nowej tabeli dla tego identyfikatora. Zamiast tego będzie nadal zapisywać w nim dane tej konkretnej aplikacji. Wszystkie inne aplikacje będą zapisywane w nowych tabelach.}

^{** Jeśli jeden z identyfikatorów w pliku binarnym aplikacji pasował do identyfikatora ustawionego dla aplikacji w Firebase, nowa infrastruktura eksportu nie utworzyła nowej tabeli. Zamiast tego zachowa tę tabelę i zacznie zapisywać w niej dane wszystkich aplikacji.}

Opcje minimalizowania zakłóceń

Ważne: jeśli masz pytania lub nie czujesz się na siłach, aby wdrożyć jedną z tych opcji, skontaktuj się z zespołem pomocy Firebase.

• OPCJA 1.
  Użyj nowej tabeli utworzonej przez nową infrastrukturę eksportu. Skopiujesz dane ze starszej tabeli do nowej.

  1. W konsoli Google Cloud skopiuj wszystkie dane ze starej tabeli do nowej tabeli utworzonej podczas uaktualniania infrastruktury.

  2. Jeśli masz jakieś zależności podrzędne, które zależą od tabeli zbiorczej, zmień je tak, aby korzystały z nowej tabeli.

  Uwaga: nowe dane nie będą zapisywane w starszej tabeli. Wcześniej zapisane dane w starszej tabeli nie zostaną usunięte.

• OPCJA 2:
  Zmień konfigurację, aby ponownie zapisywać dane w starszej tabeli. Aby to zrobić, musisz zastąpić niektóre wartości domyślne w konfiguracji BigQuery.

  1. W konsoli Firebase znajdź i zapisz identyfikator aplikacji Firebase (np. 1:1234567890:ios:321abc456def7890) z niezgodną nazwą i identyfikatorem tabeli zbiorczej:
     Otwórz Ustawienia projektu, a następnie przejdź do karty Twoje aplikacje, aby wyświetlić wszystkie aplikacje Firebase i informacje o nich.

  2. W konsoli Google Cloud zmień nową „konfigurację przenoszenia danych”, która została utworzona podczas uaktualniania infrastruktury, tak aby dane były zapisywane w starszej tabeli:

     1. Aby wyświetlić „konfigurację transferu danych”, otwórz BigQuery > Transfery danych.

     2. Wybierz konfigurację, która ma źródło Firebase Crashlytics with Multi-Region Support.

     3. W prawym górnym rogu kliknij Edytuj.

     4. W sekcji Szczegóły źródła danych znajdź listę gmp_app_id i listę client_namespace.

        W BigQuery identyfikator aplikacji w Firebase jest nazywany gmp_app_id. Domyślnie wartość client_namespace w BigQuery to odpowiadający jej unikalny identyfikator pakietu lub nazwa pakietu aplikacji, ale zastąpisz tę konfigurację domyślną.

        BigQuery używa wartości client_namespace jako nazwy tabeli wsadowej, do której zapisuje każda połączona aplikacja w Firebase.

     5. Znajdź identyfikator gmp_app_id aplikacji w Firebase, dla której chcesz zastąpić ustawienia domyślne. Zmień wartość client_namespace na nazwę tabeli, w której aplikacja w Firebase ma zapisywać dane (zwykle jest to nazwa starszej tabeli, w której aplikacja zapisywała dane przy użyciu starszej infrastruktury eksportu).

        Uwaga: jeśli wcześniej dane były zapisywane w jednej tabeli, a po uaktualnieniu masz wiele tabel, możesz użyć tego samego client_namespace dla każdego odpowiedniego gmp_app_id. BigQuery zasadniczo scalą wszystkie tabele i zapiszą wszystkie dane ze wszystkich aplikacji w Firebase w tej jednej tabeli.

     6. Zapisz zmiany w konfiguracji.

  3. Zaplanuj uzupełnienie w przypadku dni, w których w starszej tabeli brakuje danych.

  4. Po zakończeniu uzupełniania usuń nową tabelę, która została automatycznie utworzona przez nową infrastrukturę eksportu.