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

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

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 silnik analizy do grupowania zdarzeń, a także zaktualizowany wygląd i niektóre zaawansowane funkcje dotyczące nowych problemów (np. wariantów). Więcej szczegółów znajdziesz w naszym ostatnim poście na blogu, ale 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 według tych problemów, 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ń ślady 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 ramach problemu, 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 sprawdzać, czy różne główne przyczyny prowadzą do niepowodzenia.

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 duplikatów
  Zmiana numeru wiersza nie powoduje utworzenia 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.

Oto jak wprowadzamy te ulepszenia:

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

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

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.

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 te wymagania:

• W projekcie w Firebase włączono Google Analytics.

• Włączono udostępnianie danych 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 Google Analytics:iOS+ | Androida | Fluttera | Unity.
  Ten pakiet SDK musi zostać dodany oprócz pakietu SDK Crashlytics.

• 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+ – 6.3.1+ (8.9.0+ w przypadku macOS i tvOS) | Android – 17.2.3+ (BoM 24.7.1+).

Brak alertów o rosnącej liczbie problemów

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 bezawaryjnej pracy (np. użytkowników i sesji bez awarii) lub widzisz dane, którym nie możesz zaufać, sprawdź te kwestie:

• 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, wyłączając automatyczne raportowanie awarii, informacje o awariach będą mogły być wysyłane do Crashlytics tylko przez użytkowników, którzy wyraźnie zgodzili się na zbieranie danych. W związku z tym dokładność danych o braku awarii będzie mniejsza, ponieważ Crashlytics będzie mieć informacje o awariach tylko od tych użytkowników (a nie od wszystkich). Oznacza to, że dane o 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 wysyła dane o awariach do Crashlytics, ale nie wysyła danych o sesjach, co powoduje, że na wykresach w konsoli wskaźniki bez awarii mają niskie lub zerowe wartości.

Jak obliczany jest współczynnik użytkowników, u których nie wystąpił błąd?

Zobacz Informacje o danych dotyczących braku awarii.

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

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

Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona adresem e-mail powiązanym z jego kontem Google. Ten adres e-mail będzie 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:

• Uczestnicy 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, aleCrashlytics otrzymano nowy raport o jego ponownym wystąpieniu. 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. Problem pozostanie zamknięty.
   • 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ł problem. Jeśli nie chcesz, aby problem został ponownie otwarty z powodu działania 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 po zamknięciu problemu nigdy nie wysyłała raportów o awariach, Crashlytics uzna, że problem powrócił, i ponownie go otworzy.

Taka sytuacja może wystąpić, gdy naprawisz błąd i udostępnisz nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji, w których ten błąd nie został naprawiony. Jeśli przypadkiem jedna z tych starszych wersji nigdy nie wysyłała raportów o awariach, gdy problem został zamknięty, a użytkownicy zaczęli napotykać ten błąd, te raporty o awariach spowodują ponowne otwarcie problemu.

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

Brak plików dSYM lub nie są one przesyłane

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ę w 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 powodzi, skontaktuj się z zespołem pomocy Firebase i dołącz do zgłoszenia swoje 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, sprawdź, czy -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 nie ma opcjonalnych plików dSYM oznaczonych jako brakujące (w przypadku danej wersji aplikacji). Jeśli tak jest, wykonaj czynności opisane w sekcji „Alert o brakujących plikach dSYM” w tym artykule. 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 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żek).

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

W jednym projekcie w Firebase możesz teraz raportować awarie wielu aplikacji, nawet jeśli są one 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 rozdzielać na osobne projekty w 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 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:

• Sprawdź, czy używasz aktualnej wersji Crashlyticspakietu Android SDK i Crashlyticswtyczki Gradle.

  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 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 zasobów wspólnych.

• Sprawdź, czy 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 readelf -n w plikach binarnych. Jeśli nie ma flagi 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 Crashlyticspanelu 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, w przeciwieństwie do Google Play, które wyświetla błędy ANR z urządzeń z usługami Google Play i 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, usługa Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java.

Aby narzędzie Crashlytics mogło generować problemy z prawidłowym rozszerzeniem pliku, upewnij się, że Twoja aplikacja korzysta z tej konfiguracji:

• 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 w sposób opisany 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ę problemy .kt, które są duplikatami istniejących problemów .java?

Od połowy grudnia 2021 r. Crashlyticsulepszona obsługa aplikacjiCrashlytics korzystających z języka Kotlin.

Do niedawna dostępne zaciemniacze nie ujawniały rozszerzenia pliku, więc Crashlyticsdomyślnie generowały każdy problem 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 języku Kotlin, 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 aplikacja ma następującą konfigurację:

• Aplikacja korzysta z Androida Gradle w wersji 4.2.0 lub nowszej.
• Twoja aplikacja używa R8 z włączonym zaciemnianiem.

Nowe awarie zawierają teraz w swoich sygnaturach problemów prawidłowe rozszerzenie pliku, więc 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 wykrywać i informować Cię, czy nowy .kt problem jest możliwym duplikatem istniejącego problemu oznaczonego etykietą .java.

Brak awarii w przypadku Dexguard

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

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

Ten wyjątek nie powoduje awarii aplikacji, ale uniemożliwia 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 wtyczkę Gradle w wersji Crashlytics?

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 w wersji 3 (Crashlytics) 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 Androida Studio.

• Wtyczka Gradle Firebase w wersji google-services4.4.1 lub nowszej
  Aby uaktualnić tę wtyczkę, w pliku kompilacji Gradle projektu określ najnowszą wersję, np.:

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

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

Zmiany w rozszerzeniu Crashlytics

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

• Usunęliśmy rozszerzenie z bloku defaultConfig android. Zamiast tego skonfiguruj każdą odmianę.

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

• Usunięto wycofane pole strippedNativeLibsDir. Zamiast tego w przypadku wszystkich bibliotek natywnych używaj unstrippedNativeLibsDir.

• Pole unstrippedNativeLibsDir zostało zmienione na pole skumulowane.

  Przykład 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 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 o wartości "breakpad" (domyślna) lub "csym".
  • breakpadBinary, plik lokalnego dump_syms zastąpienia binarnego.

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 logcat

Łańcuchy 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 Firebase konsoli. 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 ten kod:

-fno-omit-frame-pointer

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

Wtyczka Crashlytics zawiera dostosowany 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 1 z 2 sposobów:

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

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

  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 usunięta w NDK w wersji r17.

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

Jeśli używasz Unity IL2CPP i widzisz niezasymbolizowane ślady stosu, spróbuj wykonać 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ę do publikacji lub inną wersję, w przypadku której chcesz wyświetlać zsymbolizowane zrzuty stosu w Firebase. 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ć zsymbolizowane ślady stosu w przypadku aplikacji, które korzystają z IL2CPP. Ta funkcja jest dostępna w przypadku aplikacji opublikowanych na platformach Android i Apple. Aby z niej skorzystać, wykonaj te czynności:

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

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

   • W przypadku aplikacji na platformę Apple: nie musisz podejmować żadnych specjalnych działań. W przypadku aplikacji na platformę Apple wtyczka Firebase Unity Editor automatycznie konfiguruje projekt Xcode do przesyłania symboli.

   • W przypadku aplikacji na Androida: upewnij się, że masz skonfigurowane i uruchomione polecenie Firebase CLI 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ę do publikacji lub inną wersję, w przypadku której chcesz wyświetlać zsymbolizowane zrzuty stosu w Firebase. 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?

Zgłaszając nieobsłużone wyjątki jako błędy krytyczne, uzyskasz bardziej realistyczne informacje o tym, 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 krytyczne?

Aby funkcja Crashlytics mogła 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 wyjątek, który nie jest przechwytywany. Wyjątek, który jest tworzony, ale nie zgłaszany, nie jest uważany za nieprzechwycony.

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 błędach krytycznych, możesz je obsłużyć na kilka sposobów:

• Zastanów się, jak 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 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 powrócić 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 generować wyjątek, try-catchblokiem. Upewnij się, że warunki w instrukcjach catch są jak najwęższe, aby odpowiednio obsługiwać konkretne wyjątki.

Rejestrowanie wyjątków w Unity lub Crashlytics

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

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

• Opcja 1. Drukowanie w konsoli Unity, ale nieprzesyłanie informacji do Crashlytics podczas tworzenia aplikacji 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.

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

  • Jeśli wyjątek warto zarejestrować, aby debugować możliwe kolejne zdarzenie, użyj Crashlytics.Log(exception.ToString()).Crashlytics
  • 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ć 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 powoduje nieprzechwycony 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 niewyłapany 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 wraz z pakietem SDK Google Mobile Ads, prawdopodobnie rejestrowanie procedur obsługi wyjątków powoduje konflikt między modułami raportowania awarii. Aby rozwiązać ten problem, wyłącz raportowanie 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 zestawu danych Crashlytics, jak i zestawu danych sesji Firebase (jeśli eksportowanie danych o sesjach jest włączone).

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

• Po utworzeniu zbioru danych nie można zmienić jego lokalizacji. Możesz natomiast skopiować zbiór danych do innej lokalizacji lub ręcznie przenieść (ponownie utworzyć) zbiór danych 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 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 danych z ostatnich 30 dni lub z najnowszej daty, w której włączono eksportowanie do BigQuery (w zależności od tego, która z tych dat jest późniejsza).

• Nowa infrastruktura BigQuery nazywa 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 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 Twoim projekcie w Firebase.

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

Jeśli nazwa starszej tabeli partii nie odpowiada identyfikatorowi pakietu lub nazwie pakietu ustawionym 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 pliku binarnym aplikacji nie pasuje do identyfikatora pakietu lub nazwy pakietu ustawionych dla zarejestrowanej aplikacji w Firebase w projekcie w 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 miejscach nie są zgodne, 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 Twoim 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 lub _ANDROID, aby wskazać platformę aplikacji._IOS

^{* Jeśli identyfikator w pliku binarnym aplikacji pasował do jednego z identyfikatorów ustawionych dla aplikacji Firebase, nowa infrastruktura eksportu nie utworzyła dla niego nowej tabeli. Zamiast tego będzie nadal zapisywać w niej dane dotyczące 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 ograniczania zakłóceń

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

  1. W Google Cloudkonsoliskopiuj wszystkie dane z dotychczasowej 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 w starszej tabeli. Aby to zrobić, musisz zastąpić niektóre wartości domyślne w konfiguracji BigQuery.

  1. W Firebasekonsoli
     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ę przenoszenia 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ę dla gmp_app_id i listę dla client_namespace.

        W BigQuery identyfikator aplikacji Firebase jest nazywany gmp_app_id. Domyślnie wartość client_namespace w 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łnianie wsteczne w przypadku dni, 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.