Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
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.
Rozwiązywanie problemów/najczęstsze pytania
Różne formaty
(a czasem „warianty”) w przypadku niektórych problemów w tabeli Problemy.
W tabeli Problemy możesz zobaczyć 2 różne formaty problemów
w konsoli Firebase. Możesz też zauważyć funkcję
„warianty” w niektórych kwestiach. Oto dlaczego.
Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupujący zdarzenia jako
a także zaktualizowany wygląd i niektóre zaawansowane funkcje w przypadku nowych problemów (np.
wersji). Zobacz nasze najnowsze
post na blogu
.
Crashlytics analizuje wszystkie zdarzenia z aplikacji (np. awarie, błędy niekrytyczne i błędy ANR) oraz tworzy grupy zdarzeń o nazwie problemy – wszystkie zdarzenia w problemie mają wspólny punkt awarii.
Aby pogrupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje teraz:
wielu aspektów zdarzenia, w tym ramki zrzutu stosu,
komunikat o wyjątku, kod błędu oraz inną platformę lub typ błędu
dla niektórych cech produktu.
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 odzwierciedlić tę możliwą różnicę w ramach problemu, tworzymy
warianty w ramach problemów – każdy wariant jest podgrupą zdarzeń w danym problemie.
które mają ten sam punkt błędu i podobny zrzut 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:
Zmienione 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 złożonych problemów o różnych przyczynach Używaj wariantów do debugowania najczęstszych zrzutów stosu w obrębie problemu.
Bardziej przydatne alerty i sygnały Nowy problem to w rzeczywistości 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, automatycznie zastosujemy
lepszy sposób grupowania zdarzeń.
algorytm do zdarzenia i sformułować nowy problem ze zmienionymi metadanymi.
projektu.
To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkasz problem, prześlij raport.
Nie widać
dane o braku awarii lub alerty o 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
dzienniki menu nawigacyjnego,
zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że spełniasz te wymagania:
Szczególnie sprawdź, czy korzystasz przynajmniej z poniższej wersji programu
Pakiet SDK Firebase dla platformy 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 aplikacjach na Androida z urządzeń, które działają
Androida 11 lub nowszego, Interfejs API, którego używamy do zbierania ANR (getHistoricalProcessExitReasons), jest bardziej niezawodny niż podejście oparte na SIGQUIT lub watchdog. Ten interfejs API jest
dostępne tylko na urządzeniach z Androidem 11 lub nowszym.
Dlaczego niektóre błędy ANR nie mają BuildId?
Jeśli w przypadku niektórych błędów ANR brakuje parametrów BuildId, rozwiąż problemy w ten sposób:
Upewnij się, że używasz aktualnego pakietu SDK Androida Crashlytics oraz
Wersja wtyczki do obsługi Gradle w wersji Crashlytics.
Jeśli brakuje błędów (BuildId) dotyczących Androida 11 i niektórych błędów ANR w Androidzie 12,
prawdopodobnie używasz nieaktualnego pakietu SDK, wtyczki Gradle lub obu tych wersji.
Aby prawidłowo zbierać błędy BuildId w przypadku tych błędów ANR, musisz użyć tych
wersje:
CrashlyticsPakiet SDK na Androida w wersji 18.3.5 lub nowszej (Firebase BoM w wersji 31.2.2 lub nowszej)
Crashlytics wtyczka Gradle w wersji 2.9.4 lub nowszej;
Sprawdź, czy Twoje biblioteki udostępnione używają niestandardowej lokalizacji.
Jeśli brakuje tylko BuildId w bibliotekach udostępnionych aplikacji, prawdopodobnie nie używasz standardowej domyślnej lokalizacji bibliotek udostępnionych. Jeśli
w takim przypadku Crashlytics może nie być w stanie znaleźć
powiązane komponenty typu BuildId. Zalecamy użycie standardowego
lokalizacji bibliotek udostępnionych.
Sprawdź, czy podczas procesu kompilacji nie są usuwane elementy BuildId.
Pamiętaj, że te wskazówki dotyczące rozwiązywania problemów dotyczą zarówno błędów ANR, jak i reklam natywnych
awarii.
Sprawdź, czy pliki BuildId istnieją, uruchamiając w nich readelf -n. Jeśli
brak elementów BuildId, a następnie dodaj -Wl,--build-id do flag
systemu kompilacji.
Sprawdź, czy nie usuwasz przypadkiem tych elementów BuildId
, by zmniejszyć rozmiar pliku APK.
Jeśli przechowujesz wersje z usuniętymi i nieusuniętymi plikami, w kodzie musisz wskazać właściwą wersję.
Różnice między raportami ANR na panelu Crashlytics a Konsolą Google Play
Między liczbą błędów ANR w Google Play i w Google Play może występować niezgodność
Crashlytics Jest to spowodowane różnicą w mechanizmie
zbieranie i raportowanie danych o błędach ANR. Crashlytics raportuje błędy ANR, gdy aplikacja uruchomi się ponownie, a Android Vitals wysyła dane ANR po ich wystąpieniu.
Dodatkowo Crashlytics wyświetla tylko błędy ANR, które wystąpiły na urządzeniach z włączonym
Androida 11 i nowszych, w porównaniu z Google Play, który wyświetla błędy ANR na urządzeniach
Zaakceptowano Usługi Google Play i zgodę na zbieranie danych.
Różnice
między zrzutami stosu NDK w panelu Crashlytics i logcat
Łańcuchy narzędzi LLVM i GNU mają różne ustawienia domyślne i metody tylko do odczytu
segment plików binarnych aplikacji, co może powodować niespójne zrzuty stosu
w konsoli Firebase. Aby temu zaradzić, dodaj te flagi tagu łączącego
w procesie kompilacji:
Jeśli używasz linkera lld z zestawu 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żywać
mój własny plik binarny z symbolami Breakpada dla NDK?
Wtyczka Crashlytics zawiera
niestandardowy generator plików symboli Breakpad.
Jeśli wolisz używać własnych plików binarnych 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. Podaj ścieżkę za pomocą tagu firebaseCrashlytics
w pliku build.gradle
Do pliku build.gradle.kts na poziomie aplikacji dodaj te informacje:
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 executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
starsze wersje wtyczki
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ę w wierszu właściwości w Gradle
plik właściwości
Za pomocą usługi com.google.firebase.crashlytics.breakpadBinary
, 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ń. Aby na przykład podać ścieżkę za pomocą polecenia
, użyj polecenia podobnego do tego:
Dlaczego widzę awarie spowodowane plikami .kt oznaczonymi jako problemy .java?
Jeśli aplikacja używa zaciemnionego kodu, który nie ujawnia rozszerzenia pliku,
Crashlytics domyślnie generuje każdy problem z rozszerzeniem .java.
Aby usługa Crashlytics mogła generować problemy z prawidłowym rozszerzeniem pliku,
upewnij się, że aplikacja korzysta z tej konfiguracji:
Korzysta z Androida Gradle w wersji 4.2.0 lub nowszej
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. Zobacz
odpowiedziami na najczęstsze pytania, aby dowiedzieć się więcej o tej sytuacji.
Dlaczego widzę
.kt problemów jest duplikatami istniejących
.java problemu?
W połowie grudnia 2021 r. Crashlytics ulepszyła obsługę aplikacji
które korzystają z platformy Kotlin.
Do niedawna dostępne programy zaciemniające nie ujawniały rozszerzenia pliku,
Domyślnie Crashlytics wygenerował(a) każdy problem 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 poszczególne zajęcia są używane
aplikacja jest napisana w języku Kotlin i zawiera prawidłową nazwę pliku,
podpis. Awarie są teraz prawidłowo przypisywane do .kt plików (w stosownych przypadkach)
jeśli aplikacja ma taką konfigurację:
Twoja aplikacja używa Android Gradle 4.2.0 lub nowszej wersji.
Aplikacja używa R8 z włączonym zaciemnianiem kodu.
Nowe awarie mają teraz prawidłowe rozszerzenie pliku
podpisy, możesz zauważyć nowe problemy z kategorii .kt, które są w rzeczywistości duplikatami
obecne problemy z etykietą .java. W konsoli Firebase staramy się zidentyfikować
i powiadamiać Cię, czy nowy problem z .kt jest możliwym duplikatem
istniejący problem z etykietą: .java.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów związanych z pytaniami i stanem
aktualizacje itd.
Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego Google
koncie. Ten adres e-mail jest widoczny wraz z notatką dla całego projektu
użytkowników mających uprawnienia do wyświetlania notatki.
Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania
uwagi:
Członkowie projektu z dowolną z tych ról mogą wyświetlać i usuwać istniejące
notatki i pisanie nowych notatek na temat problemu.
Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w
problem, ale nie mogą usunąć ani napisać notatki.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów związanych z pytaniami i stanem
aktualizacje itd.
Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego Google
koncie. Ten adres e-mail jest widoczny wraz z notatką dla całego projektu
użytkowników mających uprawnienia do wyświetlania notatki.
Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisu i usuwania
uwagi:
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 Crashlytics i pakietu SDK Google Mobile Ads,
jest prawdopodobne, że narzędzia do zgłaszania awarii zakłócają działanie
rejestracji modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz zgłaszanie awarii w
pakiet SDK Mobile Ads, wywołując metodę disableSDKCrashReporting.
Gdzie znajduje się mój zbiór danych BigQuery?
Gdy połączysz usługę Crashlytics z BigQuery, nowe zbiory danych zostaną
znajduje się automatycznie w USA, niezależnie od lokalizacji
projekt 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 regresja
problem?
Problem został rozwiązany, ale po pewnym czasie Crashlytics otrzymał nowe zgłoszenie, że problem powrócił.
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 otrzymuje raport o awarii „A”. Crashlytics otworzy problem związany z tą awarią (problem „A”).
Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję
do 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 dotyczy wersji aplikacji, o której Crashlyticsnie wiedział w momencie zamykania problemu (czyli w tej wersji nigdy nie wysłano żadnego raportu o awarii), Crashlytics uzna, że problem został rozwiązany i ponownie otworzy zgłoszenie.
Gdy problem pogorszy się, wysyłamy alert o wykryciu regresji i dodajemy
sygnał regresji do problemu, informujący, że w wyniku Crashlytics
ponownie otworzył 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ę tak zdarzyć, jeśli: naprawiono błąd i
opublikowała nową wersję Twojej aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji
bez poprawek. Jeśli przez przypadek jedna ze starszych wersji nigdy nie została wysłana
żadnych raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczną
napotkania błędu, raporty o awariach wywołałyby ponowne wystąpienie problemu.
Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast zamykać problem, „wycisz go”.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2024-10-16 UTC."],[],[]]