Rozwiązywanie problemów z Crashlytics i najczęstsze pytania
Na tej stronie znajdziesz pomoc w rozwiązywaniu problemów oraz odpowiedzi na najczęstsze pytania dotyczące korzystania z 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
W przypadku niektórych problemów w tabeli Problemy widzę różne formaty (a czasem „warianty”).
W tabeli Problemy w konsoli Firebase możesz zobaczyć 2 różne formaty problemów. 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 w danym problemie mają wspólny punkt awarii.
Aby pogrupować 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.
Jednak w przypadku tej grupy zdarzeń zrzuty stosu prowadzące do awarii mogą być inne. Inny zrzut stosu może oznaczać inną przyczynę problemu.
Aby przedstawić tę możliwą różnicę w danym problemie, tworzymy teraz warianty w problemach. Każdy wariant jest podgrupą zdarzeń w danym problemie, które mają ten sam punkt błędu i podobny zrzut stosu. Dzięki wariantom możesz debugować najczęstsze zrzuty stosu związane z danym problemem i ustalić, czy do niepowodzenia prowadzą różne główne przyczyny.
Oto zalety tych ulepszeń:
Ulepszone metadane wyświetlane w wierszu problemu Teraz łatwiej jest zrozumieć i eliminować problemy występujące w aplikacji.
Mniej zduplikowanych problemów Zmiana numeru wiersza nie powoduje pojawienia się nowego problemu.
Łatwiejsze debugowanie złożonych problemów o różnych głównych przyczynach Używaj wariantów do debugowania najczęstszych zrzutów stosu w przypadku danego problemu.
Bardziej istotne alerty i sygnały Nowy problem oznacza nowy błąd.
Skuteczniejsze wyszukiwanie Każdy problem zawiera metadane, które można przeszukiwać, np. typ wyjątku i nazwę pakietu.
Oto jak wprowadzamy te ulepszenia:
Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują do istniejącego problemu.
Jeśli nie znajdziemy dopasowania, automatycznie zastosujemy do zdarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem ze odnowionymi metadanymi.
To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkać jakieś problemy, skontaktuj się z nami,
wypełniając zgłoszenie
.
Brak wskaźników bezawaryjnej pracy lub alertów o rosnącej liczbie problemów
Jeśli nie widzisz danych o braku awarii (takich jak użytkownicy i sesje bez awarii)
ani alertów o szybkości
Nie widzę logów menu nawigacyjnego
Jeśli nie widzisz logów menu nawigacyjnego, sprawdź konfigurację aplikacji pod kątem Google Analytics.
Upewnij się, że spełniasz te wymagania:
W szczególności sprawdź, czy używasz co najmniej tej wersji pakietu SDK Firebase dla Google Analytics: Android – wersja 17.2.3 lub nowsza(BoM w wersji 24.7.1 lub nowszej).
Dlaczego błędy ANR są zgłaszane tylko w przypadku Androida w wersji 11 i nowszych?
Crashlytics obsługuje raportowanie błędów ANR w aplikacjach na Androida z urządzeń 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 lub nowszym.
Dlaczego w przypadku niektórych błędów ANR brakuje parametrów 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 aktualnej wersji pakietu SDK Crashlytics na Androida i wtyczki Crashlytics do Gradle.
Jeśli brakuje błędów BuildId w Androidzie 11 i niektórych błędach 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żywać tych wersji:
Pakiet SDK Crashlytics na Androida w wersji 18.3.5 lub nowszej (Firebase BoM 31.2.2 lub nowszy)
Wtyczka Crashlytics do Gradle w wersji 2.9.4 lub nowszej
Sprawdź, czy Twoje biblioteki udostępnione używają niestandardowej lokalizacji.
Jeśli brakuje tylko bibliotek BuildId w bibliotekach udostępnionych aplikacji, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji dla bibliotek udostępnionych. W takim przypadku Crashlytics może nie być w stanie znaleźć powiązanych elementów BuildId. Zalecamy korzystanie ze standardowej
lokalizacji w przypadku bibliotek udostępnionych.
Sprawdź, czy podczas procesu kompilacji nie są usuwane elementy BuildId.
Te wskazówki dotyczące rozwiązywania problemów dotyczą zarówno błędów ANR, jak i awarii natywnych.
Sprawdź, czy pliki BuildId istnieją, uruchamiając w nich readelf -n. Jeśli brakuje BuildId, dodaj -Wl,--build-id do flag systemu kompilacji.
Sprawdź, czy nie usuwasz przypadkowo elementów BuildId, starając się 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 w panelu Crashlytics a Konsoli Google Play
Między liczbą błędów ANR w Google Play i Crashlytics może być niezgodność. Jest to spowodowane różnicami w mechanizmach zbierania i raportowania danych o błędach ANR. Crashlytics zgłasza błędy ANR przy kolejnym uruchomieniu aplikacji, a Android Vitals wysyła ich dane już po wystąpieniu tego błędu.
Dodatkowo Crashlytics wyświetla tylko błędy ANR na urządzeniach z Androidem 11 i nowszym, a 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 zrzutami stosu NDK w panelu Crashlytics a logcatem
Łańcuchy narzędzi LLVM i GNU mają różne ustawienia domyślne i metody działania dla segmentu plików binarnych aplikacji tylko do odczytu, co może powodować niespójne zrzuty stosu w konsoli Firebase. Aby temu zapobiec, dodaj do procesu kompilacji te flagi tagu łączącego:
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 zrzucie stosu (lub żadna z flag nie pasuje do Twojego łańcucha narzędzi), spróbuj w procesie kompilacji dodać te elementy:
-fno-omit-frame-pointer
Jak użyć własnego pliku binarnego generatora plików symboli Breakpad dla NDK?
Wtyczka Crashlytics zawiera dostosowany generator plików symboli Breakpad.
Jeśli wolisz używać własnego pliku binarnego do generowania plików symboli Breakpad (jeśli na przykład wolisz tworzyć na podstawie źródła wszystkie natywne pliki wykonywalne w łańcuchu kompilacji), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary, aby określić ścieżkę do pliku wykonywalnego.
Ścieżka do pliku binarnego generatora plików symboli Breakpad możesz określić na 2 sposoby:
Opcja 1. Podaj ścieżkę w pliku build.gradle za pomocą rozszerzenia firebaseCrashlytics
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 pliku właściwości Gradle
Ścieżkę do pliku wykonywalnego możesz określić za pomocą właściwości com.google.firebase.crashlytics.breakpadBinary.
Możesz ręcznie zaktualizować plik właściwości Gradle lub zaktualizować go za pomocą wiersza poleceń. Aby np. podać ścieżkę w wierszu poleceń, użyj tego polecenia:
Dlaczego widzę awarie pochodzące z .kt plików oznaczonych jako problemy (.java)?
Gdy aplikacja używa zaciemnionego kodu, który nie ujawnia rozszerzenia pliku, Crashytics domyślnie generuje każdy problem z rozszerzeniem .java.
Aby Crashlytics mogła generować problemy z prawidłowym rozszerzeniem pliku, aplikacja powinna korzystać z tej konfiguracji:
Korzysta z Androida Gradle w wersji 4.2.0 lub nowszej
Używa R8 z włączonym zaciemnianiem kodu. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją.
Pamiętaj, że po zaktualizowaniu konfiguracji opisanej powyżej mogą zacząć pojawiać się nowe problemy z usługą .kt, które są duplikatami istniejących problemów z usługą .java. Aby dowiedzieć się więcej o tej sytuacji, przeczytaj Najczęstsze pytania.
Dlaczego widzę .kt problemów, które są duplikatami istniejących problemów z usługą .java?
W połowie grudnia 2021 r. Crashlytics ulepszyła obsługę aplikacji korzystających z Kotlina.
Do niedawna dostępne funkcje zaciemniania kodu nie ujawniały rozszerzenia pliku, więc Crashlytics domyślnie generowała każdy problem z rozszerzeniem .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 Kotlin, i umieścić prawidłową nazwę pliku w podpisie problemu. Awarie są teraz prawidłowo przypisywane do plików .kt (w stosownych przypadkach), jeśli aplikacja ma taką konfigurację:
Twoja aplikacja używa Androida Gradle w wersji 4.2.0 lub nowszej.
Aplikacja używa R8 z włączonym zaciemnianiem kodu.
Ponieważ nowe awarie mają teraz prawidłowe rozszerzenie pliku w sygnaturach problemów, możesz zauważyć nowe problemy z usługą .kt, które w rzeczywistości są duplikatami istniejących problemów z etykietą .java. W konsoli Firebase staramy się zidentyfikować i powiadomić Cię, czy nowy problem z .kt jest możliwym duplikatem istniejącego problemu z etykietą .java.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów, w tym pytania, aktualizacje stanu itp.
Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich użytkowników projektu, którzy mają uprawnienia do wyświetlania notatki.
Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisywania i usuwania notatek:
Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe na temat problemu.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają uczestnikom projektu komentowanie konkretnych problemów, w tym pytania, aktualizacje stanu itp.
Gdy członek projektu opublikuje notatkę, zostanie ona oznaczona etykietą z adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich użytkowników projektu, którzy mają uprawnienia do wyświetlania notatki.
Poniżej znajdziesz informacje o uprawnieniach wymaganych do wyświetlania, zapisywania i usuwania notatek:
Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe na temat problemu.
Aplikacja używa też pakietu SDK do reklam mobilnych Google, ale nie występują żadne awarie
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, funkcje zgłaszania awarii prawdopodobnie zakłócają rejestrację modułów 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.
Gdzie znajduje się mój zbiór danych BigQuery?
Po połączeniu 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?
Firebase Crashlytics NDK nie obsługuje ARMv5 (armeabi).
Obsługa tego interfejsu ABI została usunięta od NDK r17.
Problemy, które pojawiły się znowu
Co to jest problem, który pojawił się ponownie?
Wystąpił problem po wcześniejszym zamknięciu przez Ciebie problemu, ale Crashytics otrzymuje nowy raport o powtórnym wystąpieniu problemu.
Crashlytics automatycznie ponownie otwiera te problemy, aby rozwiązać je w sposób odpowiedni dla Twojej aplikacji.
Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics klasyfikuje problem jako regresję:
Po raz pierwszy Crashlytics otrzymuje raport o awarii „A”. Crashlytics wyświetli odpowiedni problem dotyczący tej awarii (problem „A”).
Szybko naprawisz ten błąd, zamknij problem „A” i opublikujesz nową wersję aplikacji.
Gdy zamkniesz zgłoszenie, Crashlytics otrzyma kolejny raport o problemie „A”.
Jeśli raport pochodzi z wersji aplikacji, którą Crashlytics znała w momencie zamykania problemu (co oznacza, że ta wersja wysłała raport o żadnej awarii), Crashlytics nie uzna problemu za ponownie regresję. Problem pozostanie zamknięty.
Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedziała w momencie zamknięcia problemu (co oznacza, że ta wersja nigdy nie wysyłała żadnego raportu o awarii), Crashlytics uzna, że problem wrócił do poprzedniego i otworzy go ponownie.
Gdy problem pogarsza się, wysyłamy alert o wykryciu regresji i dodajemy do problemu sygnał regresji, aby poinformować Cię, że Crashlytics ponownie otworzyła problem. Jeśli nie chcesz, aby problem był ponownie otwierany przez nasz algorytm regresji, „zignoruj” go, zamiast go zamykać.
Dlaczego w starszych wersjach aplikacji występują ponownie problemy?
Jeśli raport pochodzi ze starej wersji aplikacji, w której w momencie zamknięcia problemu nie były wysyłane żadne raporty o awariach, Crashlytics uzna, że problem wystąpił ponownie, i ponownie go otworzy.
Może się tak zdarzyć, jeśli błąd został już naprawiony i opublikowana została nowa wersja aplikacji, ale użytkownicy nadal korzystają ze starszych wersji, które nie zostały już poprawione. Jeśli przez przypadek jedna ze starszych wersji nigdy w ogóle nie wysyłała raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczną napotkać ten błąd, raporty o awariach będą wywoływać ten problem.
Jeśli nie chcesz, aby problem był ponownie otwierany przez nasz algorytm regresji, „zignoruj” go, zamiast go zamykać.