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

wyświetlanie w tabeli Problemy różnych formatów (a czasami „wariantów”) niektórych problemów;

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ę 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 danego problemu mają wspólny punkt awarii.

Aby grupować 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.

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ą przyczynę problemu. Aby uwzględnić tę możliwą różnicę w problemie, tworzymy 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 z problemem
  Zrozumienie i rozwiązywanie problemów w aplikacji jest teraz łatwiejsze.

• Mniej zduplikowanych problemów
  Zmiana numeru wiersza nie powoduje pojawienia się nowego problemu.

• Łatwiejsze debugowanie skomplikowanych problemów z różnymi przyczynami
  Używaj wariantów do debugowania najczęstszych ścieżek wywołań w ramach problemu.

• Bardziej istotne alerty i sygnały
  Nowy problem oznacza nowy błąd.

• Bardziej zaawansowane wyszukiwanie
  Każdy problem zawiera więcej metadanych, które można wyszukiwać, na przykład typ wyjątku i nazwę 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 pasującego zdarzenia, automatycznie zastosujemy do niego nasz inteligentniejszy algorytm grupowania zdarzeń i utworzymy nowy problem z ulepszonym projektem metadanych.

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

Nie widzisz danych o bezawaryjnej pracy ani alertów dotyczących szybkości

Jeśli nie widzisz danych o użytkownikach i sesjach bez awarii ani alertów dotyczących szybkości, sprawdź, czy używasz

Nie widzę logów menu nawigacyjnego

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 masz włączone Udostępnianie danych. Więcej informacji o tym ustawieniu znajdziesz w artykule Zarządzanie ustawieniami udostępniania danych w Analytics.

• Do aplikacji do aplikacji. Ten pakiet SDK musi zostać dodany oprócz pakietu SDK Crashlytics.

• Używasz wszystkich usług używanych w aplikacji.

Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?

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.

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

Zapoznaj się z informacjami o danych dotyczących braku awarii.

Kto może wyświetlać, pisać i usuwać notatki dotyczące problemu?

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ą przypisaną dowolną z tych ról, mogą wyświetlać notatki opublikowane na temat problemu, ale nie mogą usuwać ani pisać.

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

Aplikacja korzysta też z pakietu SDK Google Mobile Ads, ale nie ma awarii

Jeśli Twój projekt używa interfejsu Crashlytics razem z pakietem SDK Google Mobile Ads, prawdopodobnie narzędzia do 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.

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

Po połączeniu usługi Crashlytics z BigQuery nowe zbiory danych, które utworzysz, zostaną automatycznie umieszczone w Stanach Zjednoczonych, niezależnie od lokalizacji Twojego projektu Firebase.

Co to jest problem z powrotem do stanu poprzedniego?

Występuje ponowna regresja, ponieważ wcześniej został przez Ciebie zamknięty wcześniej, ale usługa Crashlytics otrzymuje nowy raport o ponownym wystąpieniu problemu. 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 załamaniu), Crashlytics nie uzna problemu za rozwiązany. Problem pozostanie zamknięty.
   • Jeśli raport pochodzi z wersji aplikacji, o której użytkownik Crashlytics nie wiedział o czymś w momencie zamknięcia problemu (czyli że ta wersja nigdy nie wysyłała żadnego raportu o awarii), Crashlytics uznaje, że problem wrócił do poprzedniego, i otworzy go ponownie.