Rozwiązywanie problemów z Crashlytics i najczęstsze pytania

bookmark_border Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W konsoli Firebase możesz zauważyć 2 różne formaty problemów wymienionych w tabeli Problemy. W niektórych problemach możesz też zauważyć funkcję „warianty”. Oto dlaczego.

Na początku 2023 r. wprowadziliśmy ulepszony mechanizm analizy do grupowania zdarzeń, a także zaktualizowaliśmy interfejs i dodaliśmy kilka zaawansowanych funkcji do obsługi nowych problemów (np. wariantów). Więcej informacji znajdziesz w naszym najnowszym poście na blogu. Najważniejsze informacje znajdziesz poniżej.

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 grupować zdarzenia według tych problemów, ulepszony mechanizm analizy uwzględnia wiele aspektów zdarzenia, w tym ramki w wyświetleniu stosu, komunikat o wyjątkach, kod błędu i inne cechy platformy lub typu błędu.

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ą główną przyczynę. Aby uwzględnić tę możliwą różnicę w problemie, tworzymy teraz warianty w problemach. Każdy wariant to podgrupa zdarzeń w problemie, która ma ten sam punkt awarii i podobny ślad 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:

• Zaktualizowane metadane wyświetlane w wierszu problemu
  Zrozumienie i rozwiązywanie problemów w aplikacji jest teraz łatwiejsze.

• Mniej problemów z duplikatami
  Zmiana numeru linii nie powoduje powstania nowego problemu.

• Łatwiejsze debugowanie skomplikowanych problemów o różnych przyczynach
  Używaj wariantów do debugowania najczęstszych ścieżek wywołań w ramach 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ć, takich jak typ wyjątku i nazwa pakietu.

Oto, jak wprowadzamy te ulepszenia:

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

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

To pierwsza duża zmiana, jaką wprowadzamy w grupowaniu wydarzeń. Jeśli chcesz podzielić się opinią lub napotkasz problem, prześlij raport .

Jeśli nie widzisz dzienników ścieżek, sprawdź konfigurację aplikacji pod kątem Google Analytics. Upewnij się, że spełniasz te wymagania:

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

• W usłudze Google Analytics zostało włączone Udostępnianie danych. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych w Analytics.

• Do aplikacji dodano pakiet SDK Firebase dla Google Analytics dodanego do aplikacji. Ten pakiet SDK musi zostać dodany oprócz pakietu SDK Crashlytics.

• Używasz najnowszych wersji pakietu SDK Firebase wszystkich usług używanych w aplikacji.

  Zwłaszcza sprawdź, czy używasz co najmniej tej wersji pakietu SDK Firebase w Google Analytics:
  Android – w wersji 17.2.3 lub nowszej (BoM w wersji 24.7.1 lub nowszej).

Jeśli nie widzisz 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),

Jeśli nie widzisz danych o bezawaryjnej pracy (np. o użytkownikach i sesjach bez awarii) lub widzisz dane niewiarygodne, sprawdź te kwestie:

• Upewnij się, że używasz: pakietu SDK Crashlytics w wersji 18.6.0 lub nowszej (lub Firebase BoM w wersji 32.6.0 lub nowszej),

• Upewnij się, że ustawienia gromadzenia danych nie wpływają na jakość danych dotyczących braku awarii:

  • Jeśli włączysz raportowanie po wyrażeniu zgody, wyłączając automatyczne raportowanie awarii, informacje o awariach będą mogły być wysyłane do Crashlytics tylko od użytkowników, którzy wyraźnie wyrazili zgodę na zbieranie danych. W związku z tym dokładność danych dotyczących liczby sesji bez awarii może być zaniżona, ponieważ Crashlytics ma informacje o awariach tylko od tych użytkowników, którzy wyrazili zgodę (a nie od wszystkich użytkowników). Oznacza to, że dane o czasie bez awarii mogą być mniej wiarygodne i mniej odzwierciedlać ogólną stabilność aplikacji.

  • Jeśli masz wyłączone automatyczne zbieranie danych, możesz użyć polecenia sendUnsentReports, aby wysłać raporty z pamięci podręcznej na urządzeniu do Crashlytics. W przypadku tej metody do usługi Crashlytics zostaną wysłane dane o awariach, ale nie dane o sesjach. Spowoduje to, że wykresy w konsoli będą wyświetlać niskie lub zerowe wartości wskaźników dotyczących liczby sesji bez awarii.

Zobacz dane o bezpiecznych aplikacjach.

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

Jeśli niektóre z Twoich plików ANR nie zawierają BuildId, wykonaj te czynności:

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

  Jeśli brakuje Ci BuildId na Androidzie 11 i niektórych ANR na Androidzie 12, prawdopodobnie używasz przestarzałego pakietu SDK lub wtyczki Gradle albo obu tych elementów. Aby prawidłowo zbierać BuildId w przypadku tych ANR, musisz używać tych wersji:

  • 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 używasz niestandardowej lokalizacji dla zasobów wspólnych.

  Jeśli brakuje tylko BuildId w przypadku bibliotek udostępnionych aplikacji, prawdopodobnie nie używasz standardowego domyślnego miejsca na biblioteki udostępnione. W takim przypadku Crashlytics może nie być w stanie znaleźć powiązanych BuildId. Zalecamy używanie standardowej lokalizacji dla współdzielonych bibliotek.

• Sprawdź, czy podczas procesu kompilacji nie usuwasz BuildId.

  Pamiętaj, że podane niżej wskazówki dotyczące rozwiązywania problemów dotyczą zarówno ANR, jak i wbudowanych awarii.

  • Sprawdź, czy pliki BuildId istnieją, uruchamiając readelf -n na plikach binarnych. Jeśli BuildId są nieobecne, dodaj -Wl,--build-id do flag systemu kompilacji.

  • Sprawdź, czy nie usuwasz nieumyślnie elementów BuildId, aby zmniejszyć rozmiar pliku APK.

  • Jeśli przechowujesz wersje z obciętymi i nieobciętymi bibliotekami, w kodzie musisz wskazać właściwą wersję.

Liczba powiadomień ANR może się różnić w Google Play i w Crashlytics. Jest to spowodowane różnicą w mechanizmie zbierania i raportowania danych ANR. Crashlytics raportuje błędy ANR, gdy aplikacja się uruchamia, a Android Vitals wysyła dane ANR po ich wystąpieniu.

Dodatkowo Crashlytics wyświetla tylko błędy ANR występujące na urządzeniach z Androidem 11 lub nowszym, podczas gdy Google Play wyświetla błędy ANR z urządzeń z usługami Google Play i zaakceptowanym zbieraniem danych.

Zestawy narzędzi LLVM i GNU mają różne wartości domyślne i metody obsługi segmentu binarów aplikacji tylko do odczytu, co może powodować niespójności w śladach stosu w konsoli Firebase. Aby temu zapobiec, dodaj do procesu kompilacji te flagi linkera:

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

  -Wl,--no-rosegment

• Jeśli używasz linkera ld.gold z pakietu 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

W pluginie Crashlytics jest zawarty 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 określić na 2 sposoby:

• Opcja 1. W pliku build.gradle podaj ścieżkę za pomocą rozszerzenia firebaseCrashlytics

  Dodaj do pliku build.gradle.kts na poziomie aplikacji:

  Wtyczka Gradle w wersji 3.0.0 lub nowszej starsze wersje wtyczek, Więcej
  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")
        }
      }
    }
  }

  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 określić ścieżkę do pliku wykonywalnego, użyj właściwości com.google.firebase.crashlytics.breakpadBinary.

  Plik właściwości Gradle możesz zaktualizować ręcznie lub za pomocą wiersza poleceń. Aby na przykład określić ścieżkę w wierszu poleceń, 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
  

Jeśli widzisz ten 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 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, spróbuj dodać ten wiersz do zasad zaciemniania (w pliku konfiguracyjnym DexGuard):

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

Jeśli aplikacja używa narzędzia do zaciemniania, które nie ujawnia rozszerzenia pliku, Crashlytics domyślnie generuje każdy problem z rozszerzeniem .java.

Aby Crashlytics mogła generować problemy z odpowiednią rozszerzeniem pliku, sprawdź, czy Twoja aplikacja używa tej konfiguracji:

• Używa 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. Aby dowiedzieć się więcej o tym, co należy zrobić w takich sytuacjach, zapoznaj się z najczęstszymi pytaniami.

Od połowy grudnia 2021 r. Crashlytics poprawiliśmy obsługę aplikacji korzystających z języka Kotlin.

Do niedawna dostępne narzędzia do zaciemniania nie ujawniały rozszerzenia pliku, więc problemy generowane przezCrashlytics miały domyślnie rozszerzenie .java. Jednak od wersji 4.2.0 wtyczki Androida do obsługi Gradle 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 Kotlinie, i uwzględnić poprawną nazwę pliku w signaturze problemu. Awarie są teraz poprawnie przypisywane do plików .kt (w odpowiednich przypadkach), jeśli aplikacja ma taką konfigurację:

• Twoja aplikacja korzysta z Android Gradle 4.2.0 lub nowszej wersji.
• Twoja aplikacja używa R8 z włączonym zaciemnieniem.

Ponieważ nowe błędy zawierają teraz prawidłowe rozszerzenie pliku w swoich sygnaturach, możesz zobaczyć nowe problemy .kt, które są w istocie duplikami istniejących problemów z oznaczeniem .java. W konsoli Firebase staramy się wykrywać i informować Cię, jeśli nowy problem .kt jest potencjalnym duplikatem istniejącego problemu z oznaczeniem .java.

Uwagi umożliwiają uczestnikom projektu komentowanie konkretnych problemów, zadawanie pytań, informowanie o aktualizacjach stanu itp.

Gdy członek zespołu projektu opublikuje notatkę, zostanie ona oznaczona adresem e-mail jego konta Google. Ten adres e-mail wraz z notatką jest widoczny dla wszystkich członków projektu, którzy mają uprawnienia do wyświetlania notatek.

Poniżej opisujemy uprawnienia wymagane do wyświetlania, zapisywania i usuwania notatek:

• 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.

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

• Członkowie projektu, którzy mają jedną z tych ról, mogą wyświetlać notatki opublikowane w ramach problemu, ale nie mogą ich usuwać ani pisać.

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

Jeśli Twój projekt korzysta z biblioteki Crashlytics obok pakietu SDK Google Mobile Ads, prawdopodobnie funkcje zgłaszania awarii zakłócają rejestrowanie modułów obsługi wyjątków. Aby rozwiązać ten problem, wyłącz raportowanie awarii w pakiecie SDK Mobile Ads, wywołując funkcję disableSDKCrashReporting.

Po połączeniu Crashlytics z BigQuery nowe tworzone przez Ciebie zbiory danych są automatycznie umieszczane w Stanach Zjednoczonych niezależnie od lokalizacji projektu Firebase.

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

Problem powrócił po tym, jak został zamknięty. Crashlytics otrzymuje nowe zgłoszenie, że problem wystąpił ponownie. 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ę:

1. Po raz pierwszy Crashlytics otrzymał raport o awarii „A”. Crashlytics otwiera odpowiedni problem dotyczący tego błędu (problem „A”).
2. Szybko naprawiasz ten błąd, zamykasz problem „A”, a potem publikujesz nową wersję aplikacji.
3. Crashlytics otrzymuje kolejny raport dotyczący problemu „A” po tym, jak został on zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, którą Crashlytics znał w momencie zamknięcia problemu (co oznacza, że wersja wysłała raport o dowolnym awarii), Crashlytics nie uzna problemu za rozwiązany. Problem pozostanie zamknięty.
   • Jeśli raport dotyczy wersji aplikacji, o której Crashlytics nie wiedział, że istnieje, w momencie zamykania problemu (co oznacza, że nigdy nie wysłano żadnego raportu o awarii), Crashlytics uzna, że problem został rozwiązany i ponownie otworzy zgłoszenie.

Gdy problem powróci do poprzedniego stanu, wyślemy alert o wykryciu regresji i dodamy do problemu sygnał regresji, aby poinformować Cię, że Crashlytics ponownie otworzył problem. Jeśli nie chcesz, aby problem został ponownie otwarty z powodu algorytmu regresji, zamiast go zamykać, „wycisz” go.

Jeśli raport pochodzi ze starej wersji aplikacji, która nigdy nie wysłała żadnych raportów o wypadkach, Crashlytics uzna, że problem się cofał, i ponownie otworzy zgłoszenie.

Może się to zdarzyć, gdy naprawisz błąd i opublikujesz nową wersję aplikacji, ale nadal masz użytkowników korzystających ze starszych wersji bez poprawki. Jeśli po zamknięciu problemu okazało się, że jedna z tych starszych wersji nigdy nie wysłała raportów o awariach, a użytkownicy zaczęli napotykać ten błąd, raporty o awariach spowodują, że problem wróci.

Jeśli nie chcesz, aby problem został ponownie otwarty z powodu naszego algorytmu regresji, zamiast zamykać problem, „wycisz go”.