App Center stürzt ab (Unity)
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 möglicherweise eine Migration in Erwägung ziehen.
App Center-Abstürze generiert automatisch jedes Mal, wenn Ihre App abstürzt, ein Absturzprotokoll mit einem Protokoll an Gerätespeicher. Wenn ein Benutzer die App erneut startet, sendet das SDK den Absturzbericht an App Center. Das Sammeln von Abstürze funktioniert sowohl für Beta- als auch für Live-Apps, d. h. Abstürze, die an Google Play übermittelt werden. Absturzprotokolle enthalten wertvolle Informationen, die Sie bei der Behebung des Absturzes unterstützen.
Befolgen Sie die Anweisungen im Abschnitt Unity Erste Schritte, wenn Sie das SDK noch nicht in Ihrer Anwendung eingerichtet haben.
Absturzprotokolle unter iOS erfordern Symbolik. Informationen zum Aktivieren der Symbolik finden Sie in der App Center-Diagnosedokumentation, in der erläutert wird, wie Symbole für Ihre App bereitgestellt werden.
Wichtig
Das Crashes SDK für Unity unterstützt UWP nicht. Die Anweisungen auf dieser Seite behandeln nur Android und iOS.
Hinweis
Das SDK leitet keine Absturzprotokolle weiter, wenn Sie den Debugger angefügt haben. Stellen Sie sicher, dass der Debugger nicht angefügt ist, wenn Sie die App abstürzen.
Hinweis
Wenn Sie die Option in PlayerSettings aktiviert habenEnable CrashReport API, sammelt das SDK keine Absturzprotokolle.
Generieren eines Testabsturzes
App Center Crashes bietet Ihnen eine API zum Generieren eines Testabsturzes zum einfachen Testen des SDK. Diese API sucht nach Debug- und Releasekonfigurationen. Sie können es also nur beim Debuggen verwenden, da es für Release-Apps nicht funktioniert.
Crashes.GenerateTestCrash();
Hinweis
Diese Methode funktioniert nur mit aktivierter Entwicklungsbuildeinstellung .
Weitere Informationen zu einem vorherigen Absturz
App Center Crashes verfügt über zwei APIs, die Ihnen weitere Informationen liefern, falls 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:
bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;
Hinweis
Diese Methode funktioniert nicht in Awake().
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:
bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();
Das Aufrufen HasCrashedInLastSessionAsync ist nützlich, wenn Sie das Verhalten oder die Benutzeroberfläche Ihrer App nach einem Absturz anpassen möchten. Einige Entwickler zeigen eine zusätzliche Benutzeroberfläche an, um sich bei ihren Benutzern zu entschuldigen, oder möchten sich nach einem Absturz mit ihnen in Verbindung setzen.
Details zum letzten Absturz
Wenn Ihre App zuvor abgestürzt ist, können Sie Details zum letzten Absturz abrufen.
ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();
Der häufigste Anwendungsfall für diese API ist, wenn ein Benutzer seinen benutzerdefinierten Absturzdelegat oder Listener implementiert.
Anpassen der Nutzung von App Center-Abstürze
App Center Crashes bietet Rückrufe für Entwickler, um zusätzliche Aktionen zu ergreifen, bevor und wann sie Absturzprotokolle an App Center senden.
Hinweis
Legen Sie den Rückruf fest, bevor App Center gestartet wird, z. B. in der Awake -Methode, da App Center mit der Verarbeitung von Abstürze unmittelbar nach dem Start beginnt.
Sollte der Absturz verarbeitet werden?
Legen Sie den folgenden Rückruf fest, wenn Sie entscheiden möchten, ob ein bestimmter Absturz verarbeitet werden muss oder nicht. Beispielsweise kann es zu einem Absturz auf Systemebene kommen, den Sie ignorieren und nicht an App Center senden möchten.
Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
// Check the report in here and return true or false depending on the ErrorReport.
return true;
};
Anfordern der Zustimmung des Benutzers zum Senden eines Absturzprotokolls
Wenn Ihnen der Datenschutz der Benutzer wichtig ist, sollten Sie eine 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 Bestätigung des Benutzers abzuwarten, bevor Absturzberichte gesendet werden.
Wenn Ihr Code diesen Rückruf verwendet, sind Sie dafür verantwortlich, die Bestätigung des Benutzers zu erhalten. Eine Option besteht über eine Eingabeaufforderung mit einer der folgenden Optionen: Immer senden, senden und Nicht senden. Basierend auf der Eingabe teilen Sie den App Center-Abstürzen mit, 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 einzuholen.
Der folgende Rückruf zeigt, wie sie das SDK anweisen, auf die Benutzerbestätigung zu warten, bevor Abstürze gesendet werden:
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;
};
Wenn der Rückruf zurückgibt true, müssen Sie die Benutzerberechtigung abrufen und das SDK mit dem Ergebnis mithilfe der folgenden API per Nachricht senden:
// 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);
Als Beispiel können Sie sich auf unser benutzerdefiniertes Dialogfeldbeispiel beziehen.
Abrufen von Informationen zum sendenden status für ein Absturzprotokoll
Manchmal möchten Sie die status Ihres App-Absturzes kennen. Ein gängiger Anwendungsfall ist das Anzeigen einer Benutzeroberfläche, die den Benutzer darüber informiert, dass die App einen Absturzbericht übermittelt. Ein anderes Szenario ist, wenn Sie das Verhalten der App anpassen möchten, um sicherzustellen, dass die Absturzprotokolle kurz nach dem Neustart übermittelt werden können. App Center Abstürze bietet drei verschiedene Rückrufe, die Sie vornehmen können, um über die durchgeführten Vorgänge benachrichtigt zu werden:
Der folgende Rückruf wird aufgerufen, bevor das SDK ein Absturzprotokoll sendet.
Crashes.SendingErrorReport += (errorReport) =>
{
// Your code, e.g. to present a custom UI.
};
Falls Netzwerkprobleme oder ein Ausfall auf dem Endpunkt auftreten und Sie die App neu starten, SendingErrorReport wird nach dem Neustart des Prozesses erneut ausgelöst.
Der folgende Rückruf wird aufgerufen, nachdem das SDK erfolgreich ein Absturzprotokoll gesendet hat
Crashes.SentErrorReport += (errorReport) =>
{
// Your code, e.g. to hide the custom UI.
};
Der folgende Rückruf wird aufgerufen, wenn das SDK ein Absturzprotokoll nicht senden konnte
Crashes.FailedToSendErrorReport += (errorReport, exception) =>
{
// Your code goes here.
};
Der FailedToSendErrorReport Empfang bedeutet einen nicht wiederherstellbaren Fehler, 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 unterbrochen ist).
Hinzufügen von Anlagen zu einem Absturz oder einem nicht behandelten Ausnahmebericht
Sie können auch optional Binär- und Textanlagen zu einem Absturz oder einem nicht behandelten Ausnahmebericht hinzufügen. Das SDK sendet sie zusammen mit dem Bericht, sodass Sie sie im App Center-Portal anzeigen können. Der folgende Rückruf wird direkt vor dem Senden des gespeicherten Berichts aufgerufen. Bei Abstürze tritt dies beim nächsten Anwendungsstart auf. Bei nicht behandelten Ausnahmen müssen Sie sich für das Senden von Anlagen anmelden. 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 Bericht:
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")
};
};
Abstürze unterscheiden sich von nicht behandelten Ausnahmen in Berichten mit der IsCrash -Eigenschaft. Die Eigenschaft ist bei Abstürze true und andernfalls false.
Hinweis
Die Größenbegrenzung beträgt für Anlagen derzeit 7 MB. Der Versuch, eine größere Anlage zu senden, löst einen Fehler aus.
Hinweis
GetErrorAttachmentswird im Standard-Thread aufgerufen, und die Arbeit wird nicht über Frames aufgeteilt. Um das Blockieren der Spielschleife zu vermeiden, führen Sie in diesem Rückruf keine Aufgaben mit langer Ausführungszeit aus.
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, führt das SDK keine Absturzberichte für die App aus.
Crashes.SetEnabledAsync(false);
Um App Center-Abstürze erneut zu aktivieren, verwenden Sie dieselbe API, übergeben true Sie jedoch als Parameter.
Crashes.SetEnabledAsync(true);
Sie müssen nicht auf diesen Aufruf warten, um andere API-Aufrufe (z IsEnabledAsync. B. ) konsistent auszuführen.
Der Zustand wird über Anwendungsstarts hinweg im Speicher des Geräts beibehalten.
Überprüfen, ob App Center-Abstürze aktiviert ist
Sie können auch überprüfen, ob App Center-Abstürze aktiviert sind:
bool isEnabled = await Crashes.IsEnabledAsync();
Behandelte Ausnahmen in Unity
Mit App Center können Sie auch Fehler mithilfe von behandelten Ausnahmen in Unity nachverfolgen. Verwenden Sie dazu die TrackError -Methode:
try {
// your code goes here.
} catch (Exception exception) {
Crashes.TrackError(exception);
}
Für einen weiteren Kontext zu Ihrem Fehler können Sie auch Eigenschaften an ihn anfügen. Übergeben Sie die Eigenschaften als Wörterbuch von Zeichenfolgen. Dieser Schritt ist optional.
try {
// your code goes here.
} catch (Exception exception) {
var properties = new Dictionary<string, string>
{
{ "Category", "Music" },
{ "Wifi", "On" }
};
Crashes.TrackError(exception, properties);
}
Optional können Sie auch Binär- und Textanlagen zu einem behandelten Fehlerbericht hinzufügen. Übergeben Sie die Anlagen als Array von ErrorAttachmentLog Objekten, wie im folgenden Beispiel gezeigt.
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);
}
Nicht behandelte Ausnahmen in Unity
Melden von nicht behandelten Ausnahmen
Standardmäßig meldet das App Center SDK keine nicht behandelten Ausnahmen, die in Ihrer App ausgelöst werden und nicht zu einem schwerwiegenden Absturz führen. Um diese Funktionalität zu aktivieren, rufen Sie die folgende Methode auf:
Crashes.ReportUnhandledExceptions(true);
Nach dem Aufruf dieser API protokolliert App Center alle nicht behandelten Ausnahmen als Probleme im App Center-Portal, ähnlich wie zuvor erwähnte Ausnahmen. Um diese Funktionalität zu deaktivieren, rufen Sie dieselbe API auf, die den Parameter übergibt false .
Crashes.ReportUnhandledExceptions(false);
Hinweis
Einige nicht behandelte Ausnahmen, die vom App Center SDK erkannt wurden, werden auf der App Center-Benutzeroberfläche als Fehler angezeigt. Dies liegt daran, dass Unity standardmäßig nicht behandelte Ausnahmen abfängt, was bedeutet, dass die App nicht beendet wird und nicht als Absturz betrachtet wird.
Hinzufügen von Anlagen zu einem Nicht behandelten Ausnahmebericht
Standardmäßig aktiviert das App Center SDK keine Anlagen für nicht behandelte Ausnahmen. Um diese Funktionalität zu aktivieren, legen Sie den enableAttachmentsCallback booleschen Parameter der ReportUnhandledExceptions -Methode auf fest true:
Crashes.ReportUnhandledExceptions(true, true);
Anschließend können Sie optional Anlagen zu einem nicht behandelten Ausnahmebericht hinzufügen, indem Sie den GetErrorAttachments-Rückruf implementieren.
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
Als Nächstes müssen Sie Google Breakpad einschließen und kompilieren, indem Sie die Anweisungen in der offiziellen Infodatei zu Google Breakpad für Android befolgen. Um sie in Unity zu verwenden, schließen Sie die Binärdatei in Ihre App ein.
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 an:
/* Attach NDK Crash Handler. */
var minidumpDir = Crashes.GetMinidumpDirectoryAsync();
setupNativeCrashesListener(minidumpDir.Result);
...
[DllImport("YourLib")]
private static extern void setupNativeCrashesListener(string path);
Die -Methode setupNativeCrashesListener ist eine native Methode, die Sie in C/C++ implementieren müssen:
#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);
}
Wo dumpCallback wird für die Problembehandlung verwendet:
/*
* 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;
}
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 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.
Warnung
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 .