Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów oraz odpowiedzi na często zadawane pytania dotyczące korzystania z Crashlytics. Jeśli nie możesz znaleźć tego, czego szukasz lub potrzebujesz dodatkowej pomocy, skontaktuj się z pomocą techniczną Firebase .
Ogólne rozwiązywanie problemów/FAQ
Możesz zauważyć dwa różne formaty problemów wymienionych w tabeli Problemy w konsoli Firebase. W niektórych problemach możesz także zauważyć funkcję zwaną „wariantami”. Dlatego!
Na początku 2023 r. wprowadziliśmy ulepszony silnik analityczny do grupowania wydarzeń, a także zaktualizowany projekt i kilka zaawansowanych funkcji dla nowych problemów (takich jak warianty!). Wszystkie szczegóły znajdziesz w naszym najnowszym poście na blogu , ale najważniejsze informacje znajdziesz poniżej.
Crashlytics analizuje wszystkie zdarzenia z Twojej aplikacji (takie jak awarie, zdarzenia inne niż krytyczne i błędy ANR) i tworzy grupy zdarzeń zwane problemami — wszystkie zdarzenia w problemie mają wspólny punkt awarii.
Aby pogrupować zdarzenia w te problemy, ulepszony silnik analizy analizuje obecnie wiele aspektów zdarzenia, w tym ramki w śladzie stosu, komunikat wyjątku, kod błędu i inne cechy platformy lub typu błędu.
Jednak w obrębie tej grupy zdarzeń ślady stosu prowadzące do awarii mogą być inne. Inny ślad stosu może oznaczać inną przyczynę podstawową. Aby przedstawić tę możliwą różnicę w obrębie problemu, tworzymy teraz warianty w obrębie problemów — każdy wariant jest podgrupą zdarzeń w problemie, które mają ten sam punkt awarii i podobny ślad stosu. Dzięki wariantom możesz debugować najczęstsze ślady stosu w obrębie problemu i określić, czy do niepowodzenia prowadzą różne przyczyny główne.
Oto, czego doświadczysz dzięki tym ulepszeniom:
Zmienione metadane wyświetlane w wierszu problemu
Teraz łatwiej jest zrozumieć i ocenić problemy w aplikacji.Mniej duplikatów problemów
Zmiana numeru linii nie powoduje nowego problemu.Łatwiejsze debugowanie złożonych problemów z różnymi przyczynami źródłowymi
Użyj wariantów, aby debugować najczęstsze ślady stosu w ramach problemu.Bardziej znaczące alerty i sygnały
Nowy problem w rzeczywistości oznacza nowy błąd.Mocniejsze wyszukiwanie
Każde wydanie zawiera więcej metadanych, które można przeszukiwać, takich jak typ wyjątku i nazwa pakietu.
Oto jak wdrażane są te ulepszenia:
Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują one do istniejącego problemu.
Jeśli nie ma 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 naszym grupowaniu wydarzeń. Jeśli masz uwagi lub napotkasz jakiekolwiek problemy, daj nam znać, przesyłając raport.
Jeśli nie widzisz wskaźników wolnych od awarii (takich jak użytkownicy i sesje bez awarii) i/lub alertów dotyczących prędkości, upewnij się, że używasz pakietuCrashlytics SDK v18.6.0+ (lub Firebase BoM v32.6.0+).
Jeśli nie widzisz dzienników nawigacji , zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics. Upewnij się, że spełniasz następujące wymagania:
Włączyłeś Google Analytics w swoim projekcie Firebase.
Włączyłeś udostępnianie danych dla Google Analytics. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych Analytics
dodałeś pakiet SDK Firebase dla Google Analyticsdo swojej aplikacji. Ten zestaw SDK należy dodać oprócz zestawu SDK Crashlytics.
Używasznajnowszych wersji Firebase SDKdla wszystkich produktów, których używasz w swojej aplikacji.
Sprawdź zwłaszcza, czy używasz co najmniej następującej wersji pakietu SDK Firebase dla Google Analytics:
Android — v17.2.3+ (BoM v24.7.1+) .
Crashlytics obsługuje raportowanie ANR dla aplikacji na Androida z urządzeń z Androidem 11 i nowszym. Podstawowy 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.
Jeśli w niektórych komunikatach ANR brakuje identyfikatorów BuildId
, rozwiąż problem w następujący sposób:
Upewnij się, że używasz aktualnej wersji pakietu Crashlytics Android SDK i wtyczki Crashlytics Gradle.
Jeśli brakuje
BuildId
s dla Androida 11 i niektórych błędów ANR w Androidzie 12, prawdopodobnie używasz nieaktualnego zestawu SDK, wtyczki Gradle lub obu. Aby poprawnie zbieraćBuildId
dla tych błędów ANR, musisz użyć następujących wersji:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Wtyczka Crashlytics Gradle v2.9.4+
Sprawdź, czy używasz niestandardowej lokalizacji dla swoich bibliotek współdzielonych.
Jeśli brakuje tylko identyfikatorów
BuildId
dla bibliotek współdzielonych aplikacji, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek współdzielonych. W takim przypadku Crashlytics może nie być w stanie zlokalizować powiązanych identyfikatorówBuildId
. Zalecamy rozważenie użycia standardowej lokalizacji bibliotek współdzielonych.Upewnij się, że nie usuwasz
BuildId
s podczas procesu kompilacji.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
BuildId
s istnieje, uruchamiającreadelf -n
w swoich plikach binarnych. Jeśli nie ma parametrówBuildId
, dodaj-Wl,--build-id
do flag swojego systemu kompilacji.Sprawdź, czy nie usuwasz niechcący identyfikatorów
BuildId
w celu zmniejszenia rozmiaru pliku APK.Jeśli przechowujesz pozbawione i pozbawione ograniczeń wersje biblioteki, pamiętaj o wskazaniu prawidłowej wersji w kodzie.
Może występować rozbieżność między liczbą błędów ANR między Google Play i Crashlytics. Jest to oczekiwane ze względu na różnicę w mechanizmie gromadzenia i raportowania danych ANR. Crashlytics zgłasza błędy ANR przy następnym uruchomieniu aplikacji, natomiast Android Vitals wysyła dane ANR po ich wystąpieniu.
Ponadto Crashlytics wyświetla tylko błędy ANR występujące na urządzeniach z systemem Android 11 lub nowszym, w porównaniu do Google Play, które wyświetla błędy ANR z urządzeń z usługami Google Play i zaakceptowaną zgodą na gromadzenie danych.
Łańcuchy narzędzi LLVM i GNU mają różne ustawienia domyślne i sposoby traktowania segmentu plików binarnych aplikacji tylko do odczytu, co może generować niespójne ślady stosu w konsoli Firebase. Aby temu zaradzić, dodaj następujące flagi linkera do procesu kompilacji:
Jeśli używasz linkera
lld
z łańcucha 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 śledzeniu stosu (lub jeśli żadna flaga nie dotyczy Twojego łańcucha narzędzi), spróbuj zamiast tego dodać do procesu kompilacji następujące elementy:
-fno-omit-frame-pointer
Wtyczka Crashlytics zawiera dostosowany generator plików symboli Breakpad . Jeśli wolisz używać własnego pliku binarnego do generowania plików symboli Breakpad (na przykład, jeśli wolisz budować wszystkie natywne pliki wykonywalne w łańcuchu kompilacji ze źródła), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary
, aby określić ścieżkę do pliku wykonywalnego.
Możesz określić ścieżkę do pliku binarnego generatora plików symboli Breakpad na jeden z dwóch sposobów:
Opcja 1 : Określ ścieżkę za pomocą rozszerzenia
firebaseCrashlytics
w plikubuild.gradle
Dodaj następujące elementy do pliku
build.gradle
na poziomie aplikacji: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ę poprzez linię właściwości w pliku właściwości Gradle
Możesz użyć właściwości
com.google.firebase.crashlytics.symbolGeneratorBinary
, aby określić ścieżkę do pliku wykonywalnego.Możesz ręcznie zaktualizować plik właściwości Gradle lub zaktualizować plik za pomocą wiersza poleceń. Na przykład, aby określić ścieżkę za pomocą wiersza poleceń, użyj polecenia podobnego do poniższego:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Jeśli widzisz następujący 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ć:
Upewnij się, że używasz najnowszej wersji DexGuard 8.x. Najnowsza wersja zawiera reguły wymagane przez pakiet SDK Firebase Crashlytics.
Jeśli nie chcesz zmieniać wersji DexGuard, spróbuj dodać następujący wiersz do reguł zaciemniania (w pliku konfiguracyjnym DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Gdy aplikacja korzysta z narzędzia zaciemniającego, które nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java
.
Aby Crashlytics mógł generować problemy z prawidłowym rozszerzeniem pliku, upewnij się, że Twoja aplikacja korzysta z następującej konfiguracji:
- Używa Androida Gradle 4.2.0 lub nowszego
- Używa R8 z włączoną funkcją zaciemniania. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją .
Pamiętaj, że po aktualizacji do konfiguracji opisanej powyżej mogą zacząć pojawiać się nowe problemy .kt
, które są duplikatami istniejących problemów z .java
. Zobacz często zadawane pytania , aby dowiedzieć się więcej na temat tej okoliczności.
Od połowy grudnia 2021 r. Crashlytics poprawiło obsługę aplikacji korzystających z Kotlina.
Do niedawna dostępne zaciemniacze nie ujawniały rozszerzenia pliku, dlatego Crashlytics generował każdy problem domyślnie z rozszerzeniem pliku .java
. Jednak od wersji Androida Gradle 4.2.0 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 języku Kotlin i uwzględnić poprawną nazwę pliku w sygnaturze problemu. Awarie są teraz poprawnie przypisywane plikom .kt
(w zależności od przypadku), jeśli Twoja aplikacja ma następującą konfigurację:
- Twoja aplikacja korzysta z Androida Gradle 4.2.0 lub nowszego.
- Twoja aplikacja korzysta z R8 z włączonym zaciemnianiem.
Ponieważ nowe awarie zawierają teraz prawidłowe rozszerzenie pliku w sygnaturach problemów, mogą pojawić się nowe problemy z .kt
, które w rzeczywistości są po prostu duplikatami istniejących problemów z etykietą .java
. W konsoli Firebase staramy się zidentyfikować i powiadomić Cię, jeśli nowy problem .kt
jest możliwym duplikatem istniejącego problemu z etykietą .java
.
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.
Kiedy członek projektu publikuje notatkę, jest ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich członków projektu mających dostęp do przeglądania notatki.
Poniżej opisano dostęp wymagany do przeglądania, pisania i usuwania notatek:
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie problemu, ale nie mogą usuwać ani pisać notatek.
Zobacz Omówienie wskaźników bezawaryjnych .
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.
Kiedy członek projektu publikuje notatkę, jest ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich członków projektu mających dostęp do przeglądania notatki.
Poniżej opisano dostęp wymagany do przeglądania, pisania i usuwania notatek:
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie problemu, ale nie mogą usuwać ani pisać notatek.
Integracje
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobne jest, że osoby zgłaszające awarie zakłócają rejestrację programów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie o awariach w pakiecie SDK do reklam mobilnych, wywołując disableSDKCrashReporting
.
Po połączeniu Crashlytics z BigQuery nowe utworzone przez Ciebie zbiory danych będą automatycznie lokalizowane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Wsparcie platformy
Firebase Crashlytics NDK nie obsługuje ARMv5 (armeabi). Obsługa tego ABI została usunięta w wersji NDK r17.
Cofnięte problemy
Problem uległ regresji, gdy został już wcześniej zamknięty, ale Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu. Crashlytics automatycznie ponownie otwiera te problemy, które uległy regresji, dzięki czemu możesz je rozwiązać odpowiednio do swojej aplikacji.
Oto przykładowy scenariusz wyjaśniający, jak Crashlytics kategoryzuje problem jako regresję:
- Po raz pierwszy w historii Crashlytics otrzymuje raport o awarii dotyczącej awarii „A”. Crashlytics otwiera odpowiedni problem dla tej awarii (problem „A”).
- Szybko naprawisz ten błąd, zamkniesz wydanie „A”, a następnie wypuścisz nową wersję swojej aplikacji.
- Crashlytics otrzymuje kolejny raport na temat problemu „A” po jego zamknięciu.
- Jeśli raport dotyczy wersji aplikacji, o której Crashlytics wiedziała w chwili zamykania problemu (co oznacza, że ta wersja wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna, że problem uległ regresji. Temat pozostanie zamknięty.
- Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedziała w chwili zamykania problemu (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o awarii w przypadku żadnej awarii), Crashlytics uzna, że problem ustąpił i ponownie go otworzy .
Gdy problem się cofa, wysyłamy alert o wykryciu regresji i dodajemy sygnał regresji do problemu, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.
Jeśli raport pochodzi ze starej wersji aplikacji, która po zamknięciu problemu nie wysyłała żadnych raportów o awariach, Crashlytics uzna, że problem uległ regresji i ponownie go otworzy.
Taka sytuacja może mieć miejsce w następującej sytuacji: Naprawiłeś błąd i wydałeś nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki błędu. Jeśli przez przypadek jedna ze starszych wersji nigdy nie wysłała żadnych raportów o awariach po zamknięciu problemu, a ci użytkownicy zaczną napotykać błąd, wówczas te raporty o awariach spowodują regresję problemu.
Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.