Ta strona zawiera pomoc w rozwiązywaniu problemów i 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 nawigacyjnych i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że masz włączone Google Analytics w swoim projekcie Firebase.
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ądzane w konsoli Google Analytics.
Oprócz pakietu Firebase Crashlytics SDK upewnij się, że do swojej aplikacji został dodany pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).
Upewnij się, że używasz najnowszych wersji wszystkich swoich pakietów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji Firebase SDK 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. Dlatego!
Crashlytics analizuje wszystkie zdarzenia z Twojej aplikacji — awarie, błędy bez błędów i błędy ANR — i grupuje podobne zdarzenia w osobne problemy. W styczniu 2023 r. wprowadziliśmy ulepszony mechanizm analizy do grupowania zdarzeń na podstawie kodu Twojej aplikacji oraz zaktualizowany wygląd do wyświetlania nowych problemów.
Oto, czego doświadczysz dzięki tym ulepszeniom:
Zmienione metadane wyświetlane w wierszu problemu
Łatwiej jest teraz zrozumieć i segregować problemy w aplikacji.Mniej zduplikowanych problemów
Zmiana numeru linii nie powoduje powstania nowego problemu.Bardziej znaczące alerty i sygnały
Nowy problem w rzeczywistości oznacza nowy błąd.Bardziej wydajne wyszukiwanie
Każde wydanie zawiera więcej możliwych do przeszukiwania metadanych, 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ą do istniejącego problemu.
Jeśli nie ma dopasowania, automatycznie zastosujemy nasz inteligentniejszy algorytm grupowania zdarzeń do zdarzenia i utworzymy nowy problem z odnowionym projektem metadanych.
To pierwsza duża aktualizacja naszego grupowania wydarzeń. Jeśli masz uwagi lub napotkasz jakiekolwiek problemy, daj nam znać, wypełniając raport.
Crashlytics obsługuje raportowanie błędów ANR dla aplikacji na Androida z urządzeń z Androidem 11 lub 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 watchdog. Ten interfejs API jest dostępny tylko na urządzeniach z Androidem 11+.
Może występować niezgodność między liczbą błędów ANR między Google Play a Crashlytics. Jest to oczekiwane ze względu na różnicę w mechanizmie zbierania i raportowania danych ANR. Crashlytics zgłasza błędy ANR przy następnym uruchomieniu aplikacji, podczas gdy Android Vitals wysyła dane ANR po wystąpieniu błędu ANR.
Ponadto Crashlytics wyświetla tylko błędy ANR, które występują na urządzeniach z Androidem 11 lub nowszym, w porównaniu do Google Play, który 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ą odrębne wartości domyślne i sposoby postępowania dla 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 konsolidatora do procesu kompilacji:
Jeśli używasz konsolidatora
lldz zestawu narzędzi LLVM, dodaj:-Wl,--no-rosegmentJeśli używasz konsolidatora
ld.goldz łańcucha narzędzi GNU, dodaj:-Wl,--rosegment
Jeśli nadal widzisz niespójności śledzenia stosu (lub jeśli żadna flaga nie jest związana z twoim zestawem narzędzi), spróbuj zamiast tego dodać następujące elementy do procesu kompilacji:
-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
firebaseCrashlyticsw plikubuild.gradleDodaj następujące elementy do pliku
build.gradlena 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ę przez 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 następującego polecenia:
./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 Firebase Crashlytics SDK:
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ć swojej wersji DexGuard, spróbuj dodać następującą linię do reguł zaciemniania (w pliku konfiguracyjnym DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Gdy aplikacja korzysta z zaciemniacza, który nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java .
Aby Crashlytics mogło generować problemy z poprawnym rozszerzeniem pliku, upewnij się, że Twoja aplikacja ma następującą konfigurację:
- Używa Androida Gradle 4.2.0 lub nowszego
- Używa R8 z włączonym zaciemnianiem. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją .
Pamiętaj, że po aktualizacji do konfiguracji opisanej powyżej możesz zacząć widzieć nowe problemy .kt , które są duplikatami istniejących problemów z .java . Zobacz FAQ , aby dowiedzieć się więcej o 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, więc Crashlytics domyślnie generował każdy problem z rozszerzeniem pliku .java . Jednak od wersji Android 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 umieścić poprawną nazwę pliku w sygnaturze zgłoszenia. Awarie są teraz poprawnie przypisywane do plików .kt (odpowiednio), jeśli Twoja aplikacja ma następującą konfigurację:
- Twoja aplikacja korzysta z Androida Gradle 4.2.0 lub nowszego.
- Twoja aplikacja używa R8 z włączonym zaciemnianiem.
Ponieważ nowe awarie zawierają teraz poprawne rozszerzenia plików w swoich sygnaturach, możesz zobaczyć nowe problemy .kt , które w rzeczywistości są tylko duplikatami istniejących problemów z rozszerzeniem .java . W konsoli Firebase staramy się zidentyfikować i poinformować Cię, czy nowy problem z rozszerzeniem .kt jest możliwym duplikatem istniejącego problemu z etykietą .java .
Wartość bez awarii reprezentuje odsetek użytkowników, którzy korzystali z Twojej aplikacji, ale nie mieli awarii w określonym czasie.
Oto wzór do obliczania 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 to łączna liczba użytkowników, którzy korzystali z Twojej aplikacji w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii to agregacja w czasie , a nie średnia.
Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwijmy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy wchodzili w interakcję z Twoją aplikacją każdego dnia i którzy z nich mieli tego dnia awarię:
| Poniedziałek | Wtorek | Środa | |
|---|---|---|---|
| Użytkownicy, którzy korzystali z Twojej aplikacji | A, B, C | A, B, C | A, B |
| Użytkownik, który miał awarię | C | B | A |
W środę Twój odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników był bez awarii).
Dwóch użytkowników korzystało z Twojej aplikacji w środę, ale tylko jeden z nich (Użytkownik B) nie miał żadnych awarii.W ciągu ostatnich 2 dni Twój odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników był bez awarii).
Trzech użytkowników korzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko jeden z nich (Użytkownik C) nie miał żadnych awarii.W ciągu ostatnich 3 dni Twój odsetek użytkowników bez awarii wynosił 0% (0 na 3 użytkowników było bez awarii).
Trzech użytkowników korzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale żaden z nich nie miał żadnych awarii.
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.
Gdy 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 z uprawnieniami do przeglądania notatki.
Poniżej opisano uprawnienia wymagane do przeglądania, zapisywania 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 dotyczące problemu.
Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie, ale nie mogą ich usuwać ani pisać.
- Przeglądarka projektów , Przeglądarka Firebase , Przeglądarka jakości lub Przeglądarka Crashlytics
Integracje
Jeśli Twój projekt korzysta z Crashlytics wraz z pakietem SDK do reklam mobilnych Google, prawdopodobnie moduły zgłaszające awarie zakłócają rejestrację procedur obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK do reklam mobilnych, wywołując funkcję disableSDKCrashReporting .
Po połączeniu Crashlytics z BigQuery nowe zbiory danych, które tworzysz, są automatycznie umieszczane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Wsparcie platformy
Firebase Crashlytics NDK nie obsługuje ARMv5 (armeabi). Wsparcie dla tego ABI zostało usunięte od NDK r17.
Regresowane problemy
Problem uległ regresji po jego wcześniejszym zamknięciu, ale Crashlytics otrzymuje nowy raport, że problem pojawił się ponownie. Crashlytics automatycznie ponownie otwiera te cofnięte problemy, dzięki czemu możesz je odpowiednio rozwiązać dla swojej aplikacji.
Oto przykładowy scenariusz wyjaśniający, w jaki sposób Crashlytics klasyfikuje problem jako regresję:
- Po raz pierwszy Crashlytics otrzymuje raport o awarii dotyczący awarii „A”. Crashlytics otwiera odpowiedni problem dla tej awarii (problem „A”).
- Szybko naprawiasz ten błąd, zamykasz problem „A”, a następnie wydajesz nową wersję swojej aplikacji.
- Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po jego zamknięciu.
- Jeśli zgłoszenie pochodzi z wersji aplikacji, o której Crashlytics wiedziało w momencie zamykania problemu (co oznacza, że ta wersja w ogóle wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna problemu za cofnięty. Temat pozostanie zamknięty.
- Jeśli zgłoszenie dotyczy wersji aplikacji, o której Crashlytics nie wiedziało w momencie zamykania problemu (co oznacza, że wersja nigdy nie wysłała żadnego raportu o awarii w przypadku jakiejkolwiek 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 z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.
Jeśli zgłoszenie pochodzi ze starej wersji aplikacji, która nigdy nie wysyłała żadnych raportów o awariach po zamknięciu problemu, Crashlytics uzna, że problem został cofnięty i otworzy go ponownie.
Taka sytuacja może wystąpić w następującej sytuacji: naprawiłeś błąd i wydałeś nową wersję swojej aplikacji, ale nadal masz użytkowników starszych wersji bez poprawki. Jeśli przypadkowo jedna z tych starszych wersji nigdy nie wysłała żadnych raportów o awariach po zamknięciu problemu, a ci użytkownicy zaczną napotykać błąd, wtedy te raporty o awariach wywołałyby regresję problemu.
Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.