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.
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.
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()
App Center-Abstürze verfügt über zwei APIs, die Ihnen weitere Informationen für den Fall liefern, dass Ihre App abgestürzt ist.
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.
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
.
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
.
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.
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.
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.
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:
@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.
}
@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).
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.
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.
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
.
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))
}
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.
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.
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.
Weitere Informationen zur Verarbeitung von Abstürze finden Sie in der Diagnosedokumentation .