App Center stürzt ab (Android)

Wichtig

Visual Studio App Center wird am 31. März 2025 eingestellt. Sie können Visual Studio App Center zwar weiterhin verwenden, bis es vollständig eingestellt ist, es gibt jedoch mehrere empfohlene Alternativen, zu denen Sie eine Migration in Betracht ziehen können.

Erfahren Sie mehr über Supportzeitpläne und Alternativen.

App Center-Abstürze generieren automatisch ein Absturzprotokoll, wenn Ihre App abstürzt. Das Protokoll wird zuerst in den Speicher des Geräts geschrieben, und wenn der Benutzer die App erneut startet, wird der Absturzbericht an App Center gesendet. Das Sammeln von Abstürze funktioniert sowohl für Beta- als auch für Live-Apps, d. h. für solche, die an Google Play übermittelt werden. Absturzprotokolle enthalten wertvolle Informationen zur Behebung des Absturzes.

Befolgen Sie den Abschnitt Erste Schritte, wenn Sie das SDK noch nicht in Ihrer Anwendung eingerichtet haben.

Generieren eines Testabsturzes

App Center Crashes bietet Ihnen eine API zum Generieren eines Testabsturzes zum einfachen Testen des SDK. Diese API kann nur in Debugbuilds verwendet werden und führt in Releasebuilds keine Aktionen aus.

Crashes.generateTestCrash();
Crashes.generateTestCrash()

Weitere Informationen zu einem vorherigen Absturz

App Center-Abstürze verfügt über zwei APIs, die Ihnen weitere Informationen für den Fall liefern, dass Ihre App abgestürzt ist.

Hat die App in der vorherigen Sitzung eine Warnung zu wenig Arbeitsspeicher erhalten?

Nach dem Starten des SDK können Sie jederzeit überprüfen, ob die App in der vorherigen Sitzung eine Speicherwarnung erhalten hat:

Crashes.hasReceivedMemoryWarningInLastSession();
Crashes.hasReceivedMemoryWarningInLastSession()

Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .

Hinweis

Diese Methode darf nur verwendet werden, nachdem Crashes gestartet wurde. Sie wird immer vor dem Start zurückgegeben false .

Hinweis

In einigen Fällen kann ein Gerät mit wenig Arbeitsspeicher keine Ereignisse senden.

Ist die App in der vorherigen Sitzung abgestürzt?

Nach dem Starten des SDK können Sie jederzeit überprüfen, ob die App beim vorherigen Start abgestürzt ist:

Crashes.hasCrashedInLastSession();
Crashes.hasCrashedInLastSession()

Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .

Dies ist nützlich, wenn Sie das Verhalten oder die Benutzeroberfläche Ihrer App nach einem Absturz anpassen möchten. Einige Entwickler haben sich entschieden, eine zusätzliche Benutzeroberfläche anzuzeigen, um sich bei ihren Benutzern zu entschuldigen oder nach einem Absturz kontaktieren zu können.

Hinweis

Diese Methode darf nur verwendet werden, nachdem Crashes gestartet wurde. Sie wird immer vor dem Start zurückgegeben false .

Details zum letzten Absturz

Wenn Ihre App zuvor abgestürzt ist, können Sie Details zum letzten Absturz abrufen.

Crashes.getLastSessionCrashReport();
Crashes.getLastSessionCrashReport()

Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .

Es gibt zahlreiche Anwendungsfälle für diese API. Am häufigsten sind Personen, die diese API aufrufen und ihre benutzerdefinierten CrashesListener implementieren.

Hinweis

Diese Methode darf nur verwendet werden, nachdem Crashes gestartet wurde. Sie wird immer vor dem Start zurückgegeben null .

Anpassen der Nutzung von App Center-Abstürze

App Center-Abstürze bietet Rückrufe für Entwickler, um zusätzliche Aktionen vor und beim Senden von Absturzprotokollen an App Center auszuführen.

Um die Rückrufe zu verarbeiten, implementieren Sie entweder alle Methoden in der CrashesListener -Schnittstelle, oder überschreiben Sie die AbstractCrashesListener -Klasse, und wählen Sie nur die Methoden aus, an denen Sie interessiert sind.

Verwenden Sie Ihren eigenen CrashesListener.

Erstellen Sie Ihren eigenen CrashesListener, und weisen Sie ihn wie folgt zu:

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

Falls Sie nur einige der Rückrufe anpassen möchten, verwenden Sie stattdessen Folgendes 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)

Hinweis

Legen Sie den Listener vor dem Aufrufen AppCenter.start()von fest, da App Center unmittelbar nach dem Start mit der Verarbeitung abstürzt.

Sollte der Absturz verarbeitet werden?

Implementieren Sie diesen Rückruf, wenn Sie entscheiden möchten, ob ein bestimmter Absturz verarbeitet werden muss oder nicht. Es kann z. B. zu einem Absturz auf Systemebene kommen, den Sie ignorieren und den Sie nicht an App Center senden möchten.

@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
}

Wenn Ihnen der Datenschutz des Benutzers wichtig ist, sollten Sie die Benutzerbestätigung erhalten, bevor Sie einen Absturzbericht an App Center senden. Das SDK macht einen Rückruf verfügbar, der App Center-Abstürze angibt, die Benutzerbestätigung abzuwarten, bevor Absturzberichte gesendet werden.

Wenn Sie sich dafür entschieden haben, sind Sie dafür verantwortlich, die Bestätigung des Benutzers zu erhalten, z. B. über eine Dialogaufforderung mit einer der folgenden Optionen: Immer senden, senden und Nicht senden. Basierend auf der Eingabe geben Sie App Center-Abstürze an, was zu tun ist, und der Absturz wird dann entsprechend behandelt.

Hinweis

Das SDK zeigt dafür kein Dialogfeld an. Die App muss eine eigene Benutzeroberfläche bereitstellen, um die Zustimmung des Benutzers zu verlangen.

Der folgende Rückruf zeigt, wie das SDK anweisen kann, auf die Benutzerbestätigung zu warten, bevor Abstürze gesendet werden:

@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
}

Wenn Sie zurückgeben true, muss Ihre App (mit Ihrem eigenen Code) die Benutzerberechtigung abrufen und dem SDK mit dem Ergebnis mithilfe der folgenden API eine Nachricht senden:

// 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)

Als Beispiel können Sie auf unser Benutzerdefiniertes Dialogfeldbeispiel verweisen.

Abrufen von Informationen zum sendenden status für ein Absturzprotokoll

Manchmal möchten Sie die status ihres App-Absturzes kennen. Ein häufiger Anwendungsfall ist, dass Sie möglicherweise eine Benutzeroberfläche anzeigen möchten, die den Benutzern mitteilt, dass Ihre App einen Absturzbericht übermittelt. Falls Ihre App nach dem Start schnell abstürzt, möchten Sie das Verhalten der App anpassen, um sicherzustellen, dass die Absturzprotokolle übermittelt werden können. App Center-Abstürze verfügt über drei verschiedene Rückrufe, die Sie in Ihrer App verwenden können, um über die Vorgänge benachrichtigt zu werden:

Der folgende Rückruf wird aufgerufen, bevor das SDK ein Absturzprotokoll sendet.

@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.
}

Falls Netzwerkprobleme oder ein Ausfall des Endpunkts auftreten und Sie die App neu starten, onBeforeSending wird nach dem Prozessneustart erneut ausgelöst.

Der folgende Rückruf wird aufgerufen, nachdem das SDK erfolgreich ein Absturzprotokoll gesendet hat.

@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.
}

Der folgende Rückruf wird aufgerufen, wenn das SDK ein Absturzprotokoll nicht senden konnte

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

onSendingFailed Empfangen bedeutet, dass ein nicht wiederherstellbarer Fehler auftritt, z. B. ein 4xx-Code. Beispielsweise bedeutet 401 , dass falsch appSecret ist.

Dieser Rückruf wird nicht ausgelöst, wenn es sich um ein Netzwerkproblem handelt. In diesem Fall versucht das SDK immer wieder (und hält auch Wiederholungen an, während die Netzwerkverbindung ausfällt).

Hinzufügen von Anlagen zu einem Absturzbericht

Sie können binär- und Textanlagen zu einem Absturzbericht hinzufügen. Das SDK sendet sie zusammen mit dem Absturz, sodass Sie sie im App Center-Portal sehen können. Der folgende Rückruf wird direkt vor dem Senden des gespeicherten Absturzes von früheren Anwendungsstarts aufgerufen. Es wird nicht aufgerufen, wenn der Absturz auftritt. Stellen Sie sicher, dass die Anlagedatei nicht benannt minidump.dmp ist, da dieser Name für Minidump-Dateien reserviert ist. Hier sehen Sie ein Beispiel für das Anfügen von Text und einem Bild an einen Absturz:

@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)
}

Hinweis

Die Größenbeschränkung beträgt derzeit 7 MB. Beim Versuch, eine größere Anlage zu senden, wird ein Fehler ausgelöst.

Aktivieren oder Deaktivieren von App Center-Abstürze zur Laufzeit

Sie können App Center-Abstürze zur Laufzeit aktivieren und deaktivieren. Wenn Sie sie deaktivieren, erstellt das SDK keine Absturzberichte für die App.

Crashes.setEnabled(false);
Crashes.setEnabled(false)

Um App Center-Abstürze erneut zu aktivieren, verwenden Sie dieselbe API, übergeben true Sie jedoch als Parameter.

Crashes.setEnabled(true);
Crashes.setEnabled(true)

Der Zustand wird über Anwendungsstarts hinweg im Speicher des Geräts beibehalten.

Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .

Hinweis

Diese Methode darf erst nach dem Crashes Start verwendet werden.

Überprüfen, ob App Center-Abstürze aktiviert ist

Sie können auch überprüfen, ob App Center-Abstürze aktiviert ist oder nicht:

Crashes.isEnabled();
Crashes.isEnabled()

Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .

Hinweis

Diese Methode darf nur verwendet werden, nachdem Crashes gestartet wurde. Sie wird immer vor dem Start zurückgegeben false .

Behandelte Fehler

Mit App Center können Sie auch Fehler mithilfe von behandelten Ausnahmen nachverfolgen. Verwenden Sie dazu die trackError -Methode:

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

Eine App kann optional Eigenschaften an einen behandelten Fehlerbericht anfügen, um weiteren Kontext bereitzustellen. Übergeben Sie die Eigenschaften als Zuordnung von Schlüssel-Wert-Paaren (nur Zeichenfolgen), wie im folgenden Beispiel gezeigt.

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)
}

Optional können Sie auch Binär- und Textanlagen zu einem behandelten Fehlerbericht hinzufügen. Übergeben Sie die Anlagen als wie Iterable im folgenden Beispiel gezeigt.

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))
}

Melden von NDK-Abstürze

Melden von Abstürzen

Um ordnungsgemäße Absturzberichte in App Center zu erhalten, stellen Sie zunächst sicher, dass Sie das App Center Crashes SDK eingerichtet haben, indem Sie die oben aufgeführten Anweisungen befolgen.

Erstellen der Breakpadbibliothek

Fügen Sie als Nächstes Google Breakpad hinzu, und kompilieren Sie es, indem Sie die Anweisungen in der offiziellen Infodatei zu Google Breakpad für Android befolgen.

Hinweis

Das App Center SDK bündelt Google Breakpad standardmäßig nicht.

Anfügen des Ausnahmehandlers

Sobald Google Breakpad enthalten ist, fügen Sie den NDK-Absturzhandler nach an 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);
        }
    }
});

Die -Methode setupNativeCrashesListener ist eine native Methode, die Sie in C/C++ implementieren müssen:

#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);
}

Wo dumpCallback wird für die Problembehandlung verwendet:

/*
 * 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;
}

Nachdem diese Methoden ordnungsgemäß eingerichtet wurden, sendet die App den Minidump beim Neustart automatisch an App Center. Zur Problembehandlung können Sie ausführliche Protokolle (AppCenter.setLogLevel(Log.VERBOSE) vor AppCenter.start) verwenden, um zu überprüfen, ob Minidumps nach dem Neustart der App gesendet werden.

Hinweis

App Center verwendet den reservierten Namen minidump.dmp für Minidumpanlagen. Stellen Sie sicher, dass Sie Ihrer Anlage einen anderen Namen geben, es sei denn, es handelt sich um eine Minidumpdatei, damit wir sie ordnungsgemäß verarbeiten können.

Hinweis

Es gibt einen bekannten Fehler in Breakpad, der es unmöglich macht, Abstürze auf x86-Emulatoren zu erfassen.

Symbolik

Weitere Informationen zur Verarbeitung von Abstürze finden Sie in der Diagnosedokumentation .