Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
Na tej stronie znajdziesz pomoc dotyczącą rozwiązywania problemów oraz odpowiedzi na najczęstsze pytania dotyczące Crashlytics. Jeśli nie możesz znaleźć tego, czego szukasz, lub potrzebujesz dodatkowej pomocy, skontaktuj się z zespołem pomocy Firebase.
Ogólne informacje o rozwiązywaniu problemów i najczęstsze pytania
wyświetlanie w tabeli Problemy różnych formatów (a czasami „wariantów”) niektórych problemów;
W konsoli Firebase możesz zauważyć 2 różne formaty problemów wymienionych w tabeli Problemy. W niektórych problemach możesz też zauważyć funkcję
o nazwie „warianty”. Wyjaśniamy dlaczego.
Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupowania zdarzeń oraz zaktualizowany wygląd i kilka zaawansowanych funkcji związanych z nowymi problemami (takimi jak warianty). Więcej informacji znajdziesz w naszym niedawnym poście na blogu. Poniżej znajdziesz najważniejsze informacje.
Crashlytics analizuje wszystkie zdarzenia z aplikacji (takie jak awarie, błędy niekrytyczne i błędy ANR) oraz tworzy grupy zdarzeń nazywane problemami. Wszystkie zdarzenia danego problemu mają wspólny punkt awarii.
Aby grupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje teraz wiele aspektów zdarzenia, w tym ramki w zrzucie stosu, komunikat o wyjątku, kod błędu oraz inne cechy platformy lub typu błędu.
W ramach tej grupy zdarzeń ścieżki stosu prowadzące do błędu mogą się jednak różnić. Inny zrzut stosu może oznaczać inną przyczynę problemu.
Aby uwzględnić tę możliwą różnicę w problemie, tworzymy warianty w problemach. Każdy wariant to podgrupa zdarzeń w problemie, która ma ten sam punkt awarii i podobny ślad stosu. Za pomocą wariantów możesz debugować najczęstsze ścieżki stosu w ramach problemu i określać, czy do niepowodzenia prowadzą różne przyczyny.
Oto, co się zmieni:
Zaktualizowane metadane wyświetlane w wierszu z problemem Zrozumienie i rozwiązywanie problemów w aplikacji jest teraz łatwiejsze.
Mniej zduplikowanych problemów Zmiana numeru wiersza nie powoduje pojawienia się nowego problemu.
Łatwiejsze debugowanie skomplikowanych problemów z różnymi przyczynami Używaj wariantów do debugowania najczęstszych ścieżek wywołań w ramach problemu.
Bardziej istotne alerty i sygnały Nowy problem oznacza nowy błąd.
Bardziej zaawansowane wyszukiwanie Każdy problem zawiera więcej metadanych, które można wyszukiwać, na przykład 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 zdarzenia, automatycznie zastosujemy do niego nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.
Jest to pierwsza duża zmiana, jaką wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkasz problem, prześlij raport.
Nie widzisz danych o bezawaryjnej pracy ani alertów dotyczących szybkości
Jeśli nie widzisz danych o użytkownikach i sesjach bez awarii ani alertów dotyczących szybkości, sprawdź, czy używaszpakietu SDK Crashlytics w wersji 18.6.0 lub nowszej (lub Firebase BoMw wersji 32.6.0 lub nowszej), wtyczki Crashlytics Flutter w wersji 3.4.5 lub nowszej, pakietu SDK Crashlytics w wersji 11.7.0 lub nowszej.
Nie widzę logów menu nawigacyjnego
Jeśli nie widzisz dzienników ścieżek, sprawdź konfigurację aplikacji pod kątem Google Analytics.
Upewnij się, że spełniasz te wymagania:
Zwłaszcza sprawdź, czy używasz co najmniej tej wersji pakietu SDK Firebase w Google Analytics: Android – w wersji 17.2.3 lub nowszej(BoM w wersji 24.7.1 lub nowszej).
Dlaczego błędy ANR są zgłaszane tylko w przypadku Androida w wersji 11 lub nowszej?
Crashlytics obsługuje raportowanie błędów ANR w przypadku aplikacji na Androida na urządzeniach z Androidem 11 lub nowszym. Podstawowy interfejs API, którego używamy do zbierania informacji o błędach ANR (getHistoryProcessExitReasons), jest bardziej niezawodny niż metody SIGQUIT czy watchdog. Ten interfejs API jest dostępny tylko na urządzeniach z Androidem 11 i nowszych.
Dlaczego w przypadku niektórych błędów ANR nie ma wartości BuildId?
Jeśli niektóre z Twoich plików ANR nie mają atrybutu BuildId, wykonaj te czynności:
Upewnij się, że używasz aktualnej wersji pakietu CrashlyticsAndroid SDK i Crashlyticswtyczki Gradle.
Jeśli brakuje Ci BuildId na Androidzie 11 i niektórych ANR na Androidzie 12, prawdopodobnie używasz przestarzałego pakietu SDK lub wtyczki Gradle albo obu tych elementów.
Aby prawidłowo zbierać BuildId w przypadku tych ANR, musisz używać tych wersji:
Crashlytics Android SDK w wersji 18.3.5 lub nowszej (Firebase BoM wersja 31.2.2 lub nowsza)
Wtyczka do Gradle Crashlytics w wersji 2.9.4 lub nowszej
Sprawdź, czy używasz niestandardowej lokalizacji dla zasobów wspólnych.
Jeśli brakuje tylko BuildId w bibliotekach udostępnionych aplikacji, prawdopodobnie nie używasz standardowej domyślnej lokalizacji bibliotek udostępnionych. W takim przypadku usługa Crashlytics może nie być w stanie znaleźć powiązanych elementów BuildId. Zalecamy używanie standardowej lokalizacji dla współdzielonych bibliotek.
Sprawdź, czy podczas procesu kompilacji nie są usuwane elementy BuildId.
Pamiętaj, że podane niżej wskazówki dotyczące rozwiązywania problemów dotyczą zarówno ANR, jak i wbudowanych awarii.
Sprawdź, czy pliki BuildId istnieją, uruchamiając readelf -n na plikach binarnych. Jeśli BuildId są nieobecne, dodaj -Wl,--build-id do flag systemu kompilacji.
Sprawdź, czy nie usuwasz nieumyślnie elementów BuildId, aby zmniejszyć rozmiar pliku APK.
Jeśli zachowasz uproszczone i nieskrócone wersje biblioteki, wskaż prawidłową wersję w kodzie.
Różnice między raportami ANR na panelu Crashlytics a Konsolą Google Play
Liczba powiadomień ANR w Google Play może się różnić od liczby w Crashlytics. Jest to spowodowane różnicami w mechanizmach zbierania i raportowania danych o błędach ANR. Crashlytics raportuje błędy ANR, gdy aplikacja uruchamia się następnym razem, a Android Vitals wysyła dane ANR po ich wystąpieniu.
Dodatkowo Crashlytics wyświetla tylko błędy ANR na urządzeniach z Androidem 11 lub nowszym. Natomiast Google Play wyświetla błędy ANR z urządzeń, na których zaakceptowano Usługi Google Play i zgodę na zbieranie danych.
Różnice między śladami stosu NDK w panelu Crashlytics i logcat
Zestawy narzędzi LLVM i GNU mają różne wartości domyślne i metody obsługi segmentu binarów aplikacji, który jest tylko do odczytu. Może to powodować niespójności w śladach stosu w konsoli Firebase. Aby temu zapobiec, dodaj do procesu kompilacji te flagi linkera:
Jeśli używasz tagu łączącego lld z łańcucha narzędzi LLVM, dodaj:
-Wl,--no-rosegment
Jeśli korzystasz z tagu łączącego ld.gold z łańcucha narzędzi GNU, dodaj:
-Wl,--rosegment
Jeśli nadal widzisz niespójności w śladzie stosu (lub żadna z flag nie jest odpowiednia dla Twojego zestawu narzędzi), dodaj do procesu kompilacji te informacje:
-fno-omit-frame-pointer
Jak użyć własnego binarnego generatora plików symboli Breakpad na potrzeby NDK?
W pluginie Crashlytics jest zawarty niestandardowy generator pliku symboli Breakpad.
Jeśli wolisz używać własnego pliku binarnego do generowania plików symboli Breakpad (np. jeśli wolisz kompilować wszystkie natywne pliki wykonywalne w łańcuchu kompilacji z źródła), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary, aby określić ścieżkę do pliku wykonywalnego.
Ścieżkę do binarnego generatora plików symboli Breakpad możesz podać na 2 sposoby:
Opcja 1. W pliku build.gradle określ ścieżkę za pomocą rozszerzenia firebaseCrashlytics
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 executablesymbolGeneratorType="breakpad"breakpadBinary=file("/PATH/TO/BREAKPAD/DUMP_SYMS")}}}}
starsze wersje wtyczek,
android{// ...buildTypes{// ...release{// ...firebaseCrashlytics{// existing; required for either symbol file generatornativeSymbolUploadEnabledtrue// Add this optional new block to specify the path to the executablesymbolGenerator{breakpad{binaryfile("/PATH/TO/BREAKPAD/DUMP_SYMS")}}}}}
Opcja 2. Określ ścieżkę w wierszu właściwości w pliku właściwości Gradle
Możesz użyć właściwości com.google.firebase.crashlytics.breakpadBinary, aby określić ścieżkę do pliku wykonywalnego.
Plik właściwości Gradle możesz zaktualizować ręcznie lub za pomocą wiersza poleceń. Aby na przykład określić ścieżkę w wierszu poleceń, użyj polecenia podobnego do tego:
Dlaczego widzę awarie pochodzące z .kt plików oznaczonych jako problemy (.java)?
Jeśli aplikacja używa narzędzia do zaciemniania, które nie ujawnia rozszerzenia pliku,
Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java.
Aby Crashlytics mogła generować problemy z odpowiednią rozszerzeniem pliku, sprawdź, czy Twoja aplikacja używa tej konfiguracji:
Używa Androida Gradle 4.2.0 lub nowszej wersji.
Używa R8 z włączonym zaciemnieniem. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją.
Pamiętaj, że po przejściu na konfigurację opisaną powyżej możesz zacząć widzieć nowe problemy .kt, które są duplikami dotychczasowych problemów .java. Aby dowiedzieć się więcej o tych okolicznościach, zapoznaj się z najczęstszymi pytaniami.
Dlaczego widzę problemy .kt, które są duplikatami istniejących problemów .java?
W połowie grudnia 2021 r. Crashlytics wprowadziła lepszą obsługę aplikacji korzystających z języka Kotlin.
Do niedawna dostępne mechanizmy zaciemniania kodu nie ujawniały rozszerzenia pliku, więc usługa Crashlytics domyślnie generowała 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ślić, czy każda klasa używana w aplikacji jest napisana w Kotlinie, i uwzględnić poprawną nazwę pliku w signaturze problemu. Awarie są teraz poprawnie przypisywane do plików .kt (w odpowiednich przypadkach), jeśli aplikacja ma taką konfigurację:
Twoja aplikacja korzysta z Android Gradle w wersji 4.2.0 lub nowszej.
Twoja aplikacja używa R8 z włączonym zaciemnieniem.
Ponieważ nowe błędy zawierają teraz w swoich sygnaturach prawidłowe rozszerzenie pliku, możesz zobaczyć nowe problemy .kt, które są w istocie duplikami istniejących problemów z oznaczeniem .java. W konsoli Firebase staramy się zidentyfikować i poinformować Cię, jeśli nowy problem .kt jest możliwym duplikatem istniejącego problemu z oznaczeniem .java.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Uwagi umożliwiają uczestnikom projektu komentowanie konkretnych problemów, zadawanie pytań, informowanie o aktualizacjach stanu itp.
Gdy członek zespołu projektu opublikuje notatkę, zostanie ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail wraz z notatką jest widoczny dla wszystkich członków projektu, którzy mają uprawnienia do wyświetlania notatek.
Poniżej opisujemy uprawnienia wymagane do wyświetlania, zapisywania i usuwania notatek:
Uczestnicy projektu, którzy mają dowolną z tych ról, mogą wyświetlać i usuwać istniejące notatki oraz tworzyć nowe notatki dotyczące problemu.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Uwagi umożliwiają uczestnikom projektu komentowanie konkretnych problemów, zadawanie pytań, informowanie o aktualizacjach stanu itp.
Gdy członek zespołu projektu opublikuje notatkę, zostanie ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail wraz z notatką jest widoczny dla wszystkich członków projektu, którzy mają uprawnienia do wyświetlania notatek.
Poniżej opisujemy uprawnienia wymagane do wyświetlania, zapisywania i usuwania notatek:
Uczestnicy projektu, którzy mają dowolną z tych ról, mogą wyświetlać i usuwać istniejące notatki oraz tworzyć nowe notatki dotyczące problemu.
Aplikacja korzysta też z pakietu SDK Google Mobile Ads, ale nie ma awarii
Jeśli Twój projekt używa interfejsu Crashlytics razem z pakietem SDK Google Mobile Ads, prawdopodobnie narzędzia do zgłaszania awarii zakłócają rejestrowanie modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK Mobile Ads, wywołując funkcję disableSDKCrashReporting.
Gdzie znajduje się mój zbiór danych BigQuery?
Po połączeniu usługi Crashlytics z BigQuery nowe zbiory danych, które utworzysz, zostaną automatycznie umieszczone w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Pomoc dotycząca platformy
Czy Crashlytics obsługuje armeabi?
NDK Firebase Crashlytics nie obsługuje ARMv5 (armeabi).
Obsługa tego interfejsu ABI została usunięta w wersji NDK r17.
Problemy z regresją
Co to jest problem z powrotem do stanu poprzedniego?
Występuje ponowna regresja, ponieważ wcześniej został przez Ciebie zamknięty wcześniej, ale usługa Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu.
Crashlytics automatycznie otwiera te problemy, aby umożliwić ich rozwiązanie w sposób odpowiedni dla Twojej aplikacji.
Oto przykładowy scenariusz, który pokazuje, jak Crashlytics klasyfikuje problem jako regresję:
Po raz pierwszy Crashlytics otrzymał raport o awarii „A”. Crashlytics otwiera odpowiedni problem dotyczący tego błędu (problem „A”).
Szybko naprawiasz ten błąd, zamykasz problem „A”, a potem publikujesz nową wersję aplikacji.
Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po tym, jak został on zamknięty.
Jeśli raport pochodzi z wersji aplikacji, którą Crashlyticsznał w momencie zamknięcia problemu (co oznacza, że wersja wysłała raport o dowolnym załamaniu), Crashlytics nie uzna problemu za rozwiązany. Problem pozostanie zamknięty.
Jeśli raport pochodzi z wersji aplikacji, o której użytkownik Crashlyticsnie wiedział
o czymś w momencie zamknięcia problemu (czyli że ta wersja nigdy nie wysyłała żadnego raportu o awarii), Crashlytics uznaje, że problem wrócił do poprzedniego, i otworzy go ponownie.
Gdy problem wystąpi ponownie, wyślemy alert o wykryciu regresji i dodamy do problemu sygnał regresji, aby poinformować Cię, że usługa Crashlytics ponownie otworzyła problem. Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast go zamykać, „wycisz” go.
Dlaczego w starszych wersjach aplikacji widzę problemy?
Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysłała żadnych raportów o wypadkach, Crashlytics uzna, że problem uległ regresji, i ponownie otworzy zgłoszenie.
Może się to zdarzyć, gdy naprawisz błąd i opublikujesz nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki. Jeśli po zamknięciu problemu okazało się, że jedna z tych starszych wersji nigdy nie wysłała żadnych raportów o awariach, a użytkownicy zaczęli napotykać ten błąd, raporty o awariach spowodują problemy z powrotem.
Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast zamykać problem, „wycisz go”.
