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

Widzisz różne formaty (a czasami „warianty”) niektórych problemów w tabeli Problemy.

W tabeli Problemy w 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 roku wprowadziliśmy ulepszony silnik analizy do grupowania zdarzeń, a także zaktualizowany wygląd i niektóre funkcje zaawansowane dotyczące nowych problemów (np. wariantów). Więcej informacji znajdziesz w naszym najnowszym poście na blogu. Najważniejsze informacje znajdziesz poniżej.

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

Aby grupować zdarzenia w te problemy, ulepszony silnik 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 w problemach warianty – każdy wariant to podgrupa zdarzeń w problemie, które mają ten sam punkt awarii i podobny ślad stosu. W przypadku wariantów możesz debugować najczęstsze ślady stosu w ramach problemu i określać, czy różne przyczyny źródłowe prowadzą do błędu.

Oto co zyskasz dzięki tym ulepszeniom:

• Odświeżone metadane wyświetlane w wierszu problemu
  Łatwiej jest teraz zrozumieć problemy w aplikacji i określić ich priorytet.

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

• Łatwiejsze debugowanie złożonych problemów o różnych przyczynach
  Używaj wariantów, aby debugować najczęstsze ślady 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 przeszukiwać, np. typ wyjątku i nazwę pakietu.

Wprowadzanie tych ulepszeń:

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

• Jeśli nie znajdziemy pasującego problemu, automatycznie zastosujemy do zdarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z odświeżonym projektem metadanych.

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

Nie widzisz logów elementów menu nawigacyjnego

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

• WłączonoGoogle Analytics w projekcie w Firebase.

• Udostępnianie danych zostało włączone w przypadku usługi Google Analytics. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych w Analytics.

• Do aplikacji został dodany pakiet SDK Firebase na platformę Google Analytics:iOS+ | Android | Flutter | Unity.
  Ten pakiet SDK musi zostać dodany oprócz pakietu Crashlytics SDK.

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

  W przypadku platform Apple i aplikacji na Androida sprawdź, czy używasz co najmniej tych wersji pakietu SDK Firebase na Google Analytics:iOS+ – v6.3.1+ (v8.9.0+ na macOS i tvOS) |Android – v17.2.3+ (BoM v24.7.1+).

Brak alertów dotyczących prędkości

Jeśli nie widzisz alertów o szybkości, sprawdź, czy używasz:

Brak danych o sesjach bez awarii (lub dane są niewiarygodne)

Jeśli nie widzisz danych o sesjach i użytkownikach bez awarii lub dane te są niewiarygodne, sprawdź:

• Upewnij się, że używasz:

• Sprawdź, czy ustawienia zbierania danych nie wpływają na jakość wskaźników dotyczących braku awarii:

  • Jeśli włączysz raportowanie oparte na zgodzie użytkowników przez wyłączenie automatycznego raportowania o awariach, informacje o awariach będą mogły być wysyłane do Crashlytics tylko od użytkowników, którzy wyraźnie zgodzili się na zbieranie danych. W związku z tym dokładność wskaźników dotyczących braku awarii będzie mniejsza, ponieważ Crashlytics ma informacje o awariach tylko od tych użytkowników, którzy wyrazili zgodę na ich udostępnianie (a nie od wszystkich użytkowników). Oznacza to, że wskaźniki dotyczące braku awarii mogą być mniej wiarygodne i mniej odzwierciedlać ogólną stabilność aplikacji.

  • Jeśli masz wyłączone automatyczne zbieranie danych, możesz użyć parametru sendUnsentReports, aby wysyłać do Crashlytics raporty zapisane w pamięci podręcznej na urządzeniu. Ta metoda spowoduje wysłanie danych o awariach do Crashlytics, ale nie danych o sesjach, co sprawi, że na wykresach w konsoli będą widoczne niskie lub zerowe wartości wskaźników bez awarii.

Jak oblicza się liczbę użytkowników, u których nie wystąpiły awarie?

Więcej informacji znajdziesz w artykule Interpretowanie danych o aplikacjach bez awarii.

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

Notatki umożliwiają członkom projektu komentowanie konkretnych problemów, zadawanie pytań, informowanie o stanie itp.

Gdy członek 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 wyświetlania notatki.

Poniżej opisujemy dostęp wymagany do wyświetlania, zapisywania i usuwania notatek:

• Członkowie 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 przypadku problemu, ale nie mogą ich usuwać ani pisać.

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

Co to jest problem z regresją?

Problem uległ regresji, gdy został wcześniej zamknięty, ale Crashlytics otrzymuje nowy raport, że problem wystąpił ponownie. Crashlytics automatycznie ponownie otwiera te problemy, aby umożliwić Ci podjęcie odpowiednich działań w przypadku Twojej aplikacji.

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 tego błędu (problem „A”).
2. Szybko usuwasz ten błąd, zamykasz zgłoszenie „A” i publikujesz nową wersję aplikacji.
3. Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po zamknięciu przez Ciebie tego problemu.
   • Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics wiedzieliśmy, gdy problem został zamknięty (co oznacza, że wersja wysłała raport o awarii w przypadku dowolnej awarii), Crashlytics nie uzna problemu za powracający. Zgłoszenie pozostanie zamknięte.
   • Jeśli raport pochodzi z wersji aplikacji, która Crashlytics nie znała problemu w momencie jego zamknięcia (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o awarii), Crashlytics uzna, że problem powrócił, i ponownie go otworzy.

Gdy problem powróci, wyślemy alert o wykryciu regresji i dodamy do niego sygnał regresji, aby poinformować Cię, że Crashlytics ponownie otworzył(-a) zgłoszenie. Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast go zamykać, „wycisz” go.

Dlaczego w starszych wersjach aplikacji widzę problemy z regresją?

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

Może to nastąpić w sytuacji, gdy po usunięciu błędu opublikujesz nową wersję aplikacji, ale niektórzy użytkownicy nadal będą korzystać ze starszych wersji, w których ten błąd występuje. Jeśli w jednej z wcześniejszych wersji nigdy nie wysyłano raportów o awariach, a użytkownicy zaczęli napotykać błąd, to te raporty o awariach spowodują ponowne wystąpienie problemu.

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

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 elementy:

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

2. Jeśli w Firebasekonsoli zobaczysz alert „Missing dSYM”, sprawdź w Xcode, czy prawidłowo generuje on pliki dSYM w przypadku kompilacji.

3. Jeśli Xcode prawidłowo generuje pliki dSYM, a mimo to widzisz brakujące pliki dSYM, prawdopodobnie narzędzie skryptu uruchamiania zawiesza się podczas przesyłania plików dSYM. W takim przypadku wypróbuj te rozwiązania:

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

   • Ręcznie prześlij brakujące pliki dSYM:

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

4. Jeśli nadal widzisz brakujące pliki dSYM lub przesyłanie nadal się nie udaje, skontaktuj się z zespołem pomocy Firebase i dołącz logi.

Awaria jest słabo zsymbolizowana

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

• Jeśli w klatkach z biblioteki aplikacji brakuje odwołań do kodu aplikacji, upewnij się, że -fomit-frame-pointer nie jest ustawiona jako flaga kompilacji.

• Jeśli w przypadku biblioteki aplikacji widzisz kilka ramek (Missing), sprawdź, czy na karcie Crashlytics dSYMs w Firebase konsoli (w przypadku wersji aplikacji, której dotyczy problem) nie ma opcjonalnych plików dSYM oznaczonych jako brakujące. Jeśli tak, wykonaj instrukcje rozwiązywania problemów z „alertem o braku dSYM” 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 w symbolizacji przyszłych awarii.

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

Tak, możesz zaimplementować Crashlytics w projektach na macOS i tvOS. Pamiętaj, aby uwzględnić pakiet SDK Firebase w wersji 8.9.0 lub nowszej dla Google Analytics, aby awarie miały dostęp do danych zebranych przez Google Analytics (użytkownicy bez awarii, najnowsza wersja, alerty o szybkości i dzienniki ścieżki).

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 rozdzielić je na osobne projekty Firebase.

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

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

Dlaczego niektóre ANR nie mają BuildId?

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

• Sprawdź, czy używasz aktualnej wersji Crashlyticspakietu Android SDK iCrashlytics wtyczki Gradle.

  Jeśli brakuje Ci BuildId dla Androida 11 i niektórych błędów ANR na Androidzie 12, prawdopodobnie używasz nieaktualnego pakietu SDK lub wtyczki Gradle albo obu tych elementów. Aby prawidłowo zbierać BuildId w przypadku 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)
  • Crashlytics Wtyczka Gradle w wersji 2.9.4 lub nowszej

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

  Jeśli brakuje Ci tylkoBuildIdw przypadku bibliotek udostępnionych aplikacji, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek udostępnionych. W takim przypadku Crashlytics może nie być w stanie zlokalizować powiązanych BuildId. Zalecamy używanie standardowej lokalizacji bibliotek współdzielonych.

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

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

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

  • Sprawdź, czy nie usuwasz przypadkowo znaków BuildId, aby zmniejszyć rozmiar pliku APK.

  • Jeśli masz wersje biblioteki z usuniętymi i nieusuniętymi symbolami, upewnij się, że w kodzie wskazujesz prawidłową wersję.

Różnice między raportami o błędach ANR na panelu Crashlytics a Konsolą 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, a Android Vitals wysyła dane o błędach ANR po ich wystąpieniu.

Dodatkowo Crashlytics wyświetla tylko błędy ANR występujące 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, na których użytkownicy wyrazili zgodę na zbieranie danych.

Dlaczego awarie z plików .kt są oznaczane jako problemy .java?

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

Aby Crashlytics mogło generować problemy z prawidłowym rozszerzeniem pliku, sprawdź, czy Twoja aplikacja jest skonfigurowana w ten sposób:

• korzysta z Androida Gradle w wersji 4.2.0 lub nowszej,
• Używa R8 z włączonym zaciemnianiem. Aby zaktualizować aplikację do wersji R8, zapoznaj się z tą dokumentacją.

Pamiętaj, że po zaktualizowaniu konfiguracji do opisanej powyżej możesz zacząć widzieć nowe problemy .kt, które są duplikatami istniejących problemów .java. Więcej informacji o tej sytuacji znajdziesz w najczęstszych pytaniach.

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

Od połowy grudnia 2021 r. Crashlyticsulepszyliśmy obsługę aplikacji korzystających z języka Kotlin.

Do niedawna dostępne narzędzia do zaciemniania nie ujawniały rozszerzenia pliku, więc Crashlytics domyślnie generowało 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ślać, czy każda klasa używana w aplikacji jest napisana w Kotlinie, i uwzględniać 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 korzysta z Androida Gradle w wersji 4.2.0 lub nowszej.
• Twoja aplikacja używa R8 z włączonym zaciemnianiem.

Ponieważ nowe awarie mają teraz w sygnaturach problemów prawidłowe rozszerzenie pliku, możesz zobaczyć nowe problemy .kt, które są w rzeczywistości duplikatami istniejących problemów oznaczonych etykietą .java. W Firebase konsoli próbujemy zidentyfikować i poinformować Cię, czy nowy .kt problem jest prawdopodobnie duplikatem istniejącego problemu oznaczonego etykietą .java.

Brak awarii w przypadku Dexguard

Jeśli zobaczysz 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 to naprawić:

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ć do reguł zaciemniania (w pliku konfiguracyjnym DexGuard) ten wiersz:

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

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

Najnowsza wersja Crashlyticswtyczki Gradle to wersja główna (3.0.0), która unowocześnia pakiet SDK, wycofując obsługę starszych wersji Gradle i wtyczki Androida do obsługi Gradle. Zmiany w tej wersji rozwiązują też problemy z AGP w wersji 8.1 lub nowszej i poprawiają obsługę aplikacji natywnych oraz niestandardowych kompilacji.

Wymagania minimalne

Wtyczka Gradle Crashlytics w wersji 3 ma te minimalne wymagania:

• 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 Gradle Firebase w wersji google-services4.4.1 lub nowszej
  Uaktualnij tę wtyczkę, podając najnowszą wersję w pliku kompilacji Gradle projektu, jak poniżej:

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

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 wersji 3 wtyczki Gradle Crashlytics rozszerzenie Crashlytics ma te zmiany powodujące niezgodność:

• Usunięto rozszerzenie z bloku defaultConfig na Androidzie. 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 w przypadku wszystkich bibliotek natywnych.

• Zmieniono pole unstrippedNativeLibsDir na pole 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 w MY/NATIVE/LIBS, a zadanie uploadCrashlyticsSymbolFilesFeatureXRelease prześle symbole w MY/NATIVE/LIBS i MY/FEATURE_X/LIBS.

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

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

Przykład uaktualniania rozszerzenia

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

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

Różnice między śladami stosu NDK na panelu Crashlytics a w logcat

Zestawy narzędzi LLVM i GNU mają różne ustawienia domyślne i sposoby obsługi segmentu tylko do odczytu w plikach binarnych aplikacji, co może generować niespójne ślady stosu w konsoli Firebase. Aby temu zapobiec, dodaj do procesu kompilacji te flagi linkera:

• Jeśli używasz linkera lld z zestawu narzędzi LLVM, dodaj:

  -Wl,--no-rosegment

• Jeśli używasz linkera ld.gold z zestawu narzędzi GNU, dodaj:

  -Wl,--rosegment

Jeśli nadal widzisz niespójności w śladzie stosu (lub jeśli żadna z tych flag nie jest odpowiednia dla Twojego łańcucha narzędzi), spróbuj zamiast tego dodać do procesu kompilacji te elementy:

-fno-omit-frame-pointer

Jak używać własnego pliku binarnego generatora plików symboli Breakpad w 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 na podstawie kodu źródłowego), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary, aby określić ścieżkę do pliku wykonywalnego.

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

  starsze wersje wtyczek,

  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ę za pomocą wiersza właściwości w pliku Gradle properties

  Ścieżkę do pliku wykonywalnego możesz określić za pomocą właściwości com.google.firebase.crashlytics.breakpadBinary.

  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ę za pomocą wiersza poleceń, użyj polecenia takiego jak to:

  ./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 architekturę armeabi?

Pakiet Firebase Crashlytics NDK nie obsługuje architektury ARMv5 (armeabi). Obsługa tego interfejsu ABI została wycofana w NDK r17.

Wyświetlanie w panelu Crashlytics nieprzetworzonych śladów stosu w przypadku aplikacji na Androida

Jeśli używasz Unity IL2CPP i widzisz niezasymboizowane ślady stosu, wykonaj te czynności:

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

2. Upewnij się, że masz skonfigurowane i uruchomione polecenie FirebaseCLIcrashlytics:symbols:upload, aby wygenerować i przesłać plik symboli.

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

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

Tak, Crashlytics może wyświetlać symboliczne ślady stosu w przypadku aplikacji, które korzystają z IL2CPP. Ta funkcja jest dostępna w przypadku aplikacji opublikowanych na platformach Android i 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 platformę Apple: nie musisz niczego robić. W przypadku aplikacji na platformę Apple wtyczka Firebase Unity Editor automatycznie konfiguruje projekt Xcode pod kątem przesyłania symboli.

   • W przypadku aplikacji na Androida: upewnij się, że masz skonfigurowane i uruchomione polecenie interfejsu wiersza poleceń Firebase crashlytics:symbols:upload, które służy do generowania i przesyłania pliku symboli.

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

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

Raportowanie nieobsłużonych wyjątków jako błędów krytycznych daje bardziej realistyczny obraz tego, które wyjątki mogą uniemożliwić grę, 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 ten wskaźnik będzie lepiej odzwierciedlać wrażenia użytkowników końcowych związane z Twoją aplikacją.

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

Aby Crashlytics zgłosił nieobsłużony wyjątek jako krytyczny, muszą być spełnione oba te warunki:

• Podczas inicjowania w aplikacji właściwość ReportUncaughtExceptionsAsFatal musi mieć wartość true.

• Aplikacja (lub dołączona biblioteka) zgłasza nieobsłużony wyjątek. Wyjątek, który został utworzony, ale nie został zgłoszony, nie jest uznawany za nieobsłużony.

Po włączeniu zgłaszania nieobsłużonych 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 nieobsłużonych wyjątkach jako o 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 nieobsłużone wyjątki.
• Rozważ różne opcje rejestrowania 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 w celu odzwierciedlenia nieoczekiwanych lub wyjątkowych stanów. Rozwiązanie problemów odzwierciedlonych przez zgłoszony wyjątek polega na przywróceniu programu do znanego stanu (proces ten jest znany jako obsługa wyjątków).

Sprawdzoną metodą jest przechwytywanie i obsługiwanie wszystkich przewidywanych wyjątków, chyba że program nie może zostać przywrócony do znanego stanu.

Aby określić, jakie rodzaje wyjątków mają być przechwytywane i obsługiwane przez dany kod, otocz kod, który może wygenerować wyjątek, blokiem 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

Wyjątki w Unity lub Crashlytics możesz rejestrować na kilka sposobów, aby ułatwić sobie debugowanie problemu.

W przypadku korzystania z Crashlytics masz do wyboru 2 najpopularniejsze i zalecane opcje:

• Opcja 1. Drukowanie w konsoli Unity, ale nie wysyłanie raportów do Crashlytics podczas programowania lub rozwiązywania problemów

  • Drukowanie w konsoli Unity za pomocą funkcji Debug.Log(exception), Debug.LogWarning(exception) i Debug.LogError(exception), które drukują zawartość wyjątku w konsoli Unity i nie zgłaszają go ponownie.

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

  • Jeśli wyjątek warto zarejestrować, aby debugować możliwe kolejne Crashlytics zdarzenie, użyj Crashlytics.Log(exception.ToString()).
  • Jeśli wyjątek powinien być nadal zgłaszany do Crashlytics pomimo jego przechwycenia i obsłużenia, użyj Crashlytics.LogException(exception), aby zarejestrować go jako zdarzenie niekrytyczne.

Jeśli jednak chcesz ręcznie zgłosić krytyczne zdarzenie do Unity Cloud Diagnostics, możesz użyć metody Debug.LogException. Ta opcja drukuje wyjątek w konsoli Unity, tak jak opcja 1, ale również zgłasza wyjątek (niezależnie od tego, czy został już zgłoszony lub przechwycony). Zgłasza błąd nielokalnie. Oznacza to, że nawet otaczający blok Debug.LogException(exception) z blokami try-catch nadal powoduje nieobsłużony wyjątek.

Dlatego zadzwoń pod numer Debug.LogException tylko wtedy, gdy chcesz wykonać wszystkie z tych czynności:

• Aby wydrukować wyjątek w konsoli Unity.
• Aby przesłać wyjątek do Crashlytics jako zdarzenie krytyczne.
• Aby zgłosić wyjątek, potraktuj go jako nieobsłużony i zgłoś go do Unity Cloud Diagnostics.

Jeśli chcesz wydrukować przechwycony wyjątek w konsoli Unity i 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
    //
}

Aplikacja używa też pakietu SDK Google Mobile Ads, ale nie powoduje awarii

Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK Google Mobile Ads, prawdopodobnie rejestratory awarii przeszkadzają w rejestrowaniu procedur obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK Mobile Ads, wywołując funkcję 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 eksportowanie danych o sesjach jest włączone).

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

• Po utworzeniu zbioru danych nie można zmienić jego lokalizacji. 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 istniejących eksportów.

Problemy po przejściu na nową infrastrukturę eksportu w przypadku BigQuery?

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

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

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

• Nowa infrastruktura obsługuje Crashlytics lokalizacji zbiorów danych 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 eksportu 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 BigQuerynazywa tabele zbiorcze, używając identyfikatorów ustawionych dla aplikacji w Firebase w projekcie w Firebase.

  • Stara infrastruktura zapisywała dane w tabelach zbiorczych o nazwach opartych na identyfikatorach pakietu 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 partii nie pasowała do identyfikatora pakietu lub nazwy pakietu ustawionych dla zarejestrowanej aplikacji Firebase, wdróż jedną z tych opcji, aby uniknąć dalszych zakłóceń w eksportowanych danych partii.

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

Oto jak 2 infrastruktury eksportu zapisują dane Crashlytics w tabelach wsadowych:BigQuery

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

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

Czasami jednak identyfikator pakietu lub nazwa pakietu w binarnej wersji aplikacji nie pasuje do identyfikatora pakietu lub nazwy pakietu ustawionych dla zarejestrowanej aplikacji Firebase w projekcie Firebase. Zazwyczaj 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 lokalizacjach nie pasują do siebie, oznacza to, że:

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

• Do żadnej z dotychczasowych „starszych” tabel o nazwie opartej na identyfikatorze w pliku binarnym aplikacji nie są już zapisywane dane.

Przykładowe scenariusze niedopasowanych identyfikatorów

Pamiętaj, że do nazw tabel zbiorczych automatycznie dodawane są znaki BigQuery _IOS lub _ANDROID, aby wskazać platformę aplikacji.

^{* Jeśli identyfikator w pliku binarnym aplikacji pasował do jednego z identyfikatorów ustawionych dla aplikacji Firebase, nowa infrastruktura eksportu nie utworzyła dla tego identyfikatora nowej tabeli. Zamiast tego będzie nadal zapisywać w niej dane z 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 Firebase, nowa infrastruktura eksportu nie utworzyła nowej tabeli. Zamiast tego zachowa tę tabelę i zacznie zapisywać w niej dane ze wszystkich aplikacji.}

Opcje ograniczenia zakłóceń

• OPCJA 1:
  użyj nowej tabeli utworzonej przez nową infrastrukturę eksportu. Skopiujesz dane ze starej tabeli do nowej.

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

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

• OPCJA 2:
  ponownie skonfiguruj zapisywanie danych w starszej tabeli. Aby to zrobić, musisz zastąpić niektóre ustawienia domyślne w konfiguracji BigQuery.

  1. W Firebase konsoli znajdź i zanotuj identyfikator aplikacji Firebase (np. 1:1234567890:ios:321abc456def7890) aplikacji z niepasującą nazwą tabeli zbiorczej i identyfikatorem:
     otwórz settings Ustawienia projektu, a następnie kartę Twoje aplikacje, aby wyświetlić wszystkie aplikacje Firebase i ich informacje.

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

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

     2. Wybierz konfigurację, która ma źródłoFirebase 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 Firebase jest nazywany gmp_app_id. Domyślnie wartość client_namespace w parametrze BigQuery to odpowiedni unikalny identyfikator pakietu lub nazwa pakietu aplikacji, ale zastąpisz tę konfigurację domyślną.

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

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

     6. Zapisz zmianę konfiguracji.

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

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