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 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 tabeli Problemy widoczne są różne formaty (a czasem „warianty”) w przypadku niektórych problemów
W tabeli Problemy w konsoli Firebase mogą pojawić się 2 różne formaty problemów. W niektórych problemach możesz też zauważyć
funkcję o nazwie „Warianty”. Oto dlaczego.
Na początku 2023 r. wdrożyliśmy ulepszony mechanizm analizy grupowania zdarzeń, a także zaktualizowany wygląd i kilka zaawansowanych funkcji związanych z nowymi problemami (np. wariantami). Przeczytaj nasz najnowszy
post na blogu, aby poznać wszystkie szczegóły. Możesz też przeczytać najważniejsze informacje poniżej.
Crashlytics analizuje wszystkie zdarzenia z aplikacji (takie jak awarie, błędy niekrytyczne czy błędy ANR) i tworzy grupy zdarzeń nazywane problemami. Wszystkie zdarzenia związane z problemem mają wspólny punkt awarii.
Aby grupować zdarzenia w te problemy, ulepszony mechanizm analizy analizuje wiele aspektów zdarzenia, w tym ramki w zrzucie stosu, komunikat o wyjątku, kod błędu i inne cechy platformy lub typu błędu.
Jednak w tej grupie zdarzeń zrzuty stosu prowadzące do niepowodzenia mogą być inne. Inny zrzut stosu może oznaczać inną przyczynę problemu.
Aby odzwierciedlić tę możliwą różnicę w obrębie problemu, tworzymy teraz w obrębie problemu warianty – każdy wariant jest podgrupą zdarzeń związanych z problemem, które mają ten sam punkt błędu oraz podobny zrzut stosu. Dzięki wariantom możesz debugować najczęstsze zrzuty stosu w obrębie danego problemu i określić, czy różne główne przyczyny niepowodzenia prowadzą do problemów.
Oto, czego się spodziewać po wprowadzeniu tych ulepszeń:
Odświeżone metadane wyświetlane w wierszu problemu Teraz łatwiej zrozumiesz i sprawdzisz problemy z aplikacją.
Mniej zduplikowanych problemów Zmiana numeru wiersza nie powoduje utworzenia 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 danego problemu.
Bardziej przydatne alerty i sygnały Nowy problem w rzeczywistości oznacza nowy błąd.
Bardziej zaawansowane wyszukiwanie Każdy numer zawiera metadane, które łatwiej wyszukać, takie jak typ wyjątku i nazwa pakietu.
Oto jak wprowadzamy te ulepszenia:
Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy nie występują w nich jakieś problemy.
Jeśli nie uda się dopasować danych, automatycznie zastosujemy do wydarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z odświeżonym wyglądem metadanych.
To pierwsza duża aktualizacja, w której wprowadzamy zmiany w naszej grupie wydarzeń. Jeśli masz uwagi lub masz problemy, skontaktuj się z nami,
przesyłając zgłoszenie
.
Brak alertów dotyczących braku awarii lub alertów o rosnącej liczbie problemów
Jeśli nie widzisz danych o braku awarii (takich jak liczba użytkowników, u których nie wystąpiła awaria) lub alerty o porcie
Nie widzę logów menu nawigacyjnego
Jeśli nie widzisz dzienników menu nawigacyjnego, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.
Upewnij się, że spełniasz te wymagania:
Zwróć szczególną uwagę na to, 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 nowszej?
Crashlytics obsługuje raportowanie błędów ANR w aplikacjach na Androida na urządzeniach z Androidem 11 lub nowszym. Podstawowy interfejs API, którego używamy do rejestrowania błędów ANR (getHistoryProcessExitReasons), jest bardziej niezawodny niż metody SIGQUIT czy watchdog. Ten interfejs API jest dostępny tylko na urządzeniach z Androidem w wersji 11 lub nowszej.
Dlaczego w przypadku niektórych błędów ANR brakuje wartości BuildId?
Jeśli w przypadku niektórych błędów ANR brakuje błędów BuildId, rozwiąż problem w ten sposób:
Sprawdź, czy używasz aktualnej wersji pakietu SDK Crashlytics na Androida i wtyczki Crashlytics Gradle.
Jeśli brakuje niektórych błędów typu BuildId w przypadku Androida 11 i niektórych błędów ANR w Androidzie 12, prawdopodobnie używasz nieaktualnego pakietu SDK, wtyczki Gradle lub obu tych elementów.
Aby prawidłowo zbierać dane 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 w wersji 31.2.2 lub nowszej)
Wtyczka Crashlytics do Gradle w wersji 2.9.4 lub nowszej
Sprawdź, czy używasz niestandardowej lokalizacji na potrzeby swoich bibliotek udostępnionych.
Jeśli w bibliotekach udostępnionych aplikacji brakuje tylko funkcji BuildId, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek udostępnionych. W takim przypadku Crashlytics może nie być w stanie znaleźć powiązanych elementów BuildId. Zalecamy używanie standardowej lokalizacji
bibliotek udostępnionych.
Upewnij się, że podczas kompilacji nie są usuwane BuildId.
Te wskazówki dotyczące rozwiązywania problemów dotyczą zarówno błędów ANR, jak i awarii natywnych.
Sprawdź, czy BuildId istnieje, uruchamiając readelf -n w plikach binarnych. Jeśli brakuje BuildId, dodaj -Wl,--build-id do flag systemu kompilacji.
Sprawdź, czy przypadkowo nie usuwasz BuildId, staramy się zmniejszyć rozmiar pliku APK.
Jeśli przechowujesz skróconą i niezmienioną wersję biblioteki, pamiętaj, aby wskazać w kodzie odpowiednią wersję.
Różnice między raportami o błędach ANR w panelu Crashlytics a Konsoli Google Play
Liczba błędów ANR w Google Play i Crashlytics może nie być zgodna. Jest to spowodowane różnicą w mechanizmie gromadzenia i raportowania danych o błędach ANR. Crashlytics zgłasza błędy ANR podczas następnego uruchomienia aplikacji, a Android Vitals wysyła dane o błędach ANR po ich wystąpieniu.
Dodatkowo Crashlytics wyświetla tylko błędy ANR na urządzeniach z Androidem 11 lub nowszym. W przeciwieństwie do Google Play wyświetla błędy ANR z urządzeń, na których zaakceptowano usługi Google Play i zaakceptowano zgodę na gromadzenie 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 funkcje dla segmentu plików binarnych aplikacji przeznaczonych tylko do odczytu, co może powodować niespójne zrzuty stosu w konsoli Firebase. Aby temu zaradzić, dodaj do procesu kompilacji te flagi łączące:
Jeśli używasz tagu łączącego lld z łańcucha narzędzi LLVM, dodaj:
-Wl,--no-rosegment
Jeśli używasz 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 jeśli żadna z tych flag nie ma związku z łańcuchem narzędzi), spróbuj zamiast tego dodać do procesu kompilacji ten fragment:
-fno-omit-frame-pointer
Jak mogę użyć własnego pliku binarnego generatora plików symboli Breakpad dla NDK?
Wtyczka Crashlytics zawiera niestandardowy generator plików symboli Breakpad.
Jeśli do generowania plików symboli Breakpad wolisz używać własnego pliku binarnego (np. jeśli wolisz tworzyć wszystkie natywne pliki wykonywalne w łańcuchu kompilacji na podstawie źródła), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary, by określić ścieżkę do pliku wykonywalnego.
Ścieżkę do pliku binarnego generatora plików symboli Breakpad możesz określić na jeden z 2 sposobów:
Opcja 1. Określ ścieżkę za pomocą rozszerzenia firebaseCrashlytics w pliku build.gradle
Dodaj ten kod 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 executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
niższe 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ę za pomocą wiersza właściwości w pliku właściwości Gradle.
Aby podać ścieżkę do pliku wykonywalnego, możesz użyć 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 na przykład określić ścieżkę w wierszu poleceń, użyj tego polecenia:
Dlaczego widzę awarie w plikach .kt oznaczonych jako problemy .java?
Gdy aplikacja korzysta z zaciemniającego kodu, który nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java.
Aby Crashlytics mogło 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 zaciemnianiem. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją.
Po zaktualizowaniu do konfiguracji opisanej powyżej mogą pojawić się nowe problemy z .kt, które są duplikatami istniejących problemów typu .java. Więcej informacji na ten temat znajdziesz w najczęstszych pytaniach.
Dlaczego widzę problemy (.kt), które są duplikatami istniejących problemów typu .java?
W połowie grudnia 2021 r. zespół Crashlytics zaczął obsługiwać aplikacje korzystające z Kotlin.
Do niedawna dostępne metody zaciemniania danych nie ujawniały rozszerzenia pliku, więc Crashlytics domyślnie generowało każdy problem z rozszerzeniem pliku .java.
Jednak od Androida Gradle w wersji 4.2.0 wersja 4.2.0 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ć w podpisie problemu prawidłową nazwę pliku. Awarie są teraz prawidłowo przypisywane do plików .kt, jeśli aplikacja ma taką konfigurację:
Aplikacja używa Androida Gradle w wersji 4.2.0 lub nowszej.
Aplikacja używa R8 z włączonym zaciemnianiem kodu.
Nowe awarie zawierają teraz poprawne rozszerzenie pliku w sygnałach problemów, więc możesz zauważyć nowe problemy z .kt, które są w rzeczywistości duplikatami istniejących problemów z etykietą .java. W konsoli Firebase staramy się wykrywać i informować Cię, jeśli 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ą członkom projektu komentowanie konkretnych problemów związanych z pytaniami, aktualizacjami stanu itp.
Gdy członek projektu opublikuje notatkę, jest 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 jej wyświetlania.
Poniżej znajdziesz opis uprawnień wymaganych do wyświetlania, pisania i usuwania notatek:
Członkowie projektu z dowolną z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?
Notatki umożliwiają członkom projektu komentowanie konkretnych problemów związanych z pytaniami, aktualizacjami stanu itp.
Gdy członek projektu opublikuje notatkę, jest 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 jej wyświetlania.
Poniżej znajdziesz opis uprawnień wymaganych do wyświetlania, pisania i usuwania notatek:
Członkowie projektu z dowolną z poniższych ról mogą wyświetlać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.
Aplikacja korzysta też z pakietu SDK do reklam mobilnych Google, ale nie ulega awarii
Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobnie zgłaszający awarie zakłócają proces rejestrowania 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 disableSDKCrashReporting.
Gdzie znajduje się mój zbiór danych BigQuery?
Gdy połączysz Crashlytics z BigQuery, nowe zbiory danych, które utworzysz, będą automatycznie znajdować się w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.
Pomoc dotycząca platformy
Czy Crashlytics obsługuje armeabi?
Pakiet NDK Firebase Crashlytics nie obsługuje ARMv5 (armeabi).
Obsługa tego interfejsu ABI została wycofana od wersji NDK r17.
Problemy wycofane
Co to jest problem, który pojawił się ponownie?
Po zamknięciu przez Ciebie wcześniej problemu powrócił on do normalnego stanu, ale Crashlytics otrzyma nowy raport o ponownym wystąpieniu problemu.
Crashlytics automatycznie ponownie otwiera te problemy, aby można było je naprawić w sposób odpowiedni dla 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 otworzy odpowiedni problem związany z tą awarią (problem „A”).
Szybko naprawiasz ten błąd, zamykasz problem „A” i publikujesz nową wersję aplikacji.
Gdy go zamkniesz, Crashlytics otrzyma kolejny raport dotyczący problemu „A”.
Jeśli raport pochodzi z wersji aplikacji, o której usługa Crashlytics była znana w momencie zamknięcia problemu (co oznacza, że wysłała raport o awarii w przypadku każdej awarii), Crashlytics nie uzna go za problem ponownie występujący. Problem pozostanie zamknięty.
Jeśli raport dotyczy wersji aplikacji, o której usługa Crashlytics nie wiedziała w momencie zamknięcia problemu (co oznacza, że ta wersja nigdy w ogóle nie wysyłała żadnego raportu o awarii), Crashlytics uzna problem za niewystępujący i ponownie go otworzy.
Gdy problem wystąpi ponownie, wyślemy alert dotyczący wykrywania regresji i dodamy do niego sygnał, aby poinformować Cię, że Crashlytics ponownie uruchomiło problem. Jeśli nie chcesz, aby problem otwierał się ponownie z powodu naszego algorytmu regresji, zamiast go zamykać, możesz go „zignorować”.
Dlaczego w przypadku starszych wersji aplikacji pojawiają się problemy, które ponownie się pojawiły?
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 się powtarza, i ponownie go otworzy.
Może się tak zdarzyć w takiej sytuacji: naprawiono błąd i opublikowano nową wersję aplikacji, ale użytkownicy nadal korzystają ze starszych wersji bez tych poprawek. Jeśli przypadkiem jedna ze starszych wersji nigdy w ogóle nie wysłała żadnych raportów o awariach w momencie zamknięcia problemu, a użytkownicy zaczęli napotkać błąd, wtedy te raporty o awariach wywołałyby problem ponownie.
Jeśli nie chcesz, aby problem otwierał się ponownie z powodu naszego algorytmu regresji, zamiast go zamykać, „zignoruj” go.