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
Jeśli nie widzisz użytkowników bez awarii, dzienników nawigacji i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że w swoim projekcie Firebase włączyłeś Google Analytics .
Upewnij się, że Udostępnianie danych dla Google Analytics jest włączone na stronie Integracje > Google Analytics w konsoli Firebase. Pamiętaj, że ustawienia udostępniania danych są wyświetlane w konsoli Firebase, ale zarządza się nimi w konsoli Google Analytics.
Oprócz pakietu SDK Firebase Crashlytics upewnij się, że do swojej aplikacji dodałeś pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).
Upewnij się, że używasz najnowszych wersji wszystkich zestawów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu SDK Firebase dla Google Analytics:iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — v17.2.3+ (BoM v24.7.1+) .
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.
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
dla Androida 11 i niektórych błędów ANR dla Androida 12, prawdopodobnie używasz nieaktualnego pakietu 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 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 ś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 systemu Android 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
.
Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale nie doświadczyli awarii w określonym przedziale czasu.
Oto wzór na obliczenie procentu użytkowników bez awarii. Jego wartości wejściowe są dostarczane przez Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
W przypadku awarii Google Analytics wysyła typ zdarzenia
app_exception
, a CRASHED_USERS reprezentuje liczbę użytkowników powiązanych z tym typem zdarzenia.ALL_USERS reprezentuje łączną liczbę użytkowników, którzy weszli w interakcję z Twoją aplikacją w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii jest sumą w czasie , a nie średnią.
Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy korzystali z Twojej aplikacji każdego dnia i który z nich miał tego dnia awarię:
Poniedziałek | Wtorek | Środa | |
---|---|---|---|
Użytkownicy, którzy weszli w interakcję z Twoją aplikacją | A, B, C | A, B, C | A, B |
Użytkownik, który miał awarię | C | B | A |
W środę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie miał żadnych awarii).
Dwóch użytkowników skorzystało z Twojej aplikacji w środę, ale tylko u jednego z nich (Użytkownik B) nie wystąpiła żadna awaria.W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników nie miał żadnych awarii).
Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko u jednego z nich (Użytkownik C) nie wystąpiła żadna awaria.W ciągu ostatnich 3 dni odsetek użytkowników bez awarii wynosił 0% (0 z 3 użytkowników nie miało żadnych awarii).
Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiła żadna awaria.
Wartości użytkowników bez awarii nie należy porównywać w różnych okresach czasu. Prawdopodobieństwo, że pojedynczy użytkownik doświadczy awarii, rośnie im częściej korzysta z aplikacji, więc wartość użytkowników bez awarii będzie prawdopodobnie mniejsza w dłuższych okresach.
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ć.
,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
Jeśli nie widzisz użytkowników bez awarii, dzienników nawigacji i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że w swoim projekcie Firebase włączyłeś Google Analytics .
Upewnij się, że Udostępnianie danych dla Google Analytics jest włączone na stronie Integracje > Google Analytics w konsoli Firebase. Pamiętaj, że ustawienia udostępniania danych są wyświetlane w konsoli Firebase, ale zarządza się nimi w konsoli Google Analytics.
Oprócz pakietu SDK Firebase Crashlytics upewnij się, że do swojej aplikacji dodałeś pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).
Upewnij się, że używasz najnowszych wersji wszystkich zestawów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu SDK Firebase dla Google Analytics:iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — v17.2.3+ (BoM v24.7.1+) .
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.
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
dla Androida 11 i niektórych błędów ANR dla Androida 12, prawdopodobnie używasz nieaktualnego pakietu 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 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 ś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 systemu Android 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 .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
.
Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale nie doświadczyli awarii w określonym przedziale czasu.
Oto wzór na obliczenie procentu użytkowników bez awarii. Jego wartości wejściowe są dostarczane przez Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
W przypadku awarii Google Analytics wysyła typ zdarzenia
app_exception
, a CRASHED_USERS reprezentuje liczbę użytkowników powiązanych z tym typem zdarzenia.ALL_USERS reprezentuje łączną liczbę użytkowników, którzy weszli w interakcję z Twoją aplikacją w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii jest sumą w czasie , a nie średnią.
Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy korzystali z Twojej aplikacji każdego dnia i który z nich miał tego dnia awarię:
Poniedziałek | Wtorek | Środa | |
---|---|---|---|
Użytkownicy, którzy weszli w interakcję z Twoją aplikacją | A, B, C | A, B, C | A, B |
Użytkownik, który miał awarię | C | B | A |
W środę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie miał żadnych awarii).
Dwóch użytkowników skorzystało z Twojej aplikacji w środę, ale tylko u jednego z nich (Użytkownik B) nie wystąpiła żadna awaria.W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników nie miał żadnych awarii).
Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko u jednego z nich (Użytkownik C) nie wystąpiła żadna awaria.W ciągu ostatnich 3 dni odsetek użytkowników bez awarii wynosił 0% (0 z 3 użytkowników nie miało żadnych awarii).
Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiła żadna awaria.
Wartości użytkowników bez awarii nie należy porównywać w różnych okresach czasu. Prawdopodobieństwo, że pojedynczy użytkownik doświadczy awarii, rośnie im częściej korzysta z aplikacji, więc wartość użytkowników bez awarii będzie prawdopodobnie mniejsza w dłuższych okresach.
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ć.