Ta strona zawiera 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 szybkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że masz włączoną usługę Google Analytics w swoim projekcie Firebase.
Upewnij się, że udostępnianie danych jest włączone dla Google Analytics 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 Twojej aplikacji ( iOS+ | Android ) został dodany pakiet Firebase SDK dla Google Analytics.
Upewnij się, że korzystasz z najnowszych wersji wszystkich pakietów SDK Firebase ( iOS+ | Android ).
W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu Firebase SDK dla Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — wersja 17.2.3+(BoM v24.7.1+) .
Crashlytics obsługuje raportowanie ANR dla aplikacji na Androida z urządzeń z Androidem 11 lub nowszym. Bazowy interfejs API, którego używamy do zbierania błędów ANR ( getHistoricalProcessExitReasons ), jest bardziej niezawodny niż metody 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 w Google Play i 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+, w przeciwieństwie do Google Play, który wyświetla błędy ANR z urządzeń z zaakceptowanymi usługami Google Play i zaakceptowaną zgodą na gromadzenie danych.
Łańcuchy narzędzi LLVM i GNU mają różne wartości domyślne i sposoby obsługi segmentu plików binarnych aplikacji tylko do odczytu, co może generować niespójne ślady stosu w konsoli Firebase. Aby to złagodzić, dodaj następujące flagi konsolidatora do procesu kompilacji:
Jeśli używasz konsolidatora
lldz łańcucha narzędzi LLVM, dodaj:-Wl,--no-rosegmentJeśli używasz linkera
ld.goldz łańcucha narzędzi GNU, dodaj:-Wl,--rosegment
Jeśli nadal widzisz niespójności śledzenia stosu (lub jeśli żadna z flag nie dotyczy Twojego zestawu 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 kompilować 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.
Ścieżkę do pliku binarnego generatora plików symboli Breakpad można określić na dwa sposoby:
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ę poprzez linię własnoś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 następującego:
./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 niezgodnej 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 Firebase Crashlytics SDK.
Jeśli nie chcesz zmieniać swojej wersji DexGuard, spróbuj dodać następujący wiersz do swoich reguł zaciemniania (w pliku konfiguracyjnym DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Gdy aplikacja używa zaciemniacza, który nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem .java .
Aby Crashlytics mogło generować problemy z poprawnym 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 powyższej konfiguracji możesz zacząć widzieć nowe problemy .kt , które są duplikatami istniejących problemów .java . Zobacz FAQ , aby dowiedzieć się więcej o tej sytuacji.
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ło każdy problem z rozszerzeniem .java . Jednak od 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 Kotlinie i zawierać poprawną nazwę pliku w sygnaturze problemu. 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 prawidłowe rozszerzenie pliku w sygnaturach problemów, możesz zobaczyć nowe problemy z .kt , które w rzeczywistości są tylko duplikatami istniejących problemów z etykietami .java . W konsoli Firebase staramy się identyfikować i informować, czy nowy problem z .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 w określonym czasie nie wystąpiła awaria. Okres ten wybierasz z menu w prawym górnym rogu panelu Crashlytics.
Odsetek użytkowników bez awarii to agregacja w czasie , a nie średnia.
Na przykład wyobraź sobie, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownik A, Użytkownik B i Użytkownik C. Poniższa tabela pokazuje, którzy użytkownicy korzystają z Twojej aplikacji każdego dnia i który z nich miał 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ę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie powodował awarii).
Dwóch użytkowników korzystało z Twojej aplikacji w środę, ale tylko jeden z nich (użytkownik B) nie miał awarii.W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosi 33,3% (1 na 3 użytkowników nie uległo 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ł awarii.W ciągu ostatnich 3 dni Twój odsetek użytkowników bez awarii wynosi 0% (0 z 3 użytkowników nie powodowało awarii).
Trzech użytkowników korzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiły żadne awarie.
Jeśli to konieczne, oto konkretne dane wejściowe i wzór do obliczenia procentu użytkowników bez awarii:
1 - ( IMPACTED_USERS / ALL_USERS )
Gdzie IMPACTED_USERS i ALL_USERS są gromadzone przez Google Analytics i dostępne za pośrednictwem panelu Analytics.
Integracje
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobnie zgłaszający awarie zakłócają rejestrację modułó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 zbiory danych, które utworzysz, będą automatycznie zlokalizowane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Obsługa platformy
Firebase Crashlytics NDK nie obsługuje ARMv5 (armeabi). Obsługa tego ABI została usunięta w NDK r17.
Cofnięte problemy
Problem uległ regresji, gdy poprzednio go zamknąłeś, ale Crashlytics otrzymuje nowy raport, że problem wystąpił ponownie. Crashlytics automatycznie ponownie otwiera te problemy, które cofnęły się, aby można było je rozwiązać zgodnie z potrzebami Twojej aplikacji.
Oto przykładowy scenariusz, który wyjaśnia, w jaki sposób Crashlytics klasyfikuje problem jako regresję:
- Po raz pierwszy w historii Crashlytics otrzymuje raport o awarii o Crashu „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 otrzyma kolejny raport o problemie „A” po jego zamknięciu.
- Jeśli zgłoszenie pochodzi z wersji aplikacji, o której Crashlytics wiedziało , gdy zamknąłeś problem (co oznacza, że wersja wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna problemu za cofnięty. Sprawa pozostanie zamknięta.
- Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedział podczas zamykania problemu (co oznacza, że ta wersja nigdy nie wysłała żadnego raportu o awariach), Crashlytics uzna, że problem uległ regresji i ponownie go otworzy .
Gdy problem cofa się, wysyłamy alert o wykryciu regresji i dodajemy do niego sygnał regresji, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby sprawa została ponownie otwarta z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.
Jeśli raport 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ł wycofany i ponownie go otworzy.
Taka sytuacja może mieć miejsce w następującej sytuacji: Naprawiłeś błąd i wydałeś nową wersję swojej aplikacji, ale nadal masz użytkowników w starszych wersjach bez poprawki. Jeśli przypadkiem 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, te raporty o awariach wywołają problem cofnięty.
Jeśli nie chcesz, aby sprawa została ponownie otwarta z powodu naszego algorytmu regresji, „wycisz” problem zamiast go zamykać.