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

W tabeli Problemy w przypadku niektórych problemów widoczne są różne formaty (a czasem „warianty”).

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 problemie, 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:

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 będą mogły być wysyłane do usługi Crashlytics tylko od użytkowników, którzy wyraźnie zgodzili się na zbieranie danych. Wpłynie to na dokładność danych dotyczących sesji bez 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 dane dotyczące 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 do Crashlytics danych o awariach, 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ą uczestnikom 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 zgłoszeniu, 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 powrócił?

Problem został zamknięty, ale Crashlytics otrzymał nowe zgłoszenie, że 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 kategoryzuje 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 Crashlytics nie wiedziało w momencie zamknięcia problemu (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 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 w momencie zamknięcia problemu nie wysłała żadnych raportów o awarii, Crashlytics uzna, że problem powrócił, i ponownie go otworzy.

Taka sytuacja może wystąpić, gdy naprawisz błąd i wydasz 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 awarii, gdy problem został zamknięty, a użytkownicy zaczną napotykać błąd, te raporty o awarii wywołają problem z regresją.

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

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

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 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 pamiętaj o dołączeniu logów.

Awarie są słabo symbolizowane

Jeśli zrzuty stosu wydają się być nieprawidłowo zsymbolizowane, 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 ramek (Missing) dla biblioteki aplikacji, sprawdź, czy na karcie dSYMs w Crashlytics w konsoli Firebase nie ma opcjonalnych plików dSYM wymienionych jako brakujące (w przypadku wersji aplikacji, której dotyczy problem). Jeśli tak, wykonaj czynności opisane w sekcji „Alert o braku dSYM” w Najczęstszych pytaniach dotyczących 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 masz pakiet 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.

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 błędów ANR (getHistoricalProcessExitReasons), jest bardziej niezawodny niż podejścia 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 w bibliotekach udostępnionych aplikacji brakuje tylko plików BuildId, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek udostępnionych. 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, 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 .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 narzędzia do zaciemniania kodu nie ujawniały rozszerzenia pliku, więc Crashlytics domyślnie generował każdy problem z rozszerzeniem pliku .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, dlatego 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 modernizuje pakiet SDK przez wycofanie obsługi 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 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 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:

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 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 przesyła tylko symbole z MY/NATIVE/LIBS, a uploadCrashlyticsSymbolFilesFeatureXRelease przesyła 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 o wartości "breakpad" (domyślna) 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 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ć niespójne zrzuty 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 zestawu 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 łańcucha narzędzi), spróbuj dodać do procesu kompilacji:

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

Ś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 wiersze:

  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?

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

Wyświetlanie niezsymbolizowanych zrzutów stosu aplikacji na Androida w panelu Crashlytics

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

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 edytora Unity Firebase automatycznie konfiguruje projekt Xcode pod kątem 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 Czytelne raporty o awariach.

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 żadna awaria, prawdopodobnie się zmniejszy, ale dane dotyczące tych użytkowników będą bardziej reprezentatywne dla wrażeń użytkowników końcowych związanych z Twoją aplikacją.

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 nieobsługiwanych 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 jest nazywany obsługą wyjątków).

Sprawdzoną metodą jest przechwytywanie i obsługiwanie wszystkich przewidywanych wyjątków, 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ą debugować problem.

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 tworzenia lub rozwiązywania problemów

  • Wydrukuj w konsoli Unity, używając 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 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.
• Przesłać wyjątek do Crashlytics jako zdarzenie krytyczne.
• 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
    //
}

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 do użytku w panelu Crashlytics 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.

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.

  • Eksport włączony 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 nazywa tabele wsadowe 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 w 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.

• W żadnej istniejącej „starszej” tabeli 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 BigQuery automatycznie dodawane są ciągi znaków _IOS lub _ANDROID, które wskazują platformę aplikacji.

^{* 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 ze wszystkich aplikacji.}

Opcje minimalizowania zakłóceń

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

• 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 wsadowej:
     Otwórz settings 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” utworzoną podczas uaktualniania infrastruktury, aby dane były zapisywane w starszej tabeli:

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

     2. Wybierz konfigurację ze źródłem 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ę domyślną konfigurację.

        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, w 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).

     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.