Awarie usługi App Center (Android)

Awarie usługi App Center automatycznie generują dziennik awarii za każdym razem, gdy aplikacja ulegnie awarii. Dziennik jest najpierw zapisywany w magazynie urządzenia, a gdy użytkownik ponownie uruchomi aplikację, raport o awarii zostanie wysłany do Centrum aplikacji. Zbieranie awarii działa zarówno w przypadku aplikacji beta, jak i działających publicznie, czyli przesłanych do Google Play. Dzienniki awarii zawierają cenne informacje ułatwiające naprawienie awarii.

Postępuj zgodnie z sekcją Wprowadzenie , jeśli zestaw SDK nie został jeszcze skonfigurowany w aplikacji.

Generowanie awarii testowej

App Center Crashes zapewnia interfejs API do generowania testowej awarii w celu łatwego testowania SDK. To API może być używane tylko w kompilacjach debugowania i nie będzie działać w kompilacjach produkcyjnych.

Crashes.generateTestCrash();

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:

Crashes.hasReceivedMemoryWarningInLastSession();

Crashes.hasReceivedMemoryWarningInLastSession()

Ten interfejs API jest asynchroniczny. Więcej informacji na ten temat można przeczytać w naszym przewodniku asynchronicznych interfejsów API centrum aplikacji .

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:

Crashes.hasCrashedInLastSession();

Crashes.hasCrashedInLastSession()

Ten interfejs API jest asynchroniczny. Więcej informacji na ten temat można przeczytać w naszym przewodniku asynchronicznych interfejsów API centrum aplikacji .

Jest to przydatne w przypadku, gdy chcesz dostosować zachowanie lub interfejs użytkownika aplikacji po wystąpieniu awarii. Niektórzy deweloperzy zdecydowali się pokazać dodatkowy interfejs użytkownika, aby przeprosić swoich użytkowników lub chcieć skontaktować się 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.

Crashes.getLastSessionCrashReport();

Crashes.getLastSessionCrashReport()

Ten interfejs API jest asynchroniczny. Więcej informacji na ten temat można przeczytać w naszym przewodniku asynchronicznych interfejsów API centrum aplikacji .

Istnieje wiele przypadków użycia dla tego interfejsu API, a najczęściej spotykane są osoby, które wywołują ten interfejs API i implementują niestandardowe CrashesListener.

Dostosowywanie użytkowania funkcji App Center Crashes

Usługa App Center Crash udostępnia wywołania zwrotne dla deweloperów do wykonywania dodatkowych akcji przed i podczas wysyłania dzienników awarii do Centrum aplikacji.

Aby obsłużyć wywołania zwrotne, zaimplementuj wszystkie metody w interfejsie CrashesListener lub przesłoń klasę AbstractCrashesListener i wybierz tylko te, które cię interesują.

Wykorzystaj własny CrashesListener

Utwórz własny element CrashListener i przypisz go w następujący sposób:

CrashesListener customListener = new CrashesListener() {
    // Implement all callbacks here.
};
Crashes.setListener(customListener);

val customListener = object : CrashesListener {
    // Implement all callbacks here.
}
Crashes.setListener(customListener)

Jeśli interesuje Cię tylko dostosowywanie niektórych wywołań zwrotnych, użyj polecenia zamiast tego AbstractCrashesListener :

AbstractCrashesListener customListener = new AbstractCrashesListener() {
    // Implement any callback here as required.
};
Crashes.setListener(customListener);

val customListener = object : AbstractCrashesListener() {
    // Implement any callback here as required.
}
Crashes.setListener(customListener)

Czy awaria powinna zostać przetworzona?

Zaimplementuj to 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ć i że nie chcesz wysyłać do Centrum aplikacji.

@Override
public boolean shouldProcess(ErrorReport report) {
    return true; // return true if the crash report should be processed, otherwise false.
}

override fun shouldProcess(report: ErrorReport?): Boolean {
    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 zdecydujesz się to zrobić, odpowiadasz za uzyskanie potwierdzenia użytkownika, np. za pośrednictwem okna dialogowego z jedną z następujących opcji: Zawsze wysyłaj, Wysyłaj i Nie wysyłaj. Na podstawie danych wejściowych poinstruujesz App Center Crashes, co należy zrobić, a awaria zostanie 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:

@Override
public boolean 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;
}

override fun shouldAwaitUserConfirmation(): Boolean {
    return true
}

Jeśli zwrócisz true, aplikacja musi uzyskać (przy użyciu własnego kodu) uprawnienia użytkownika i poinformować SDK o wyniku, używając następującego interfejsu API:

// Depending on the user's choice, call Crashes.notifyUserConfirmation() with the right value.
Crashes.notifyUserConfirmation(Crashes.DONT_SEND);
Crashes.notifyUserConfirmation(Crashes.SEND);
Crashes.notifyUserConfirmation(Crashes.ALWAYS_SEND);

Crashes.notifyUserConfirmation(Crashes.DONT_SEND)
Crashes.notifyUserConfirmation(Crashes.SEND)
Crashes.notifyUserConfirmation(Crashes.ALWAYS_SEND)

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 polega na tym, że możesz pokazać interfejs użytkownika, który informuje użytkowników, że aplikacja przesyła raport o awarii lub w przypadku, gdy aplikacja ulega awarii szybko po uruchomieniu, chcesz dostosować zachowanie aplikacji, aby upewnić się, że dzienniki awarii można przesłać. W App Center Crashes są trzy różne wywołania zwrotne, które można zastosować w aplikacji, aby być powiadamianym o bieżących wydarzeniach.

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

@Override
public void onBeforeSending(ErrorReport errorReport) {
    // Your code, e.g. to present a custom UI.
}

override fun onBeforeSending(report: 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, onBeforeSending 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

@Override
public void onSendingSucceeded(ErrorReport report) {
    // Your code, e.g. to hide the custom UI.
}

override fun onSendingSucceeded(report: 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

@Override
public void onSendingFailed(ErrorReport report, Exception e) {
    // Your code goes here.
}

override fun onSendingFailed(report: ErrorReport?, e: Exception?) {
    // Your code goes here.
}

Odbieranie onSendingFailed 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

Do raportu o awarii można dodawać załączniki binarne i tekstowe. Zestaw SDK wyśle je wraz z awarią, aby można było je zobaczyć w portalu usługi App Center. Następujące wywołanie zwrotne zostanie wywołane bezpośrednio przed wysłaniem przechowywanej awarii z poprzednich uruchomień aplikacji. Nie będzie wywoływana, gdy wystąpi awaria. 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 awarii:

@Override
public Iterable<ErrorAttachmentLog> getErrorAttachments(ErrorReport report) {

    // Attach some text.
    ErrorAttachmentLog textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt");

    // Attach binary data.
    byte[] binaryData = getYourBinary();
    ErrorAttachmentLog binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg");

    // Return attachments as list.
    return Arrays.asList(textLog, binaryLog);
}

override fun getErrorAttachments(report: ErrorReport?): MutableIterable<ErrorAttachmentLog> {

    // Attach some text.
    val textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt")

    // Attach binary data.
    val binaryData = getYourBinary()
    val binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg")

    // Return attachments as list.
    return listOf(textLog, binaryLog)
}

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ć żadnych raportów dotyczących awarii dla aplikacji.

Crashes.setEnabled(false);

Crashes.setEnabled(false)

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

Crashes.setEnabled(true);

Crashes.setEnabled(true)

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

Ten interfejs API jest asynchroniczny. Więcej informacji na ten temat można przeczytać w naszym przewodniku asynchronicznych interfejsów API centrum 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, czy nie:

Crashes.isEnabled();

Crashes.isEnabled()

Ten interfejs API jest asynchroniczny. Więcej informacji na ten temat można przeczytać w naszym przewodniku asynchronicznych interfejsów API centrum aplikacji .

Zarządzane błędy

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

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

try {
    // your code goes here.
} catch (exception: Exception) {
    Crashes.trackError(exception)
}

Aplikacja może opcjonalnie dołączyć właściwości do obsługiwanego raportu o błędach w celu zapewnienia dalszego kontekstu. Przekaż właściwości jako mapę par klucz/wartość (tylko ciągi), jak pokazano w poniższym przykładzie.

try {
    // your code goes here.
} catch (Exception exception) {
    Map<String, String> properties = new HashMap<String, String>() {{
        put("Category", "Music");
        put("Wifi", "On");
    }};
    Crashes.trackError(exception, properties, null);
}

try {
    // your code goes here.
} catch (exception: Exception) {
    val properties = mapOf("Category" to "Music", "Wifi" to "On")
    Crashes.trackError(exception, properties, null)
}

Opcjonalnie możesz również dodać załączniki binarne i tekstowe do obsłużonego raportu o błędach. Przekaż załączniki jako Iterable zgodnie z poniższym przykładem.

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

    // Attach some text.
    ErrorAttachmentLog textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt");

    // Attach binary data.
    byte[] binaryData = getYourBinary();
    ErrorAttachmentLog binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg");

    // Track an exception with attachments.
    Crashes.trackError(exception, null, Arrays.asList(textLog, binaryLog));
}

try {
    // your code goes here.
} catch (exception: Exception) {

    // Attach some text.
    val textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt")

    // Attach binary data.
    val binaryData = getYourBinary()
    val binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg")

    // Track an exception with attachments.
    Crashes.trackError(exception, null, listOf(textLog, binaryLog))
}

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 uwzględnij i skompiluj aplikację Google Breakpad, postępując zgodnie z instrukcjami wymienionymi w oficjalnym module Google Breakpad dla systemu Android README.

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

Po dołączeniu aplikacji Google Breakpad dołącz program obsługi awarii NDK po :AppCenter.start

// Attach NDK Crash Handler after SDK is initialized.
Crashes.getMinidumpDirectory().thenAccept(new AppCenterConsumer<String>() {
    @Override
    public void accept(String path) {

        // Path is null when Crashes is disabled.
        if (path != null) {
            setupNativeCrashesListener(path);
        }
    }
});

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

#include "google-breakpad/src/client/linux/handler/exception_handler.h"
#include "google-breakpad/src/client/linux/handler/minidump_descriptor.h"

void Java_com_microsoft_your_package_YourActivity_setupNativeCrashesListener(
        JNIEnv *env, jobject, jstring path) {
    const char *dumpPath = (char *) env->GetStringUTFChars(path, NULL);
    google_breakpad::MinidumpDescriptor descriptor(dumpPath);
    new google_breakpad::ExceptionHandler(descriptor, NULL, dumpCallback, NULL, true, -1);
    env->ReleaseStringUTFChars(path, dumpPath);
}

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

/*
 * Triggered automatically after an attempt to write a minidump file to the breakpad folder.
 */
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ć pełnych dzienników (AppCenter.setLogLevel(Log.VERBOSE) przed AppCenter.start) w celu sprawdzenia, czy minidumps są wysyłane po ponownym uruchomieniu aplikacji.

Symbolezacja

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