Rozwiązywanie problemów z Crashlytics i 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. Wyjaśniamy 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, niekrytyczne, i błędy ANR) oraz tworzy grupy zdarzeń nazywane problemami – wszystkie mają wspólne punkty 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.

Jednak w ramach tej grupy zdarzeń zrzuty stosu prowadzące do błędu może być inna. 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. W przypadku wariantów możesz debugować typowe zrzuty stosu w obrębie problemu i sprawdzić, czy mają różne przyczyny.

Oto zalety tych ulepszeń:

• Ulepszone metadane wyświetlane w wierszu problemu
  Teraz łatwiej jest zrozumieć i eliminować problemy z aplikacją.

• 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 oznacza nowy błąd.

• Bardziej zaawansowane wyszukiwanie
  Każdy numer zawiera więcej metadanych, które można wyszukać, np. typ wyjątku i nazwę pakietu.

Oto jak wprowadzamy te ulepszenia:

• Gdy otrzymamy nowe zdarzenia z aplikacji, sprawdzimy, czy pasują do istniejących Google Cloud.

• Jeśli nie, automatycznie zastosujemy lepszy sposób grupowania zdarzeń. do zdarzenia i sformułować nowy problem ze zmienionymi metadanymi. projektu.

To pierwsza duża aktualizacja, którą wprowadzamy w grupowaniu wydarzeń. Jeśli Jeśli masz uwagi lub napotkasz jakieś problemy, skontaktuj się z nami do i wypełnianie zgłoszenia.

Nie widać dane o braku awarii lub alerty o szybkości

Jeśli nie widzisz danych, w których przypadku nie wystąpiła awaria (np. liczby użytkowników i sesji, w których przypadku nie wystąpiła awaria) i/lub alertów o rosnącej liczbie problemów, upewnij się, że używasz funkcji Pakiet SDK Crashlytics w wersji 18.6.0 lub nowszej (albo Firebase BoM w wersji 32.6.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:

• Masz włączono Google Analytics w projekcie Firebase.

• Włączono udostępnianie danych dla: Google Analytics. Więcej informacji o to ustawienie w Zarządzanie ustawieniami udostępniania danych Analytics

• Masz dodał pakiet SDK Firebase dla aplikacji Google Analytics do Twojej aplikacji. Ten pakiet SDK należy dodatkowo dodać do Crashlytics SDK.

• Używasz najnowsze wersje pakietu SDK Firebase w przypadku wszystkich produktów, których używasz w aplikacji.

  Szczególnie sprawdź, czy korzystasz przynajmniej z poniższej wersji programu Pakiet SDK Firebase dla platformy Google Analytics:
  Android – wersja 17.2.3 lub nowsza (BoM w wersji 24.7.1 lub nowszej).

Dlaczego występują tylko błędy ANR na urządzeniach z Androidem 11 i nowszym?

Crashlytics obsługuje raportowanie błędów ANR w aplikacjach na Androida z urządzeń, które działają Androida 11 lub nowszego, bazowy interfejs API, którego używamy do zbierania informacji o błędach ANR; (getHistoryProcessExitReasons) jest bardziej wiarygodne niż metody SIGQUIT czy watchdoga. Ten interfejs API jest dostępne tylko na urządzeniach z Androidem 11 lub nowszym.

Dlaczego brakuje niektórych błędów ANR ich 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:

  • Crashlytics Android SDK w wersji 18.3.5 lub nowszej (Firebase BoM wersja 31.2.2 lub nowsza)
  • Wtyczka Gradle Crashlytics 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 Twojej aplikacji, prawdopodobnie że 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 zachowasz uproszczone i nieskrócone wersje biblioteki, wskazuje prawidłową wersję kodu.

Różnice między raportami ANR w panelu Crashlytics – Konsola 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. Aplikacja Crashlytics zgłasza błędy ANR, gdy aplikacja Android Vitals wysyła dane o błędzie ANR po jego 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 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 w zrzucie stosu nadal występują niespójności (lub jeśli żadna z flag zgodnie z Twoim łańcuchem narzędzi), spróbuj dodać do swojego procesu tworzenia następujące elementy zamiast:

-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żyć własnego pliku binarnego do generowania plików symboli Breakpad (na Jeśli na przykład w łańcuchu kompilacji wolisz tworzyć wszystkie natywne pliki wykonywalne w łańcuchu kompilacji źródła), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary, aby określić ścieżkę do pliku wykonywalnego.

Możesz podać ścieżkę do pliku binarnego generatora plików symboli Breakpad w jednym 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 w celu określenia ścieżki 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:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Nie występują awarie przy Dexguard

Jeśli widzisz następujący wyjątek, najprawdopodobniej używasz wersji System DexGuard, który jest niezgodny z pakietem SDK Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Ten wyjątek nie powoduje awarii aplikacji, ale uniemożliwia jej wysyłanie awarii raportów. Aby rozwiązać ten problem:

1. Upewnij się, że używasz najnowszej wersji DexGuard 8.x. Najnowsza wersja zawiera reguły wymagane przez pakiet SDK Firebase Crashlytics.

2. Jeśli nie chcesz zmieniać wersji DexGuard, dodaj ten kod do reguł zaciemniania kodu (w pliku konfiguracyjnym DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct
   

Dlaczego widzę awarie z .kt plików oznaczonych 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 zaciemnianiem kodu. Aby zaktualizować aplikację do wersji R8, wykonaj te czynności dokumentacja.

Po aktualizacji do konfiguracji opisanej powyżej możesz widzieć nowe problemy (.kt), które są duplikatami istniejących 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 Androida Gradle w wersji 4.2.0 lub nowszej.
• 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.

  • Właściciel lub Edytujący projekt, Administrator Firebase, Administrator jakości, lub Administrator Crashlytics

• Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w problem, ale nie może usunąć ani napisać notatki.

  • Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość, lub Wyświetlający Crashlytics

Jak obliczana jest liczba użytkowników, u których nie wystąpiła awaria?

Zapoznaj się z sekcją Dane o braku awarii.

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.

  • Właściciel lub Edytujący projekt, Administrator Firebase, Administrator jakości, lub Administrator Crashytics

• Członkowie projektu, którzy mają przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane w problem, ale nie może usunąć ani napisać notatki.

  • Wyświetlający projekt, Wyświetlający Firebase, Wyświetlający jakość, lub Wyświetlający Crashlytics

Aplikacja używa też Google Mobile Ads pakiet SDK, ale nie występują awarie

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.

Czy w Crashlytics obsługuje się orlea armeabi?

NDK Firebase Crashlytics nie obsługuje ARMv5 (armeabi). Obsługa tego interfejsu ABI została usunięta od NDK r17.

Co to jest regresja problem?

Występuje regresja, gdy wcześniej został przez Ciebie zamknięty problem, ale Crashlytics otrzymuje nowy raport z informacją o powtórnym powtórzeniu problemu. Crashlytics automatycznie ponownie otworzy te wykryte problemy, aby umożliwić Ci odpowiednio do potrzeb aplikacji.

Oto przykładowy scenariusz, który wyjaśnia, jak Crashlytics kategoryzuje kategorię jako regresji.

1. Crashlytics po raz pierwszy otrzymuje raport o awarii „A”. Crashlytics otworzy problem związany z tą awarią (problem „A”).
2. Szybko naprawiasz błąd, zamknij problem „A”, a następnie opublikujesz nową wersję do aplikacji.
3. Crashlytics otrzymuje kolejny raport o problemie „A” po zamknięciu Google Cloud.
   • Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics znał(a) kiedy zamknięto problem (co oznacza, że wersja spowodowała awarię). w ogóle nie zgłosi żadnej awarii), Crashlytics nie weźmie pod uwagę a wraz z nim ponownie. Problem pozostanie zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, która Crashlytics nienie będzie wiedzieć, kiedy zamknęliśmy problem (co oznacza, że wersja nigdy nie wysłał(a) żadnego raportu o awariach), a następnie Użytkownik Crashlytics uzna, że problem ustąpił, i ponownie otworzy Google Cloud.

Gdy problem ustąpi, 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 dany problem został ponownie otwarty ze względu na nasze algorytm regresji, „mute”; problemu, zamiast ją zamykać.

Dlaczego u mnie się pogorszył problemów ze starszymi wersjami aplikacji?

Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysyłała żadnych raportów o awariach na po zamknięciu problemu Crashlytics uwzględni problem został rozwiązany i zostanie ponownie otwarty.

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 był ponownie otwierany przez nasz algorytm regresji, kliknij „Wycisz”. problemu, zamiast ją zamykać.