Rozwiązywanie problemów i często zadawane pytania dotyczące Crashlytics

Nie widzę użytkowników bez awarii, dzienników nawigacyjnych i/lub alertów dotyczących prędkości

Jeśli nie widzisz użytkowników bez awarii, dzienników nawigacji i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.

• Upewnij się, że w swoim projekcie Firebase włączyłeś Google Analytics .

• Upewnij się, że Udostępnianie danych dla Google Analytics jest włączone na stronie Integracje > Google Analytics w konsoli Firebase. Pamiętaj, że ustawienia udostępniania danych są wyświetlane w konsoli Firebase, ale zarządza się nimi w konsoli Google Analytics.

• Oprócz pakietu SDK Firebase Crashlytics upewnij się, że do swojej aplikacji dodałeś pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).

• Upewnij się, że używasz najnowszych wersji wszystkich zestawów SDK Firebase ( iOS+ | Android ).
  W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu SDK Firebase dla Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — v17.2.3+ (BoM v24.7.1+) .

Wyświetlanie różnych formatów (a czasem „wariantów”) niektórych problemów w tabeli Problemy

Możesz zauważyć dwa różne formaty problemów wymienionych w tabeli Problemy w konsoli Firebase. W niektórych problemach możesz także zauważyć funkcję zwaną „wariantami”. Dlatego!

Na początku 2023 r. wprowadziliśmy ulepszony silnik analityczny do grupowania wydarzeń, a także zaktualizowany projekt i kilka zaawansowanych funkcji dla nowych problemów (takich jak warianty!). Wszystkie szczegóły znajdziesz w naszym najnowszym poście na blogu , ale najważniejsze informacje znajdziesz poniżej.

Crashlytics analizuje wszystkie zdarzenia z Twojej aplikacji (takie jak awarie, zdarzenia inne niż krytyczne i błędy ANR) i tworzy grupy zdarzeń zwane problemami — wszystkie zdarzenia w problemie mają wspólny punkt awarii.

Aby pogrupować zdarzenia w te problemy, ulepszony silnik analizy analizuje obecnie wiele aspektów zdarzenia, w tym ramki w śladzie stosu, komunikat wyjątku, kod błędu i inne cechy platformy lub typu błędu.

Jednak w obrębie tej grupy zdarzeń ślady stosu prowadzące do awarii mogą być inne. Inny ślad stosu może oznaczać inną przyczynę podstawową. Aby przedstawić tę możliwą różnicę w obrębie problemu, tworzymy teraz warianty w obrębie problemów — każdy wariant jest podgrupą zdarzeń w problemie, które mają ten sam punkt awarii i podobny ślad stosu. Dzięki wariantom możesz debugować najczęstsze ślady stosu w obrębie problemu i określić, czy do niepowodzenia prowadzą różne przyczyny główne.

Oto, czego doświadczysz dzięki tym ulepszeniom:

• Zmienione metadane wyświetlane w wierszu problemu
  Teraz łatwiej jest zrozumieć i ocenić problemy w aplikacji.

• Mniej duplikatów problemów
  Zmiana numeru linii nie powoduje nowego problemu.

• Łatwiejsze debugowanie złożonych problemów z różnymi przyczynami źródłowymi
  Użyj wariantów, aby debugować najczęstsze ślady stosu w ramach problemu.

• Bardziej znaczące alerty i sygnały
  Nowy problem w rzeczywistości oznacza nowy błąd.

• Mocniejsze wyszukiwanie
  Każde wydanie zawiera więcej metadanych, które można przeszukiwać, takich jak typ wyjątku i nazwa pakietu.

Oto jak wdrażane są te ulepszenia:

• Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują one do istniejącego problemu.

• Jeśli nie ma dopasowania, automatycznie zastosujemy do zdarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.

To pierwsza duża aktualizacja, którą wprowadzamy w naszym grupowaniu wydarzeń. Jeśli masz uwagi lub napotkasz jakiekolwiek problemy, daj nam znać, przesyłając raport.

Dlaczego błędy ANR są zgłaszane tylko w przypadku Androida 11 lub nowszego?

Crashlytics obsługuje raportowanie ANR dla aplikacji na Androida z urządzeń z Androidem 11 i nowszym. Podstawowy interfejs API, którego używamy do zbierania błędów ANR ( getHistoricalProcessExitReasons ) jest bardziej niezawodny niż podejścia oparte na SIGQUIT lub watchdogu. Ten interfejs API jest dostępny tylko na urządzeniach z Androidem 11 lub nowszym.

Dlaczego w niektórych komunikatach ANR brakuje identyfikatorów BuildId ?

Jeśli w niektórych komunikatach ANR brakuje identyfikatorów BuildId , rozwiąż problem w następujący sposób:

• Upewnij się, że używasz aktualnej wersji pakietu Crashlytics Android SDK i wtyczki Crashlytics Gradle.

  Jeśli brakuje BuildId dla Androida 11 i niektórych błędów ANR dla Androida 12, prawdopodobnie używasz nieaktualnego pakietu SDK, wtyczki Gradle lub obu. Aby poprawnie zbierać BuildId dla tych błędów ANR, musisz użyć następujących wersji:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Wtyczka Crashlytics Gradle v2.9.4+

• Sprawdź, czy używasz niestandardowej lokalizacji dla swoich bibliotek współdzielonych.

  Jeśli brakuje tylko identyfikatorów BuildId dla bibliotek współdzielonych aplikacji, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek współdzielonych. W takim przypadku Crashlytics może nie być w stanie zlokalizować powiązanych identyfikatorów BuildId . Zalecamy rozważenie użycia standardowej lokalizacji bibliotek współdzielonych.

• Upewnij się, że nie usuwasz BuildId s podczas procesu kompilacji.

  Pamiętaj, że poniższe wskazówki dotyczące rozwiązywania problemów dotyczą zarówno błędów ANR, jak i awarii natywnych.

  • Sprawdź, czy BuildId s istnieje, uruchamiając readelf -n w swoich plikach binarnych. Jeśli nie ma parametrów BuildId , dodaj -Wl,--build-id do flag swojego systemu kompilacji.

  • Sprawdź, czy nie usuwasz niechcący identyfikatorów BuildId w celu zmniejszenia rozmiaru pliku APK.

  • Jeśli przechowujesz pozbawione i pozbawione ograniczeń wersje biblioteki, pamiętaj o wskazaniu prawidłowej wersji w kodzie.

Różnice między raportami ANR w panelu Crashlytics i Konsoli Google Play

Może występować rozbieżność między liczbą błędów ANR między Google Play i Crashlytics. Jest to oczekiwane ze względu na różnicę w mechanizmie gromadzenia i raportowania danych ANR. Crashlytics zgłasza błędy ANR przy następnym uruchomieniu aplikacji, natomiast Android Vitals wysyła dane ANR po ich wystąpieniu.

Ponadto Crashlytics wyświetla tylko błędy ANR występujące na urządzeniach z systemem Android 11 lub nowszym, w porównaniu do Google Play, które wyświetla błędy ANR z urządzeń z usługami Google Play i zaakceptowaną zgodą na gromadzenie danych.

Różnice między śladami stosu NDK w panelu kontrolnym Crashlytics i logcat

Łańcuchy narzędzi LLVM i GNU mają różne ustawienia domyślne i sposoby traktowania segmentu plików binarnych aplikacji tylko do odczytu, co może generować niespójne ślady stosu w konsoli Firebase. Aby temu zaradzić, dodaj następujące flagi linkera do procesu kompilacji:

• Jeśli używasz linkera lld z zestawu narzędzi LLVM, dodaj:

  -Wl,--no-rosegment
  

• Jeśli używasz linkera ld.gold z zestawu narzędzi GNU, dodaj:

  -Wl,--rosegment
  

Jeśli nadal widzisz niespójności w śledzeniu stosu (lub jeśli żadna flaga nie dotyczy Twojego łańcucha narzędzi), spróbuj zamiast tego dodać do procesu kompilacji następujące elementy:

-fno-omit-frame-pointer

Jak używać 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 (na przykład, jeśli wolisz budować wszystkie natywne pliki wykonywalne w łańcuchu kompilacji ze źródła), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary , aby określić ścieżkę do pliku wykonywalnego.

Możesz określić ścieżkę do pliku binarnego generatora plików symboli Breakpad na jeden z dwóch sposobów:

• Opcja 1 : Określ ścieżkę za pomocą rozszerzenia firebaseCrashlytics w pliku build.gradle

  Dodaj następujące elementy do pliku build.gradle na poziomie aplikacji:

  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ę poprzez linię właściwości w pliku właściwości Gradle

  Możesz użyć właściwości com.google.firebase.crashlytics.symbolGeneratorBinary , 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ń. Na przykład, aby określić ścieżkę za pomocą wiersza poleceń, użyj polecenia podobnego do poniższego:

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

Brak awarii z Dexguardem

Jeśli widzisz następujący wyjątek, prawdopodobnie używasz wersji DexGuard, która jest niezgodna 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 raportów o awariach. Aby to naprawić:

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, spróbuj dodać następujący wiersz do reguł zaciemniania (w pliku konfiguracyjnym DexGuard):

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

Dlaczego widzę awarie plików .kt oznaczonych jako problemy .java ?

Gdy aplikacja korzysta z narzędzia zaciemniającego, które nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java .

Aby Crashlytics mógł generować problemy z prawidłowym rozszerzeniem pliku, upewnij się, że Twoja aplikacja korzysta z następującej konfiguracji:

• Używa Androida Gradle 4.2.0 lub nowszego
• Używa R8 z włączoną funkcją zaciemniania. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją .

Pamiętaj, że po aktualizacji do konfiguracji opisanej powyżej mogą zacząć pojawiać się nowe problemy .kt , które są duplikatami istniejących problemów z .java . Zobacz często zadawane pytania , aby dowiedzieć się więcej na temat tej okoliczności.

Dlaczego widzę problemy .kt , które są duplikatami istniejących problemów .java ?

Od połowy grudnia 2021 r. Crashlytics poprawiło obsługę aplikacji korzystających z Kotlina.

Do niedawna dostępne zaciemniacze nie ujawniały rozszerzenia pliku, dlatego Crashlytics generował każdy problem domyślnie 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 każda klasa używana w aplikacji jest napisana w języku Kotlin i uwzględnić poprawną nazwę pliku w sygnaturze problemu. Awarie są teraz poprawnie przypisywane plikom .kt (w zależności od przypadku), jeśli Twoja aplikacja ma następującą konfigurację:

• Twoja aplikacja korzysta z systemu Android Gradle 4.2.0 lub nowszego.
• Twoja aplikacja korzysta z R8 z włączonym zaciemnianiem.

Ponieważ nowe awarie zawierają teraz prawidłowe rozszerzenie pliku w sygnaturach problemów, mogą pojawić się nowe problemy z .kt , które w rzeczywistości są po prostu duplikatami istniejących problemów z etykietą .java . W konsoli Firebase staramy się zidentyfikować i powiadomić Cię, jeśli nowy problem .kt jest możliwym duplikatem istniejącego problemu z etykietą .java .

Jak obliczana jest liczba użytkowników bez awarii?

Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale nie doświadczyli awarii w określonym przedziale czasu.

Oto wzór na obliczenie procentu użytkowników bez awarii. Jego wartości wejściowe są dostarczane przez Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• W przypadku awarii Google Analytics wysyła typ zdarzenia app_exception , a CRASHED_USERS reprezentuje liczbę użytkowników powiązanych z tym typem zdarzenia.

• ALL_USERS reprezentuje łączną liczbę użytkowników, którzy weszli w interakcję z Twoją aplikacją w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.

Odsetek użytkowników bez awarii jest sumą w czasie , a nie średnią.

Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy korzystali z Twojej aplikacji każdego dnia i który z nich miał tego dnia awarię:

• W środę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie miał żadnych awarii).
  Dwóch użytkowników skorzystało z Twojej aplikacji w środę, ale tylko u jednego z nich (Użytkownik B) nie wystąpiła żadna awaria.

• W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników nie miał żadnych awarii).
  Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko u jednego z nich (Użytkownik C) nie wystąpiła żadna awaria.

• W ciągu ostatnich 3 dni odsetek użytkowników bez awarii wynosił 0% (0 z 3 użytkowników nie miało żadnych awarii).
  Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiła żadna awaria.

Wartości użytkowników bez awarii nie należy porównywać w różnych okresach czasu. Prawdopodobieństwo, że pojedynczy użytkownik doświadczy awarii, rośnie im częściej korzysta z aplikacji, więc wartość użytkowników bez awarii będzie prawdopodobnie mniejsza w dłuższych okresach.

Kto może przeglądać, pisać i usuwać notatki dotyczące problemu?

Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.

Kiedy członek projektu publikuje notatkę, jest ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich członków projektu mających dostęp do przeglądania notatki.

Poniżej opisano dostęp wymagany do przeglądania, pisania i usuwania notatek:

• Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.

  • Właściciel lub redaktor projektu, administrator Firebase , administrator jakości lub administrator Crashlytics

• Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie problemu, ale nie mogą usuwać ani pisać notatek.

  • Przeglądarka projektu, Przeglądarka Firebase , Przeglądarka jakości lub Przeglądarka Crashlytics

Aplikacja korzysta również z pakietu SDK do reklam mobilnych Google, ale nie powoduje awarii

Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobne jest, że osoby zgłaszające awarie zakłócają rejestrację programów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie o awariach w pakiecie SDK do reklam mobilnych, wywołując disableSDKCrashReporting .

Gdzie znajduje się mój zbiór danych BigQuery?

Po połączeniu Crashlytics z BigQuery nowe utworzone przez Ciebie zbiory danych będą automatycznie lokalizowane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.

Czy Crashlytics obsługuje armeabi?

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

Co to jest regresja problemu?

Problem uległ regresji, gdy został już wcześniej zamknięty, ale Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu. Crashlytics automatycznie ponownie otwiera te problemy, które uległy regresji, dzięki czemu możesz je rozwiązać odpowiednio do swojej aplikacji.

Oto przykładowy scenariusz wyjaśniający, jak Crashlytics kategoryzuje problem jako regresję:

1. Po raz pierwszy w historii Crashlytics otrzymuje raport o awarii dotyczącej awarii „A”. Crashlytics otwiera odpowiedni problem dla tej awarii (problem „A”).
2. Szybko naprawisz ten błąd, zamkniesz wydanie „A”, a następnie wypuścisz nową wersję swojej aplikacji.
3. Crashlytics otrzymuje kolejny raport na temat problemu „A” po jego zamknięciu.
   • Jeśli raport dotyczy wersji aplikacji, o której Crashlytics wiedziała w chwili zamykania problemu (co oznacza, że ​​ta wersja wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna, że ​​problem uległ regresji. Temat pozostanie zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedziała w chwili zamykania problemu (co oznacza, że ​​ta wersja nigdy nie wysłała żadnego raportu o awarii w przypadku żadnej awarii), Crashlytics uzna, że ​​problem ustąpił i ponownie go otworzy .

Gdy problem się cofa, wysyłamy alert o wykryciu regresji i dodajemy sygnał regresji do problemu, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.

Dlaczego w przypadku starszych wersji aplikacji widzę, że problemy uległy regresji?

Jeśli raport pochodzi ze starej wersji aplikacji, która po zamknięciu problemu nie wysyłała żadnych raportów o awariach, Crashlytics uzna, że ​​problem uległ regresji i ponownie go otworzy.

Taka sytuacja może mieć miejsce w następującej sytuacji: Naprawiłeś błąd i wydałeś nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki błędu. Jeśli przez przypadek jedna ze starszych wersji nigdy nie wysłała żadnych raportów o awariach po zamknięciu problemu, a ci użytkownicy zaczną napotykać błąd, wówczas te raporty o awariach spowodują regresję problemu.

Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.

Nie widzę użytkowników bez awarii, dzienników nawigacyjnych i/lub alertów dotyczących prędkości

Jeśli nie widzisz użytkowników bez awarii, dzienników nawigacji i/lub alertów dotyczących prędkości, zalecamy sprawdzenie konfiguracji aplikacji pod kątem Google Analytics.

• Upewnij się, że w swoim projekcie Firebase włączyłeś Google Analytics .

• Upewnij się, że Udostępnianie danych dla Google Analytics jest włączone na stronie Integracje > Google Analytics w konsoli Firebase. Pamiętaj, że ustawienia udostępniania danych są wyświetlane w konsoli Firebase, ale zarządza się nimi w konsoli Google Analytics.

• Oprócz pakietu SDK Firebase Crashlytics upewnij się, że do swojej aplikacji dodałeś pakiet SDK Firebase dla Google Analytics ( iOS+ | Android ).

• Upewnij się, że używasz najnowszych wersji wszystkich zestawów SDK Firebase ( iOS+ | Android ).
  W szczególności sprawdź, czy używasz co najmniej następujących wersji pakietu SDK Firebase dla Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ dla macOS i tvOS) | Android — v17.2.3+ (BoM v24.7.1+) .

Wyświetlanie różnych formatów (a czasem „wariantów”) niektórych problemów w tabeli Problemy

Możesz zauważyć dwa różne formaty problemów wymienionych w tabeli Problemy w konsoli Firebase. W niektórych problemach możesz także zauważyć funkcję zwaną „wariantami”. Dlatego!

Na początku 2023 r. wprowadziliśmy ulepszony silnik analityczny do grupowania wydarzeń, a także zaktualizowany projekt i kilka zaawansowanych funkcji dla nowych problemów (takich jak warianty!). Wszystkie szczegóły znajdziesz w naszym najnowszym poście na blogu , ale najważniejsze informacje znajdziesz poniżej.

Crashlytics analizuje wszystkie zdarzenia z Twojej aplikacji (takie jak awarie, zdarzenia inne niż krytyczne i błędy ANR) i tworzy grupy zdarzeń zwane problemami — wszystkie zdarzenia w problemie mają wspólny punkt awarii.

Aby pogrupować zdarzenia w te problemy, ulepszony silnik analizy analizuje obecnie wiele aspektów zdarzenia, w tym ramki w śladzie stosu, komunikat wyjątku, kod błędu i inne cechy platformy lub typu błędu.

Jednak w obrębie tej grupy zdarzeń ślady stosu prowadzące do awarii mogą być inne. Inny ślad stosu może oznaczać inną przyczynę podstawową. Aby przedstawić tę możliwą różnicę w obrębie problemu, tworzymy teraz warianty w obrębie problemów — każdy wariant jest podgrupą zdarzeń w problemie, które mają ten sam punkt awarii i podobny ślad stosu. Dzięki wariantom możesz debugować najczęstsze ślady stosu w obrębie problemu i określić, czy do niepowodzenia prowadzą różne przyczyny główne.

Oto, czego doświadczysz dzięki tym ulepszeniom:

• Zmienione metadane wyświetlane w wierszu problemu
  Teraz łatwiej jest zrozumieć i ocenić problemy w aplikacji.

• Mniej duplikatów problemów
  Zmiana numeru linii nie powoduje nowego problemu.

• Łatwiejsze debugowanie złożonych problemów z różnymi przyczynami źródłowymi
  Użyj wariantów, aby debugować najczęstsze ślady stosu w ramach problemu.

• Bardziej znaczące alerty i sygnały
  Nowy problem w rzeczywistości oznacza nowy błąd.

• Mocniejsze wyszukiwanie
  Każde wydanie zawiera więcej metadanych, które można przeszukiwać, takich jak typ wyjątku i nazwa pakietu.

Oto jak wdrażane są te ulepszenia:

• Gdy otrzymamy nowe zdarzenia z Twojej aplikacji, sprawdzimy, czy pasują one do istniejącego problemu.

• Jeśli nie ma dopasowania, automatycznie zastosujemy do zdarzenia nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.

To pierwsza duża aktualizacja, którą wprowadzamy w naszym grupowaniu wydarzeń. Jeśli masz uwagi lub napotkasz jakiekolwiek problemy, daj nam znać, przesyłając raport.

Dlaczego błędy ANR są zgłaszane tylko w przypadku Androida 11 lub nowszego?

Crashlytics obsługuje raportowanie ANR dla aplikacji na Androida z urządzeń z Androidem 11 i nowszym. Podstawowy interfejs API, którego używamy do zbierania błędów ANR ( getHistoricalProcessExitReasons ) jest bardziej niezawodny niż podejścia oparte na SIGQUIT lub watchdogu. Ten interfejs API jest dostępny tylko na urządzeniach z Androidem 11 lub nowszym.

Dlaczego w niektórych komunikatach ANR brakuje identyfikatorów BuildId ?

Jeśli w niektórych komunikatach ANR brakuje identyfikatorów BuildId , rozwiąż problem w następujący sposób:

• Upewnij się, że używasz aktualnej wersji pakietu Crashlytics Android SDK i wtyczki Crashlytics Gradle.

  Jeśli brakuje BuildId dla Androida 11 i niektórych błędów ANR dla Androida 12, prawdopodobnie używasz nieaktualnego pakietu SDK, wtyczki Gradle lub obu. Aby poprawnie zbierać BuildId dla tych błędów ANR, musisz użyć następujących wersji:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Wtyczka Crashlytics Gradle v2.9.4+

• Sprawdź, czy używasz niestandardowej lokalizacji dla swoich bibliotek współdzielonych.

  Jeśli brakuje tylko identyfikatorów BuildId dla bibliotek współdzielonych aplikacji, prawdopodobnie nie używasz standardowej, domyślnej lokalizacji bibliotek współdzielonych. W takim przypadku Crashlytics może nie być w stanie zlokalizować powiązanych identyfikatorów BuildId . Zalecamy rozważenie użycia standardowej lokalizacji bibliotek współdzielonych.

• Upewnij się, że nie usuwasz BuildId s podczas procesu kompilacji.

  Pamiętaj, że poniższe wskazówki dotyczące rozwiązywania problemów dotyczą zarówno błędów ANR, jak i awarii natywnych.

  • Sprawdź, czy BuildId s istnieje, uruchamiając readelf -n w swoich plikach binarnych. Jeśli nie ma parametrów BuildId , dodaj -Wl,--build-id do flag swojego systemu kompilacji.

  • Sprawdź, czy nie usuwasz niechcący identyfikatorów BuildId w celu zmniejszenia rozmiaru pliku APK.

  • Jeśli przechowujesz pozbawione i pozbawione ograniczeń wersje biblioteki, pamiętaj o wskazaniu prawidłowej wersji w kodzie.

Różnice między raportami ANR w panelu Crashlytics i Konsoli Google Play

Może występować rozbieżność między liczbą błędów ANR między Google Play i Crashlytics. Jest to oczekiwane ze względu na różnicę w mechanizmie gromadzenia i raportowania danych ANR. Crashlytics zgłasza błędy ANR przy następnym uruchomieniu aplikacji, natomiast Android Vitals wysyła dane ANR po ich wystąpieniu.

Ponadto Crashlytics wyświetla tylko błędy ANR występujące na urządzeniach z systemem Android 11 lub nowszym, w porównaniu do Google Play, które wyświetla błędy ANR z urządzeń z usługami Google Play i zaakceptowaną zgodą na gromadzenie danych.

Różnice między śladami stosu NDK w panelu kontrolnym Crashlytics i logcat

Łańcuchy narzędzi LLVM i GNU mają różne ustawienia domyślne i sposoby traktowania segmentu plików binarnych aplikacji tylko do odczytu, co może generować niespójne ślady stosu w konsoli Firebase. Aby temu zaradzić, dodaj następujące flagi linkera do procesu kompilacji:

• Jeśli używasz linkera lld z zestawu narzędzi LLVM, dodaj:

  -Wl,--no-rosegment
  

• Jeśli używasz linkera ld.gold z zestawu narzędzi GNU, dodaj:

  -Wl,--rosegment
  

Jeśli nadal widzisz niespójności w śledzeniu stosu (lub jeśli żadna flaga nie dotyczy Twojego łańcucha narzędzi), spróbuj zamiast tego dodać do procesu kompilacji następujące elementy:

-fno-omit-frame-pointer

Jak używać 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 (na przykład, jeśli wolisz budować wszystkie natywne pliki wykonywalne w łańcuchu kompilacji ze źródła), użyj opcjonalnej właściwości rozszerzenia symbolGeneratorBinary , aby określić ścieżkę do pliku wykonywalnego.

Możesz określić ścieżkę do pliku binarnego generatora plików symboli Breakpad na jeden z dwóch sposobów:

• Opcja 1 : Określ ścieżkę za pomocą rozszerzenia firebaseCrashlytics w pliku build.gradle

  Dodaj następujące elementy do pliku build.gradle na poziomie aplikacji:

  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ę poprzez linię właściwości w pliku właściwości Gradle

  Możesz użyć właściwości com.google.firebase.crashlytics.symbolGeneratorBinary , 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ń. Na przykład, aby określić ścieżkę za pomocą wiersza poleceń, użyj polecenia podobnego do poniższego:

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

Brak awarii z Dexguardem

Jeśli widzisz następujący wyjątek, prawdopodobnie używasz wersji DexGuard, która jest niezgodna 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 raportów o awariach. Aby to naprawić:

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, spróbuj dodać następujący wiersz do reguł zaciemniania (w pliku konfiguracyjnym DexGuard):

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

Dlaczego widzę awarie plików .kt oznaczonych jako problemy .java ?

Gdy aplikacja korzysta z narzędzia zaciemniającego, które nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem pliku .java .

Aby Crashlytics mógł generować problemy z prawidłowym rozszerzeniem pliku, upewnij się, że Twoja aplikacja korzysta z następującej konfiguracji:

• Używa Androida Gradle 4.2.0 lub nowszego
• Używa R8 z włączoną funkcją zaciemniania. Aby zaktualizować aplikację do wersji R8, postępuj zgodnie z tą dokumentacją .

Pamiętaj, że po aktualizacji do konfiguracji opisanej powyżej mogą zacząć pojawiać się nowe problemy .kt , które są duplikatami istniejących problemów z .java . Zobacz często zadawane pytania , aby dowiedzieć się więcej na temat tej okoliczności.

Dlaczego widzę problemy .kt , które są duplikatami istniejących problemów .java ?

Od połowy grudnia 2021 r. Crashlytics poprawiło obsługę aplikacji korzystających z Kotlina.

Do niedawna dostępne zaciemniacze nie ujawniały rozszerzenia pliku, dlatego Crashlytics generował każdy problem domyślnie 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 każda klasa używana w aplikacji jest napisana w języku Kotlin i uwzględnić poprawną nazwę pliku w sygnaturze problemu. Awarie są teraz poprawnie przypisywane plikom .kt (w zależności od przypadku), jeśli Twoja aplikacja ma następującą konfigurację:

• Twoja aplikacja korzysta z systemu Android Gradle 4.2.0 lub nowszego.
• Twoja aplikacja korzysta z R8 z włączonym zaciemnianiem.

Ponieważ nowe awarie zawierają teraz prawidłowe rozszerzenie pliku w sygnaturach problemów, mogą pojawić się nowe problemy .kt , które w rzeczywistości są po prostu duplikatami istniejących problemów z etykietą .java . W konsoli Firebase staramy się zidentyfikować i powiadomić Cię, jeśli nowy problem .kt jest możliwym duplikatem istniejącego problemu z etykietą .java .

Jak obliczana jest liczba użytkowników bez awarii?

Wartość bez awarii reprezentuje odsetek użytkowników, którzy weszli w interakcję z Twoją aplikacją, ale nie doświadczyli awarii w określonym przedziale czasu.

Oto wzór na obliczenie procentu użytkowników bez awarii. Jego wartości wejściowe są dostarczane przez Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• W przypadku awarii Google Analytics wysyła typ zdarzenia app_exception , a CRASHED_USERS reprezentuje liczbę użytkowników powiązanych z tym typem zdarzenia.

• ALL_USERS reprezentuje łączną liczbę użytkowników, którzy weszli w interakcję z Twoją aplikacją w okresie wybranym z menu rozwijanego w prawym górnym rogu panelu Crashlytics.

Odsetek użytkowników bez awarii jest sumą w czasie , a nie średnią.

Załóżmy na przykład, że Twoja aplikacja ma trzech użytkowników; nazwiemy ich Użytkownikiem A, Użytkownikiem B i Użytkownikiem C. Poniższa tabela pokazuje, którzy użytkownicy korzystali z Twojej aplikacji każdego dnia i który z nich miał tego dnia awarię:

• W środę odsetek użytkowników bez awarii wynosi 50% (1 na 2 użytkowników nie miał żadnych awarii).
  Dwóch użytkowników skorzystało z Twojej aplikacji w środę, ale tylko u jednego z nich (Użytkownik B) nie wystąpiła żadna awaria.

• W ciągu ostatnich 2 dni odsetek użytkowników bez awarii wynosił 33,3% (1 na 3 użytkowników nie miał żadnych awarii).
  Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich dwóch dni, ale tylko u jednego z nich (Użytkownik C) nie wystąpiła żadna awaria.

• W ciągu ostatnich 3 dni odsetek użytkowników bez awarii wynosił 0% (0 z 3 użytkowników nie miało żadnych awarii).
  Trzech użytkowników skorzystało z Twojej aplikacji w ciągu ostatnich trzech dni, ale u żadnego z nich nie wystąpiła żadna awaria.

Wartości użytkowników bez awarii nie należy porównywać w różnych okresach czasu. Prawdopodobieństwo, że pojedynczy użytkownik doświadczy awarii, rośnie im częściej korzysta z aplikacji, więc wartość użytkowników bez awarii będzie prawdopodobnie mniejsza w dłuższych okresach.

Kto może przeglądać, pisać i usuwać notatki dotyczące problemu?

Notatki umożliwiają członkom projektu komentowanie konkretnych problemów za pomocą pytań, aktualizacji statusu itp.

Kiedy członek projektu publikuje notatkę, jest ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail jest widoczny wraz z notatką dla wszystkich członków projektu mających dostęp do przeglądania notatki.

Poniżej opisano dostęp wymagany do przeglądania, pisania i usuwania notatek:

• Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać i usuwać istniejące notatki oraz pisać nowe notatki na temat problemu.

  • Właściciel lub redaktor projektu, administrator Firebase , administrator jakości lub administrator Crashlytics

• Członkowie projektu pełniący dowolną z poniższych ról mogą przeglądać notatki opublikowane w sprawie problemu, ale nie mogą usuwać ani pisać notatek.

  • Przeglądarka projektu, Przeglądarka Firebase , Przeglądarka jakości lub Przeglądarka Crashlytics

Aplikacja korzysta również z pakietu SDK do reklam mobilnych Google, ale nie powoduje awarii

Jeśli Twój projekt korzysta z Crashlytics razem z pakietem SDK do reklam mobilnych Google, prawdopodobne jest, że osoby zgłaszające awarie zakłócają rejestrację programów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie o awariach w pakiecie SDK do reklam mobilnych, wywołując disableSDKCrashReporting .

Gdzie znajduje się mój zbiór danych BigQuery?

Po połączeniu Crashlytics z BigQuery nowe utworzone przez Ciebie zbiory danych będą automatycznie lokalizowane w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.

Czy Crashlytics obsługuje armeabi?

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

Co to jest regresja problemu?

Problem uległ regresji, gdy został już wcześniej zamknięty, ale Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu. Crashlytics automatycznie ponownie otwiera te problemy, które uległy regresji, dzięki czemu możesz je rozwiązać odpowiednio do swojej aplikacji.

Oto przykładowy scenariusz wyjaśniający, jak Crashlytics kategoryzuje problem jako regresję:

1. Po raz pierwszy w historii Crashlytics otrzymuje raport o awarii dotyczącej awarii „A”. Crashlytics otwiera odpowiedni problem dla tej awarii (problem „A”).
2. Szybko naprawisz ten błąd, zamkniesz wydanie „A”, a następnie wypuścisz nową wersję swojej aplikacji.
3. Crashlytics otrzymuje kolejny raport na temat problemu „A” po jego zamknięciu.
   • Jeśli raport dotyczy wersji aplikacji, o której Crashlytics wiedziała w chwili zamykania problemu (co oznacza, że ​​ta wersja wysłała raport o awarii w przypadku jakiejkolwiek awarii), Crashlytics nie uzna, że ​​problem uległ regresji. Temat pozostanie zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, o której Crashlytics nie wiedziała w chwili zamykania problemu (co oznacza, że ​​ta wersja nigdy nie wysłała żadnego raportu o awarii w przypadku żadnej awarii), Crashlytics uzna, że ​​problem ustąpił i ponownie go otworzy .

Gdy problem się cofa, wysyłamy alert o wykryciu regresji i dodajemy sygnał regresji do problemu, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.

Dlaczego w przypadku starszych wersji aplikacji widzę, że problemy uległy regresji?

Jeśli raport pochodzi ze starej wersji aplikacji, która po zamknięciu problemu nie wysyłała żadnych raportów o awariach, Crashlytics uzna, że ​​problem uległ regresji i ponownie go otworzy.

Taka sytuacja może mieć miejsce w następującej sytuacji: Naprawiłeś błąd i wydałeś nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki błędu. Jeśli przez przypadek jedna ze starszych wersji nigdy nie wysłała żadnych raportów o awariach po zamknięciu problemu, a ci użytkownicy zaczną napotykać błąd, wówczas te raporty o awariach spowodują regresję problemu.

Jeśli nie chcesz, aby problem został ponownie otwarty ze względu na nasz algorytm regresji, „wycisz” problem, zamiast go zamykać.