Eksportowanie danych z Firebase Crashlytics do BigQuery

Możesz wyeksportować dane z Firebase Crashlytics do BigQuery w celu dalszej analizy. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, eksportowanie ich do innego dostawcy usług w chmurze oraz używanie ich do wizualizacji i tworzenia niestandardowych paneli w Studiu danych Google.

Włącz eksportowanie do BigQuery

1. W konsoli Firebase otwórz stronę Integracje.

2. Na karcie BigQuery kliknij Połącz.

3. Aby włączyć eksportowanie do BigQuery, postępuj zgodnie z instrukcjami wyświetlanymi na ekranie.

   Jeśli chcesz mieć dostęp do danych Crashlytics w BigQuery w czasie zbliżonym do rzeczywistego, rozważ przejście na eksport strumieniowy.

Co się stanie, gdy włączysz eksportowanie?

• Wybierz lokalizację zbioru danych. Gdy zbiór danych zostanie 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 Zmiana lokalizacji w przypadku dotychczasowych eksportów.

  Ta lokalizacja ma zastosowanie tylko do danych eksportowanych do BigQuery i nie wpływa na lokalizację danych przechowywanych do użytku w panelu Crashlytics w konsoli Firebase ani w Android Studio.

• Domyślnie wszystkie aplikacje w projekcie są połączone z BigQuery. Wszystkie aplikacje, które dodasz do projektu później, także zostaną automatycznie połączone z BigQuery. Możesz określić, które aplikacje mają wysyłać dane.

• Firebase konfiguruje codzienne synchronizacje danych z BigQuery.

  • Po połączeniu projektu zwykle musisz poczekać do następnego dnia, aż pierwsza grupa danych zostanie wyeksportowana do BigQuery.

  • Synchronizacja dzienna odbywa się raz dziennie, niezależnie od zaplanowanego eksportu, który możesz skonfigurować w BigQuery. Pamiętaj, że czas i długość trwania zadania synchronizacji mogą się zmieniać, dlatego nie zalecamy planowania operacji ani zadań podrzędnych na podstawie konkretnego czasu eksportu.

• Firebase eksportuje kopię Twoich dotychczasowych danych do BigQuery. Początkowe rozpowszechnianie danych na potrzeby eksportu może potrwać do 48 godzin.

  • W przypadku każdej połączonej aplikacji ten eksport obejmuje tabelę zbiorczą zawierającą dane z codziennej synchronizacji.

  • Możesz ręcznie zaplanować uzupełnianie danych w tabeli zbiorczej z okresu do 30 dni wstecz lub z najnowszego dnia, w którym włączono eksportowanie do BigQuery (w zależności od tego, która data jest najnowsza).

  Jeśli przed połową października 2024 r. włączysz eksportowanie danych Crashlytics, możesz też uzupełnić dane z okresu 30 dni przed dniem, w którym włączysz eksportowanie.

• Jeśli włączyszCrashlytics eksport strumieniowy do BigQuery, wszystkie połączone aplikacje będą też miały tabelę w czasie rzeczywistym zawierającą stale aktualizowane dane.

Aby dezaktywować eksport do BigQuery, odłącz projekt w konsoli Firebase.

Jakie dane są eksportowane do BigQuery?

Dane z Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie firebase_crashlytics. Domyślnie w zbiorze danych Crashlytics będą tworzone osobne tabele dla każdej aplikacji w projekcie. Firebase nadaje tabelom nazwy na podstawie identyfikatora aplikacji, przy czym kropki są zamieniane na podkreślenia, a na końcu dodawana jest nazwa platformy.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test znajdowałyby się w tabeli o nazwie com_google_test_ANDROID. Ta tabela zbiorcza jest aktualizowana raz dziennie. Jeśli włączysz Crashlyticseksport strumieniowy doBigQuery, Crashlyticsdane będą też przesyłane strumieniowo w czasie rzeczywistymcom_google_test_ANDROID_REALTIME do tabeli o nazwie com_google_test_ANDROID_REALTIME.

Każdy wiersz w tabeli reprezentuje zdarzenie, które wystąpiło w aplikacji, w tym awarie, niekrytyczne błędy i błędy ANR.

Crashlytics eksport strumieniowy do BigQuery

Dane Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym za pomocą BigQuery strumieniowania. Możesz go używać do dowolnych celów, które wymagają danych na żywo, np. do prezentowania informacji w panelu na żywo, śledzenia wdrożenia na żywo lub monitorowania problemów z aplikacjami, które wywołują alerty i niestandardowe przepływy pracy.

Gdy włączysz Crashlyticseksport strumieniowy do BigQuery, oprócz tabeli zbiorczej będziesz mieć też tabelę w czasie rzeczywistym. Oto różnice między tabelami, o których warto pamiętać:

Tabela zbiorcza idealnie nadaje się do analizy długoterminowej i identyfikowania trendów w czasie, ponieważ trwale przechowujemy zdarzenia przed ich zapisaniem i możemy je uzupełniać w tabeli przez maksymalnie 30 dni*. Gdy zapisujemy dane w tabeli czasu rzeczywistego, od razu zapisujemy je w BigQuery, dlatego idealnie nadaje się ona do paneli na żywo i alertów niestandardowych. Te 2 tabele można połączyć za pomocą zapytania o łączenie, aby uzyskać korzyści z obu tych rozwiązań.

Domyślnie tabela czasu rzeczywistego ma czas ważności partycji wynoszący 30 dni. Aby dowiedzieć się, jak to zmienić, zapoznaj się z sekcją Ustawianie wygaśnięcia partycji w dokumentacji BigQuery.

^{* Szczegółowe informacje o obsłudze wypełniania pustych miejsc znajdziesz w artykule Przejście na nową infrastrukturę eksportu.}

Włącz eksportowanie strumieniowe Crashlytics do BigQuery

1. W konsoli Firebase otwórz stronę Integracje.

2. Na karcie BigQuery kliknij Zarządzaj.

3. Zaznacz pole wyboru Uwzględnij streaming.

To działanie włącza przesyłanie strumieniowe we wszystkich połączonych aplikacjach.

Co można zrobić z wyeksportowanymi danymi?

Eksporty do BigQuery zawierają nieprzetworzone dane o awariach, w tym typ urządzenia, system operacyjny, wyjątki (aplikacje na Androida) lub błędy (aplikacje na urządzenia Apple) oraz Crashlytics dzienniki, a także inne dane.

W dalszej części tej strony znajdziesz informacje o tym, jakie dane Crashlytics są eksportowane i jaki jest schemat tabeli.

Używanie szablonu Studia danych

Aby włączyć dane w czasie rzeczywistym w szablonie Studia danych, postępuj zgodnie z instrukcjami w artykule Wizualizowanie wyeksportowanych danych Crashlytics za pomocą Studia danych.

Tworzenie widoków

Zapytania możesz przekształcać w widoki za pomocą interfejsu BigQuery. Szczegółowe instrukcje znajdziesz w artykule Tworzenie widoków w BigQuerydokumentacji.

Uruchamianie zapytań

Poniższe przykłady pokazują zapytania, które możesz uruchamiać na swoich danych Crashlytics, aby generować raporty agregujące dane o awariach w łatwiejsze do zrozumienia podsumowania. Tego typu raporty nie są dostępne na Crashlytics panelu Firebase konsoli, więc mogą uzupełniać analizę i zrozumienie danych o awariach.

Przykład 1. Awarie według dnia

Po usunięciu jak największej liczby błędów uważasz, że Twój zespół jest wreszcie gotowy do wprowadzenia na rynek nowej aplikacji do udostępniania zdjęć. Zanim to zrobisz, chcesz sprawdzić liczbę awarii dziennie w ostatnim miesiącu, aby upewnić się, że sesja usuwania błędów sprawiła, że aplikacja stała się z czasem bardziej stabilna.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Przykład 2. Znajdowanie najczęstszych awarii

Aby prawidłowo ustalić priorytety planów produkcyjnych, chcesz znaleźć 10 najczęstszych awarii w aplikacji. Tworzysz zapytanie, które dostarcza odpowiednie punkty danych.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Przykład 3. 10 urządzeń, na których najczęściej dochodzi do awarii

Jesień to sezon nowych telefonów! W Twojej firmie wiedzą, że oznacza to również sezon problemów związanych z nowymi urządzeniami – zwłaszcza z Androidem. Aby uniknąć problemów ze zgodnością, tworzysz zapytanie, które identyfikuje 10 urządzeń, na których w ostatnim tygodniu (168 godzin) wystąpiło najwięcej awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Przykład 4. Filtrowanie według klucza niestandardowego

Jesteś deweloperem gier i chcesz wiedzieć, na którym poziomie gry występuje najwięcej awarii.

Aby śledzić tę statystykę, ustawiasz niestandardowy klucz Crashlytics o nazwie current_level i aktualizujesz go za każdym razem, gdy użytkownik osiągnie nowy poziom.

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Po wyeksportowaniu tego klucza do BigQuery możesz napisać zapytanie, które będzie raportować rozkład wartości current_level powiązanych z każdym zdarzeniem awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Przykład 5. Wyodrębnianie identyfikatora użytkownika

Masz aplikację na Androida w ramach wcześniejszego dostępu. Większość użytkowników jest zadowolona, ale u 3 osób wystąpiła nietypowo duża liczba awarii. Aby rozwiązać ten problem, piszesz zapytanie, które pobiera wszystkie zdarzenia awarii dotyczące tych użytkowników, korzystając z ich identyfikatorów.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id
 

Przykład 6. Znajdowanie wszystkich użytkowników, u których występuje konkretny problem z awarią

Twój zespół przypadkowo udostępnił krytyczny błąd grupie beta-testerów. Twój zespół mógł użyć zapytania z przykładu „Znajdź najczęstsze awarie” powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Teraz Twój zespół chce uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji, których dotyczył ten błąd.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

Przykład 7. Liczba użytkowników, których dotyczy problem z awarią, według kraju

Podczas wdrażania nowej wersji Twój zespół wykrył krytyczny błąd. Używając zapytania z przykładu „Znajdź najczęstsze awarie” powyżej, udało Ci się zidentyfikować konkretny identyfikator problemu z awarią. Twój zespół chce teraz sprawdzić, czy ten błąd występuje też u użytkowników w innych krajach na świecie.

Aby napisać to zapytanie, Twój zespół musi wykonać te czynności:

1. Włącz eksportowanie danych z Google Analytics do BigQuery. Więcej informacji znajdziesz w artykule Eksportowanie danych projektu do BigQuery.

2. Zaktualizuj aplikację, aby przekazywała identyfikator użytkownika do pakietu SDK Google Analytics i pakietu SDK Crashlytics.

   Swift

   Crashlytics.sharedInstance().setUserIdentifier("123456789");
   Analytics.setUserID("123456789");
   

   Objective-C

   CrashlyticsKit setUserIdentifier:@"123456789";
   FIRAnalytics setUserID:@"12345678 9";
   

   Java

   Crashlytics.setUserIdentifier("123456789");
   mFirebaseAnalytics.setUserId("123456789");
   

3. Napisz zapytanie, które używa pola identyfikatora użytkownika do łączenia zdarzeń w zbiorze danych Google Analytics z awariami w zbiorze danych Crashlytics.

   Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

   SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
   FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
   INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
   WHERE
     c.issue_id = "ISSUE_ID"
     AND a._TABLE_SUFFIX BETWEEN '20190101'
     AND '20200101'
   GROUP BY
     c.issue_id,
     a.geo.country,
     c.user.id

Przykład 8. 5 najczęstszych problemów do tej pory

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Przykład 9. 5 najczęstszych problemów od DATE, w tym dzisiaj

Możesz też połączyć tabele przetwarzane wsadowo i w czasie rzeczywistym za pomocą zapytania łączącego, aby dodać informacje w czasie rzeczywistym do wiarygodnych danych przetwarzanych wsadowo. Ponieważ event_id jest kluczem podstawowym, możesz użyć DISTINCT event_id, aby usunąć duplikaty wszystkich wspólnych zdarzeń z obu tabel.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i IOS (zamiast nazwy pakietu i ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Omówienie schematu Crashlytics w BigQuery

Gdy skonfigurujesz Crashlytics eksport danych do BigQuery Firebase, usługa ta będzie eksportować najnowsze zdarzenia (awarie, błędy niekrytyczne i błędy ANR), w tym zdarzenia z okresu do 2 dni przed utworzeniem połączenia. Możesz też wstecznie wypełnić dane z okresu do 30 dni.

Od tego momentu do czasu dezaktywacji eksportu Firebase będzie codziennie eksportować zdarzeniaCrashlytics. Po każdym eksporcie dane mogą być dostępne w BigQuery dopiero po kilku minutach.

Zbiory danych

Crashlytics tworzy w BigQuery nowy zbiór danych na potrzeby Crashlytics danych. Zbiór danych obejmuje cały projekt, nawet jeśli zawiera on wiele aplikacji.

Tabele

Crashlytics tworzy w zbiorze danych tabelę dla każdej aplikacji w Twoim projekcie, chyba że zrezygnujesz z eksportowania danych z danej aplikacji. Firebase nadaje tabelom nazwy na podstawie identyfikatora aplikacji, przy czym kropki są zamieniane na podkreślenia, a na końcu dodawana jest nazwa platformy.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test znajdą się w tabeli o nazwie com_google_test_ANDROID, a dane w czasie rzeczywistym (jeśli są włączone) – w tabeli o nazwie com_google_test_ANDROID_REALTIME.

Tabele zawierają standardowy zestaw Crashlytics danych oraz wszystkie niestandardowe Crashlytics klucze zdefiniowane przez Ciebie w aplikacji.

Wiersze

Każdy wiersz w tabeli odpowiada błędowi, który wystąpił w aplikacji.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, niekrytycznych błędów i błędów ANR. Jeśli włączony jest Crashlyticseksport strumieniowy do BigQuery, tabela w czasie rzeczywistym będzie miała takie same kolumny jak tabela wsadowa. Pamiętaj, że w wierszach mogą występować kolumny reprezentujące zdarzenia, które nie mają śladów stosu.

Kolumny w ramach eksportu są wymienione w tej tabeli:

Wizualizacja wyeksportowanych danych Crashlytics za pomocą Studia danych

Studio danych Google przekształca Crashlyticszbiory danychBigQuery w raporty, które są łatwiejsze do odczytania i udostępnienia oraz w pełni konfigurowalne.

Aby dowiedzieć się więcej o korzystaniu ze Studia danych, zapoznaj się z przewodnikiem Szybki start w Studiu danych: Witamy w Studiu danych.

Używanie szablonu raportu Crashlytics

Data Studio ma przykładowy raport dotyczący Crashlytics, który zawiera pełny zestaw wymiarów i danych z wyeksportowanego schematu Crashlytics BigQuery. Jeśli masz włączony Crashlyticseksport strumieniowy do BigQuery, możesz wyświetlić te dane na stronie Trendy w czasie rzeczywistym w szablonie Studia danych.Możesz użyć próbki jako szablonu, aby szybko tworzyć nowe raporty i wizualizacje na podstawie nieprzetworzonych danych o awariach w Twojej aplikacji:

1. Otwórz Crashlytics szablon panelu Studia danych.

2. W prawym górnym rogu kliknij Użyj szablonu.

3. W menu Nowe źródło danych kliknij Utwórz nowe źródło danych.

4. Na karcie BigQuery kliknij Wybierz.

5. Wybierz tabelę zawierającą wyeksportowane dane Crashlytics, klikając Moje projekty > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   Tabela plików wsadowych jest zawsze dostępna do wyboru. Jeśli masz włączony eksport strumieniowy do BigQuery, możesz zamiast tego wybrać tabelę czasu rzeczywistego.Crashlytics

6. W sekcji Konfiguracja ustaw Crashlytics Poziom szablonu na Domyślny.

7. Aby utworzyć nowe źródło danych, kliknij Połącz.

8. Kliknij Dodaj do raportu, aby wrócić do szablonu Crashlytics.

9. Na koniec kliknij Utwórz raport, aby utworzyć kopię szablonu Crashlyticspanelu Studia danych.

Przejście na nową infrastrukturę eksportu

W połowie października 2024 r. Crashlytics wprowadziła nową infrastrukturę do zbiorczego eksportowania danych Crashlytics do BigQuery.

Wszystkie projekty Firebase zostaną automatycznie uaktualnione do nowej infrastruktury eksportu zbiorczego już 15 września 2025 r. Możesz przekształcić kampanię przed tą datą, ale upewnij się, że tabele plików wsadowych BigQuery spełniają wymagania wstępne dotyczące przekształcenia.

Możesz uaktualnić infrastrukturę, ale upewnij się, że tabele wsadowe BigQuery spełniają wymagania wstępne dotyczące uaktualnienia.

Sprawdzanie, czy korzystasz z nowej infrastruktury

Jeśli eksportowanie zbiorcze zostało włączone w połowie października 2024 r. lub później, projekt Firebase automatycznie korzysta z nowej infrastruktury eksportu.

Możesz sprawdzić, z której infrastruktury korzysta Twój projekt: otwórz Google Cloudkonsolę, a jeśli „konfiguracja transferu danych” jest oznaczona symbolem Firebase Crashlytics with Multi-Region Support, oznacza to, że Twój projekt korzysta z nowej infrastruktury eksportu.

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

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

  • Eksportowanie włączone przed połową października 2024 r. i uaktualnione 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ł się monit o wybranie lokalizacji na potrzeby eksportowania danych.

• Nowa infrastruktura nie obsługuje uzupełniania danych z okresu przed włączeniem eksportu.

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

  • Nowa infrastruktura obsługuje wypełnianie wsteczne do 30 dni wstecz lub do najnowszej daty, w której włączono eksport do BigQuery (w zależności od tego, która z tych dat jest późniejsza).

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

  • Stara infrastruktura zapisywała dane w tabelach zbiorczych o nazwach opartych na identyfikatorach pakietów w konfiguracji Firebase w kodzie aplikacji.

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

Krok 1. Wymagania wstępne dotyczące przejścia na wyższą wersję

1. Sprawdź, czy istniejące tabele zbiorcze BigQuery używają identyfikatorów zgodnych z identyfikatorami pakietów lub nazwami pakietów ustawionymi dla zarejestrowanych aplikacji Firebase w projekcie Firebase. Jeśli się nie zgadzają, może to spowodować zakłócenia w wyeksportowanych danych zbiorczych. Większość projektów będzie w odpowiednim i kompatybilnym stanie, ale przed uaktualnieniem warto to sprawdzić.

   • Wszystkie aplikacje Firebase zarejestrowane w projekcie Firebase znajdziesz w Firebasekonsoli: otwórz settings Ustawienia projektu, a następnie przewiń do karty Twoje aplikacje, aby wyświetlić wszystkie aplikacje Firebase i ich informacje.

   • Wszystkie tabele wsadowe BigQuery znajdziesz na BigQuerystronie w konsoli Google Cloud.

   Oto przykłady idealnych stanów, w których nie będziesz mieć problemów z aktualizacją:

   • Masz tabelę zbiorczą o nazwie com_yourcompany_yourproject_IOS i aplikację Firebase na iOS+ o identyfikatorze pakietu com.yourcompany.yourproject zarejestrowaną w projekcie Firebase.

   • Masz tabelę zbiorczą o nazwie com_yourcompany_yourproject_ANDROID i aplikację Firebase na Androida o nazwie pakietu com.yourcompany.yourproject zarejestrowaną w projekcie Firebase.

2. Jeśli nazwy tabel wsadowych nie odpowiadają identyfikatorom ustawionym dla zarejestrowanych aplikacji Firebase, wykonaj instrukcje podane w dalszej części tej strony przed ręcznym przejściem na wyższą wersję lub przed 15 września 2025 r., aby uniknąć przerw w eksportowaniu wsadowym.

Krok 2. Ręcznie uaktualnij infrastrukturę

Jeśli eksportowanie zbiorcze zostało włączone przed połową października 2024 r., możesz ręcznie przejść na nową infrastrukturę, wyłączając, a następnie ponownie włączając eksport danych Crashlytics w konsoli Firebase.

Aby to zrobić:

1. W konsoli Firebase otwórz stronę Integracje.

2. Na karcie BigQuery kliknij Zarządzaj.

3. Aby wyłączyć eksportowanie, przesuń suwak Crashlytics. Gdy pojawi się odpowiedni komunikat, potwierdź, że chcesz zatrzymać eksportowanie danych.

4. Od razu ponownie włącz suwak Crashlytics, aby ponownie włączyć eksportowanie. Gdy pojawi się prośba, potwierdź, że chcesz wyeksportować dane.

   eksport danych Crashlytics do BigQuery odbywa się teraz przy użyciu nowej infrastruktury eksportu.

Nazwa dotychczasowej tabeli zbiorczej nie pasuje do identyfikatora aplikacji Firebase