Awarie usługi App Center (Unity)

Usługa App Center Crashes automatycznie generuje dzienniki awarii za każdym razem, gdy aplikacja się zawiesza, zapisując dziennik w pamięci urządzenia. Gdy użytkownik ponownie uruchomi aplikację, zestaw SDK wyśle raport o awarii do Centrum aplikacji. Zbieranie awarii działa zarówno w przypadku aplikacji beta, jak i na żywo, czyli awarii przesłanych do sklepu Google Play. Dzienniki awarii zawierają cenne informacje ułatwiające naprawienie awarii.

Postępuj zgodnie z instrukcjami w sekcji Rozpoczęcie pracy z Unity, jeśli SDK nie został jeszcze skonfigurowany w aplikacji.

Dzienniki awaryjne w systemie iOS wymagają symbolizacji. Aby włączyć symbole, zapoznaj się z dokumentacją diagnostyki Centrum aplikacji, w której wyjaśniono, jak dostarczać symbole dla aplikacji.

Generowanie awarii testowej

App Center Crashes zapewnia interfejs API do generowania testowej awarii w celu łatwego testowania SDK. Ten interfejs API sprawdza konfiguracje debugowania i produkcji. Dlatego można go używać tylko podczas debugowania, ponieważ nie będzie działać w przypadku aplikacji przeznaczonych do wydania.

Crashes.GenerateTestCrash();

Uzyskaj więcej informacji o poprzedniej awarii

Usługa App Center Crash ma dwa interfejsy API, które zapewniają więcej informacji na wypadek awarii aplikacji.

Czy aplikacja otrzymała ostrzeżenie o niskiej ilości pamięci w poprzedniej sesji?

W dowolnym momencie po uruchomieniu zestawu SDK możesz sprawdzić, czy aplikacja otrzymała ostrzeżenie o pamięci w poprzedniej sesji:

bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;

Czy aplikacja uległa awarii w poprzedniej sesji?

W dowolnym momencie po uruchomieniu zestawu SDK możesz sprawdzić, czy aplikacja uległa awarii w poprzednim uruchomieniu:

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

Wywołanie HasCrashedInLastSessionAsync jest przydatne, jeśli chcesz dostosować zachowanie lub interfejs użytkownika aplikacji po wystąpieniu awarii. Niektórzy deweloperzy pokazują dodatkowy interfejs użytkownika, aby przeprosić swoich użytkowników lub chcą się skontaktować po wystąpieniu awarii.

Szczegóły dotyczące ostatniej awarii

Jeśli aplikacja uległa awarii wcześniej, możesz uzyskać szczegółowe informacje o ostatniej awarii.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

Najczęstszym przypadkiem użycia tego interfejsu API jest zaimplementowanie przez użytkownika niestandardowego delegata lub odbiornika awarii.

Dostosowywanie użytkowania funkcji App Center Crashes

Usługa App Center Crashes udostępnia dla deweloperów wywołania zwrotne w celu wykonywania dodatkowych działań przed i podczas wysyłania dzienników awarii do App Center.

Czy awaria powinna zostać przetworzona?

Ustaw następujące wywołanie zwrotne, jeśli chcesz zdecydować, czy należy przetworzyć konkretną awarię, czy nie. Na przykład może wystąpić awaria na poziomie systemu, którą chcesz zignorować, a nie wysłać do Centrum aplikacji.

Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
     // Check the report in here and return true or false depending on the ErrorReport.
    return true;
};

Poproś użytkownika o zgodę na wysłanie dziennika awarii

Jeśli prywatność użytkownika jest dla Ciebie ważna, możesz uzyskać potwierdzenie użytkownika przed wysłaniem raportu o awarii do Centrum aplikacji. SDK udostępnia wywołanie zwrotne, które informuje funkcję App Center Crashes o konieczności oczekiwania na potwierdzenie użytkownika przed wysłaniem raportów o awariach.

Jeśli kod używa tego wywołania zwrotnego, odpowiadasz za uzyskanie potwierdzenia użytkownika. Jedną z opcji jest wyświetlenie monitu dialogowego z jedną z następujących opcji: Zawsze wysyłaj, Wysyłaj i Nie wysyłaj. Na podstawie danych wejściowych określisz, co należy zrobić w App Center Crashes, a awaria zostanie następnie odpowiednio obsłużona.

Poniższe wywołanie zwrotne pokazuje, jak poinformować pakiet SDK o oczekiwaniu na potwierdzenie użytkownika przed wysłaniem raportów o błędach:

Crashes.ShouldAwaitUserConfirmation = () =>
{
    // Build your own UI to ask for user consent here. SDK doesn't provide one by default.

    // Return true if you built a UI for user consent and are waiting for user input on that custom UI, otherwise false.
    return true;
};

Jeśli wywołanie zwrotne zwraca true, musisz uzyskać zgodę użytkownika i przekazać wynik do SDK, używając następującego interfejsu API.

// Depending on the user's choice, call Crashes.NotifyUserConfirmation() with the right value.
Crashes.NotifyUserConfirmation(UserConfirmation.DontSend);
Crashes.NotifyUserConfirmation(UserConfirmation.Send);
Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend);

Przykładem może być przykład niestandardowego okna dialogowego.

Uzyskaj informacje o stanie wysyłki dziennika awarii

Czasami chcesz poznać stan awarii aplikacji. Typowy przypadek użycia to wyświetlanie interfejsu użytkownika, który informuje użytkownika, że aplikacja przesyła raport o awarii. Innym scenariuszem jest dostosowanie zachowania aplikacji w celu upewnienia się, że dzienniki awarii można przesłać wkrótce po ponownym uruchomieniu. Awarie w App Center udostępniają trzy różne wywołania zwrotne, które pozwalają otrzymywać powiadomienia o tym, co się dzieje.

Następujące wywołanie zwrotne zostanie wywołane przed wysłaniem dziennika awarii przez zestaw SDK

Crashes.SendingErrorReport += (errorReport) =>
{
    // Your code, e.g. to present a custom UI.
};

W przypadku problemów z siecią lub przestoju na końcowym punkcie i ponownego uruchomienia aplikacji, SendingErrorReport zostanie uruchomiony ponownie po restarcie procesu.

Następujące wywołanie zwrotne zostanie wywołane po pomyślnym wysłaniu dziennika awarii przez zestaw SDK

Crashes.SentErrorReport += (errorReport) =>
{
    // Your code, e.g. to hide the custom UI.
};

Następujące wywołanie zwrotne zostanie wywołane, jeśli zestaw SDK nie może wysłać dziennika awarii

Crashes.FailedToSendErrorReport += (errorReport, exception) =>
{
    // Your code goes here.
};

Odbieranie FailedToSendErrorReport oznacza, że wystąpił błąd niemożliwy do odzyskania, taki jak kod 4xx . Na przykład 401 oznacza, że appSecret jest nieprawidłowy.

Ten callback nie zostanie wywołany, jeśli jest to problem z siecią. W takim przypadku zestaw SDK ponawia próbę (a także wstrzymuje ponawianie próby, gdy połączenie sieciowe nie działa).

Dodawanie załączników do raportu o awarii lub nieobsługiwanym wyjątku

Opcjonalnie możesz również dodać załączniki binarne i tekstowe do zrzutu awaryjnego lub raportu o nieobsługiwanym wyjątku. Zestaw SDK wyśle je wraz z raportem, aby można było je zobaczyć w portalu centrum aplikacji. Następujące wywołanie zwrotne zostanie wywołane bezpośrednio przed wysłaniem przechowywanego raportu. W przypadku awarii dzieje się to podczas następnego uruchamiania aplikacji. W przypadku nieobsługiwanych wyjątków należy wyrazić zgodę na wysyłanie załączników. Upewnij się, że plik załącznika nie ma nazwy minidump.dmp , ponieważ ta nazwa jest zarezerwowana dla plików minidump. Oto przykład dołączania tekstu i obrazu do raportu:

Crashes.GetErrorAttachments = (ErrorReport report) =>
{
    // Your code goes here.
    return new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
};

Awarie są odróżniane od nieobsługiwanych wyjątków w raportach przy użyciu właściwości IsCrash. Właściwość będzie mieć wartość true dla awarii i false w przeciwnym razie.

Włączanie lub wyłączanie funkcji raportowania awarii w App Center w czasie wykonywania

Możesz włączyć i wyłączyć funkcję zarządzania awariami w usłudze App Center w czasie wykonywania. Jeśli go wyłączysz, zestaw SDK nie będzie wykonywać żadnego raportowania awarii dla aplikacji.

Crashes.SetEnabledAsync(false);

Aby ponownie włączyć funkcję Crashes w usłudze App Center, użyj tego samego interfejsu API, ale przekaż true jako parametr.

Crashes.SetEnabledAsync(true);

Nie musisz czekać na to wywołanie, aby inne wywołania interfejsu API (takie jak IsEnabledAsync) były spójne.

Stan jest utrwalany w magazynie urządzenia w ramach uruchamiania aplikacji.

Sprawdź, czy raportowanie awarii w App Center jest włączone

Możesz również sprawdzić, czy usługa App Center Ulega awarii jest włączona:

bool isEnabled = await Crashes.IsEnabledAsync();

Obsługiwane wyjątki w Unity

Usługa App Center umożliwia również śledzenie błędów przy użyciu obsługiwanych wyjątków w aplikcie Unity. W tym celu użyj TrackError metody :

try {
    // your code goes here.
} catch (Exception exception) {
    Crashes.TrackError(exception);
}

Aby uzyskać dodatkowy kontekst dotyczący błędu, możesz również dołączyć do niego właściwości. Przekaż właściwości jako słownik ciągów znaków. Ten krok jest opcjonalny.

try {
    // your code goes here.
} catch (Exception exception) {
    var properties = new Dictionary<string, string>
    {
        { "Category", "Music" },
        { "Wifi", "On" }
    };
    Crashes.TrackError(exception, properties);
}

Opcjonalnie możesz również dodać załączniki binarne i tekstowe do obsłużonego raportu o błędach. Przekaż załączniki jako tablicę ErrorAttachmentLog obiektów, jak pokazano w poniższym przykładzie.

try {
    // your code goes here.
} catch (Exception exception) {
    var attachments = new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
    Crashes.TrackError(exception, attachments: attachments);
}

Nieobsługiwane wyjątki w Unity

Zgłoś nieobsługiwane wyjątki

Domyślnie zestaw SDK centrum aplikacji nie zgłasza nieobsługiwanych wyjątków zgłaszanych w aplikacji, które nie powodują awarii krytycznej. Aby włączyć tę funkcję, wywołaj następującą metodę:

Crashes.ReportUnhandledExceptions(true);

Po wywołaniu tego interfejsu API centrum aplikacji rejestruje wszystkie nieobsługiwane wyjątki jako problemy w portalu Centrum aplikacji, podobnie jak w przypadku obsługiwanych wyjątków wymienionych wcześniej. Aby wyłączyć tę funkcję, wywołaj ten sam interfejs API przekazujący false jako parametr.

Crashes.ReportUnhandledExceptions(false);

Dodaj załączniki do raportu o nieobsłużonym wyjątku

Domyślnie SDK App Center nie włącza załączników do nieobsługiwanych wyjątków. Aby włączyć tę funkcję, ustaw logiczny parametr metody enableAttachmentsCallback na ReportUnhandledExceptions:

Crashes.ReportUnhandledExceptions(true, true);

Następnie możesz opcjonalnie dodać załączniki do nieobsługiwanego raportu wyjątku, implementując wywołanie zwrotne GetErrorAttachments .

Raportowanie awarii NDK

Raportowanie awarii

Aby otrzymywać odpowiednie raporty o awarii w centrum aplikacji, najpierw upewnij się, że zestaw SDK awarii centrum aplikacji został skonfigurowany, postępując zgodnie z instrukcjami wymienionymi powyżej.

Kompilowanie biblioteki breakpad

Następnie należy uwzględnić i skompilować aplikację Google Breakpad, postępując zgodnie z instrukcjami wymienionymi w oficjalnym notatniku Google Breakpad dla systemu Android README. Aby używać go w apliki Unity, dołącz plik binarny do aplikacji.

Dołączanie programu obsługi wyjątków

Po dołączeniu aplikacji Google Breakpad dołącz program obsługi awarii NDK:

/* Attach NDK Crash Handler. */
var minidumpDir = Crashes.GetMinidumpDirectoryAsync();
setupNativeCrashesListener(minidumpDir.Result);

...

[DllImport("YourLib")]
private static extern void setupNativeCrashesListener(string path);

Metoda setupNativeCrashesListener jest natywną metodą, którą należy zaimplementować w języku C/C++:

#include <android/log.h>
#include "google-breakpad/src/client/linux/handler/exception_handler.h"
#include "google-breakpad/src/client/linux/handler/minidump_descriptor.h"

static google_breakpad::ExceptionHandler exception_handler(google_breakpad::MinidumpDescriptor(), NULL, dumpCallback, NULL, true, -1);

/**
 * Registers breakpad as the exception handler for NDK code.
 * @param path minidump directory path returned from Crashes.GetMinidumpDirectoryAsync()
 */
extern "C" void setupNativeCrashesListener(const char *path) {
    google_breakpad::MinidumpDescriptor descriptor(path);
    exception_handler.set_minidump_descriptor(descriptor);
}

Gdzie dumpCallback służy do rozwiązywania problemów:

/*
 * Triggered automatically after an attempt to write a minidump file to the breakpad folder.
 */
static bool dumpCallback(const google_breakpad::MinidumpDescriptor &descriptor,
                         void *context,
                         bool succeeded) {

    /* Allow system to log the native stack trace. */
    __android_log_print(ANDROID_LOG_INFO, "YourLogTag",
                        "Wrote breakpad minidump at %s succeeded=%d\n", descriptor.path(),
                        succeeded);
    return false;
}

Po poprawnym skonfigurowaniu tych metod aplikacja automatycznie wysyła minidump do Centrum aplikacji po ponownym uruchomieniu. Aby rozwiązać problemy, możesz użyć szczegółowych dzienników, aby sprawdzić, czy zrzuty awaryjne są wysyłane po ponownym uruchomieniu aplikacji.

Symbolezacja

Aby uzyskać więcej informacji na temat przetwarzania awarii, zobacz dokumentację diagnostyki .