Dostosowywanie raportów o awariach Firebase Crashlytics


Na pulpicie Crashlytics możesz kliknąć problem, aby uzyskać szczegółowy raport o wydarzeniu. Możesz dostosowywać te raporty, aby lepiej rozumieć, co dzieje się w aplikacji, i jakie są okoliczności związane ze zgłoszonymi zdarzeniami w Crashlytics.

  • Automatycznie otrzymuj logi ścieżki, jeśli Twoja aplikacja korzysta z pakietu SDK Firebase w Google Analytics. Te logi zapewniają wgląd w działania użytkownika, które doprowadziły do zarejestrowania w Twojej aplikacji zdarzenia Crashlytics.

  • Wyłącz automatyczne raportowanie awarii i włącz raportowanie z wyrażeniem zgody dla użytkowników. Pamiętaj, że domyślnie Crashlytics automatycznie zbiera raporty o awariach dla wszystkich użytkowników aplikacji.

Dodawanie kluczy niestandardowych

Klucze niestandardowe pomagają uzyskać konkretny stan aplikacji, który doprowadził do awarii. Możesz powiązać z raportami o awariach dowolne pary klucz-wartość, a następnie używać niestandardowych kluczy do wyszukiwania i filtrowania raportów o awariach w konsoli Firebase.

  • W panelu Crashlytics możesz wyszukiwać problemy pasujące do klucza niestandardowego.

  • Podczas sprawdzania konkretnego problemu w konsoli możesz wyświetlić powiązane klucze niestandardowe dla każdego zdarzenia (podkarta Klucze) i nawet je filtrować według kluczy niestandardowych (menu Filtr u góry strony).

Aby ustawić pary klucz-wartość, użyj metody instancji setCustomKey. Pamiętaj, że parametr setCustomKey jest przeciążony w przypadku parametru value, aby akceptować dowolny argument typu prymitywnego lub String. Oto przykłady:

Kotlin

val crashlytics = Firebase.crashlytics
crashlytics.setCustomKeys {
    key("my_string_key", "foo") // String value
    key("my_bool_key", true) // boolean value
    key("my_double_key", 1.0) // double value
    key("my_float_key", 1.0f) // float value
    key("my_int_key", 1) // int value
}

Java

FirebaseCrashlytics crashlytics = FirebaseCrashlytics.getInstance();

crashlytics.setCustomKey("my_string_key", "foo" /* string value */);

crashlytics.setCustomKey("my_bool_key", true /* boolean value */);

crashlytics.setCustomKey("my_double_key", 1.0 /* double value */);

crashlytics.setCustomKey("my_float_key", 1.0f /* float value */);

crashlytics.setCustomKey("my_int_key", 1 /* int value */);

Możesz też zmodyfikować wartość istniejącego klucza, wywołując go i ustawiając inną wartość. Przykład:

Kotlin

val crashlytics = Firebase.crashlytics
crashlytics.setCustomKeys {
    key("current_level", 3)
    key("last_UI_action", "logged_in")
}

Java

FirebaseCrashlytics crashlytics = FirebaseCrashlytics.getInstance();

crashlytics.setCustomKey("current_level", 3);
crashlytics.setCustomKey("last_UI_action", "logged_in");

Dodawaj pary klucz-wartość zbiorczo, przekazując instancję CustomKeysAndValues do metody instancji setCustomKeys:

Kotlin

W przypadku Kotlina dotychczasowa funkcjonalność jest prostsza niż użycie narzędzia CustomKeysAndValues.

crashlytics.setCustomKeys {
  key("str_key", "hello")
  key("bool_key", true)
  key("int_key", 1)
  key("long_key", 1L)
  key("float_key", 1.0f)
  key("double_key", 1.0)
}

Java

CustomKeysAndValues keysAndValues = new CustomKeysAndValues.Builder()
.putString("string key", "string value")
.putString("string key 2", "string  value 2")
.putBoolean("boolean key", True)
.putBoolean("boolean key 2", False)
.putFloat("float key", 1.01)
.putFloat("float key 2", 2.02)
.build();

FirebaseCrashlytics.getInstance().setCustomKeys(keysAndValues);

Dodawanie niestandardowych komunikatów z dziennika

Aby uzyskać więcej informacji o zdarzeniach prowadzących do awarii, możesz dodać do aplikacji niestandardowe dzienniki Crashlytics. Crashlytics łączy dzienniki z danymi o awarii i wyświetla je na stronie Crashlyticskonsoli Firebase na karcie Dzienniki.

Aby określić problemy, użyj log. Przykład:

Kotlin

Firebase.crashlytics.log("message")

Java

FirebaseCrashlytics.getInstance().log("message");

Konfigurowanie identyfikatorów użytkowników

Aby zdiagnozować problem, warto wiedzieć, którzy użytkownicy doświadczyli danego błędu. Crashlytics umożliwia anonimowe identyfikowanie użytkowników w raportach o awariach.

Aby dodawać identyfikatory użytkowników do raportów, przypisz każdemu z nich unikalny identyfikator w postaci numeru identyfikacyjnego, tokena lub wartości zaszyfrowanej:

Kotlin

Firebase.crashlytics.setUserId("user123456789")

Java

FirebaseCrashlytics.getInstance().setUserId("user123456789");

Jeśli kiedykolwiek będziesz musiał(-a) usunąć identyfikator użytkownika po jego ustawieniu, zresetuj jego wartość na pusty ciąg znaków. Wyczyszczenie identyfikatora użytkownika nie powoduje usunięcia istniejących rekordów Crashlytics. Jeśli chcesz usunąć rekordy powiązane z identyfikatorem użytkownika, skontaktuj się z zespołem pomocy Firebase.

(dotyczy tylko NDK na Androida) Dodawanie metadanych do raportów o awariach w NDK

Opcjonalnie możesz dodać nagłówek crashlytics.h w kodzie C++, aby dodać metadane do raportów o awariach NDK, takie jak klucze niestandardowe, logi niestandardowe czy identyfikatory użytkowników. Wszystkie te opcje są opisane na tej stronie powyżej.

crashlytics.h jest dostępny jako biblioteka C++ tylko z nagłówkami w repozytorium GitHub pakietu SDK Firebase na Androida.

Więcej informacji o korzystaniu z interfejsów NDK C++ znajdziesz w komentarzach w pliku nagłówkowego.

Dołącz raporty GWP-ASan, aby debugować problemy z uszkodzoną pamięcią

Crashlytics może pomóc w debugowaniu awarii spowodowanych błędami pamięci natywnej poprzez zbieranie raportów GWP-ASan. Te błędy związane z pamięcią mogą być związane z uszkodzeniem pamięci w aplikacji, co jest główną przyczyną podatności na luki w zabezpieczeniach.

  • Te dane możesz wyświetlić na nowej karcie „Ślady sterty pamięci”, gdy klikniesz szczegóły problemu w panelu Crashlytics.

  • Możesz też użyć nowego sygnału i filtra „Raport GWP-ASan”, aby szybko wyświetlić wszystkie problemy z tymi danymi.

Raporty o pamięci z GWP-ASan możesz otrzymywać, jeśli w swojej aplikacji włączysz GWP-ASan i użyjesz pakietu Crashlytics SDK dla NDK w wersji 18.3.6 lub nowszej (Firebase BoM w wersji 31.3.0 lub nowszej). Konfigurację GWP-ASan możesz przetestować, korzystając z przykładowego kodu natywnego w dokumentacji na temat Androida.

Zgłaszanie błędów niekrytycznych

Oprócz automatycznego zgłaszania awarii aplikacji Crashlytics umożliwia rejestrowanie niekrytycznych wyjątków i wysyłanie ich do Ciebie przy następnym uruchomieniu aplikacji.

Używaj metody recordException, aby rejestrować niekrytyczne wyjątki w blokach catch aplikacji. Przykład:

Kotlin

try {
    methodThatThrows()
} catch (e: Exception) {
    Firebase.crashlytics.recordException(e)
    // handle your exception here
}

Java

try {
    methodThatThrows();
} catch (Exception e) {
    FirebaseCrashlytics.getInstance().recordException(e);
    // handle your exception here
}

Wszystkie zarejestrowane wyjątki są widoczne w konsoli Firebase jako błędy niekrytyczne. Podsumowanie problemu zawiera wszystkie informacje o stanie, które zwykle otrzymujesz z wypadków, wraz z podziałem według wersji Androida i urządzenia.

Crashlytics przetwarza wyjątki w wydzielonym wątku w tle, aby zminimalizować wpływ na wydajność aplikacji. Aby zmniejszyć ruch sieciowy użytkowników, Crashlytics grupowanie zarejestrowanych wyjątków i wysyłanie ich przy następnym uruchomieniu aplikacji.

Pobieranie dzienników menu nawigacyjnego

Dzięki logowanym ścieżkom możesz lepiej poznać interakcje użytkownika z aplikacją, które doprowadziły do awarii, niekrytycznego błędu lub zdarzenia ANR. Te logi mogą być przydatne podczas odtwarzania i debugowania problemu.

Logi ścieżki breadcrumbs są obsługiwane przez Google Analytics, więc aby je uzyskać, musisz włączyć Google Analytics w projekcie Firebase i dodać do aplikacji pakiet SDK Firebase dla Google Analytics. Gdy spełnisz te wymagania, ścieżki breadcrumbs będą automatycznie uwzględniane w danych zdarzenia na karcie Logi, gdy wyświetlisz szczegóły problemu.

Pakiet SDK Analytics automatycznie rejestruje zdarzenie screen_view, dzięki czemu logi ścieżki chleba umożliwiają wyświetlanie listy ekranów wyświetlonych przed zdarzeniem ANR, niekrytycznym błędem lub błędem krytycznym. Plik z logiem informacji o elementach nawigacyjnych screen_view zawiera parametr firebase_screen_class.

Dzienniki ścieżek zawierają też wszystkie zdarzenia niestandardowe, które ręcznie rejestrujesz w sesji użytkownika, w tym dane parametrów zdarzenia. Te dane mogą pomóc w określaniu sekwencji działań użytkownika, które doprowadziły do awarii, niekrytycznego błędu lub błędu ANR.

Pamiętaj, że możesz kontrolować zbieranie i używanie danych Google Analytics, w tym danych wypełniających logi ścieżek.

Włączanie raportowania zgodnego z wyrażeniem zgody

Domyślnie Crashlytics automatycznie zbiera raporty o awariach dla wszystkich użytkowników aplikacji. Aby zapewnić użytkownikom większą kontrolę nad przesyłanymi danymi, możesz włączyć raportowanie z wymaganiem zgody użytkownika, wyłączając raportowanie automatyczne i wysyłając dane do Crashlytics tylko wtedy, gdy zdecydujesz się na to w kodze:

  1. Aby wyłączyć automatyczne zbieranie danych, w bloku application pliku AndroidManifest.xml dodaj tag meta-data:

    <meta-data
        android:name="firebase_crashlytics_collection_enabled"
        android:value="false" />
    
  2. Włącz zbieranie danych w przypadku wybranych użytkowników, wywołując podczas działania funkcji override danych Crashlytics. Wartość zastąpienia jest zachowywana przy każdym uruchomieniu aplikacji, dzięki czemu Crashlytics może automatycznie zbierać raporty. Aby zrezygnować z automatycznego zgłaszania awarii, prześlij wartość false jako wartość zastępczą. Gdy ustawisz wartość false, nowa wartość zostanie zastosowana dopiero przy następnym uruchomieniu aplikacji.

    Kotlin

    Firebase.crashlytics.setCrashlyticsCollectionEnabled(true)

    Java

    FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true);

Zarządzanie danymi z analizy awarii

Analiza awarii pomaga rozwiązywać problemy przez porównywanie anonimowych zrzutów stosu z zrzutami z innych aplikacji Firebase i informowanie, czy Twój problem jest częścią większego trendu. W przypadku wielu problemów statystyki awarii udostępniają nawet zasoby, które pomogą Ci w debugowaniu awarii.

Raport Crash Insights korzysta z zagregowanych danych o wypadkach, aby identyfikować wspólne trendy dotyczące stabilności. Jeśli nie chcesz udostępniać danych aplikacji, możesz zrezygnować ze statystyk awarii w menu Statystyki awarii u góry listy Crashlytics problemów w konsoli Firebase.