Freigeben über


App Center stürzt ab (Unity)

Von Bedeutung

Visual Studio App Center wurde am 31. März 2025 eingestellt, mit Ausnahme der Analyse- und Diagnosefeatures, die bis zum 30. Juni 2026 weiterhin unterstützt werden. Weitere Informationen

App Center Crashes erstellt automatisch jedes Mal ein Absturzprotokoll, wenn Ihre App abstürzt, und speichert das Protokoll im Gerätespeicher. Wenn ein Benutzer die App erneut startet, sendet das SDK den Absturzbericht an Das App Center. Das Sammeln von Abstürzen funktioniert sowohl für Beta- als auch für Live-Apps, d. h. Abstürze, die an Google Play übermittelt wurden. Absturzprotokolle enthalten wertvolle Informationen für Sie, um den Absturz zu beheben.

Folgen Sie den Anweisungen im Abschnitt "Erste Schritte mit Unity ", wenn Sie das SDK noch nicht in Ihrer Anwendung eingerichtet haben.

Absturzberichte auf iOS müssen symbolisiert werden. 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.

Von Bedeutung

Das Crashes SDK für Unity unterstützt UWP nicht. Die Anweisungen auf dieser Seite decken nur Android und iOS ab.

Hinweis

Das SDK leitet keine Absturzprotokolle weiter, wenn Sie den Debugger angefügt haben. Stellen Sie sicher, dass der Debugger beim Abstürzen der App nicht verbunden ist.

Hinweis

Wenn Sie Enable CrashReport API in PlayerSettings aktiviert haben, sammelt das SDK keine Absturzprotokolle.

Generieren eines Testabsturzes

App Center Crashes bietet Ihnen eine API zum Generieren eines Testabsturzes für einfache Tests des SDK. Diese API sucht nach Debug- und Releasekonfigurationen. Sie können es also nur verwenden, wenn Sie debuggen, da es nicht für release-Apps funktioniert.

Crashes.GenerateTestCrash();

Hinweis

Diese Methode funktioniert nur mit der aktivierten Entwicklungsbuild-Einstellung.

Abrufen weiterer Informationen zu einem vorherigen Absturz

App Center Crashes bietet zwei APIs, mit denen Sie weitere Informationen erhalten, falls Ihre App abgestürzt ist.

Hat die App in der vorherigen Sitzung eine Warnung mit geringem 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 geringem Arbeitsspeicher keine Ereignisse senden.

Stürzte die App in der vorherigen Sitzung ab?

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 zusätzliche Benutzeroberflächen an, um sich bei ihren Benutzern zu entschuldigen oder nach einem Absturz Kontakt aufzunehmen.

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.

Passen Sie die Nutzung von App Center Crashes an.

App Center Crashes bietet Entwicklern Callback-Funktionen, um zusätzliche Aktionen zu ergreifen, bevor sie Absturzprotokolle an App Center senden und wenn sie dies tun.

Hinweis

Legen Sie den Rückruf vor dem Start von App Center fest, beispielsweise in der Awake-Methode, da App Center die Verarbeitung von Abstürzen sofort 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. Es könnte z. B. ein Absturz auf Systemebene geben, den Sie ignorieren und nicht an das 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;
};

Wenn Ihnen der Datenschutz des Benutzers wichtig ist, sollten Sie die Benutzerbestätigung erhalten, bevor Sie einen Absturzbericht an das App Center senden. Das SDK stellt eine Callback-Funktion bereit, die App Center Crashes angewiesen ist, auf die Bestätigung des Benutzers zu warten, 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 aus einer Dialogfeldaufforderung mit einer der folgenden Optionen: "Immer senden", " Senden" und "Nicht senden". Basierend auf der Eingabe teilen Sie dem App Center mit, was zu tun ist, und der Absturz wird dann entsprechend behandelt.

Hinweis

Das SDK zeigt hierfü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 Sie dem SDK mitteilen, dass vor dem Senden von Abstürze auf die Benutzerbestätigung gewartet wird:

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 true zurückgibt, müssen Sie die Benutzerberechtigung einholen und das SDK mit dem Ergebnis mithilfe der folgenden API benachrichtigen.

// 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 auf unser benutzerdefiniertes Dialogfeldbeispiel verweisen.

Abrufen von Informationen zum Sendestatus für ein Absturzprotokoll

Manchmal möchten Sie den Status ihres App-Absturzes kennen. Ein gängiger Anwendungsfall zeigt eine Benutzeroberfläche an, die den Benutzer darüber informiert, dass die App einen Absturzbericht übermittelt. Ein weiteres 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 Crashes bietet drei verschiedene Rückrufe, die Sie darüber benachrichtigen, was passiert ist.

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

FailedToSendErrorReport Der Empfang bedeutet, dass ein nicht wiederherstellbarer Fehler wie z. B. ein 4xx-Code aufgetreten ist. Beispielsweise bedeutet 401, dass das appSecret falsch ist.

Dieser Rückruf wird nicht ausgelöst, wenn es sich um ein Netzwerkproblem handelt. In diesem Fall führt das SDK fortlaufend Wiederholungen durch (und unterbricht diese, während die Netzwerkverbindung unterbrochen ist).

Anlagen zu einem Absturz oder einem unbehandelten Ausnahmebericht hinzufügen

Sie können optional Binär- und Textanlagen zu einem Absturzbericht oder einem Bericht über eine unbehandelte Ausnahme hinzufügen. Das SDK sendet sie zusammen mit dem Bericht, damit Sie sie im App Center-Portal sehen können. Der folgende Rückruf wird direkt vor dem Senden des gespeicherten Berichts aufgerufen. Bei Abstürzen geschieht dies beim nächsten Öffnen der Anwendung. Bei unbehandelten Ausnahmen müssen Sie sich für das Senden von Anlagen anmelden. Stellen Sie sicher, dass die Anlagendatei nichtminidump.dmp genannt wird, da dieser Name für Minidumpdateien reserviert ist. Hier ist 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 werden in Berichten durch das IsCrash Attribut von unbehandelten Ausnahmen unterschieden. Die Eigenschaft wird für Abstürze wahr sein und andernfalls falsch.

Hinweis

Das Größenlimit für Anhänge beträgt derzeit 7 MB. Beim Versuch, eine größere Anlage zu senden, wird ein Fehler ausgelöst.

Hinweis

GetErrorAttachments wird im Hauptthread aufgerufen und teilt keine Arbeit über Frames auf. Um das Blockieren der Spielschleife zu vermeiden, führen Sie in diesem Rückruf keine zeitintensiven Aufgaben aus.

Aktivieren oder Deaktivieren von App Center-Abstürzen 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 durch.

Crashes.SetEnabledAsync(false);

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

Crashes.SetEnabledAsync(true);

Sie müssen diesen Aufruf nicht warten, um andere API-Aufrufe (z IsEnabledAsync. B. ) konsistent zu machen.

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

Überprüfen, ob App Center Crashes aktiviert ist

Sie können auch überprüfen, ob App Center Crashes aktiviert ist.

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

Sie können einem behandelten Fehlerbericht optional auch Binäre und Textanlagen hinzufügen. Übergeben Sie die Anhänge 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);
}

Unbehandelte Ausnahmen in Unity

Unbehandelte Ausnahmen melden

Standardmäßig meldet das App Center SDK keine unbehandelten Ausnahmen, die in Ihrer App ausgelöst werden, die keinen schwerwiegenden Absturz verursachen. Rufen Sie die folgende Methode auf, um diese Funktionalität zu aktivieren:

Crashes.ReportUnhandledExceptions(true);

Nach dem Aufrufen dieser API protokolliert App Center alle unbehandelten Ausnahmen als Probleme im App Center-Portal, ähnlich wie bei zuvor erwähnten Ausnahmen. Um diese Funktionalität zu deaktivieren, rufen Sie die gleiche API-Übergabe false wie der Parameter auf.

Crashes.ReportUnhandledExceptions(false);

Hinweis

Einige unbehandelte Ausnahmen, die vom App Center SDK erkannt wurden, werden als Fehler in der App Center-Benutzeroberfläche angezeigt. Dies liegt daran, dass Unity standardmäßig unbehandelte Ausnahmen abfangt, was bedeutet, dass die App nicht beendet wird und nicht als Absturz betrachtet wird.

Hinzufügen von Anlagen zu einem unbehandelten Ausnahmebericht

Standardmäßig aktiviert das App Center SDK keine Anhänge bei nicht behandelten Ausnahmen. Um diese Funktionalität zu aktivieren, legen Sie den enableAttachmentsCallback booleschen Parameter der ReportUnhandledExceptions Methode auf :true

Crashes.ReportUnhandledExceptions(true, true);

Anschließend können Sie einem unbehandelten Ausnahmebericht optional Anlagen hinzufügen, indem Sie den GetErrorAttachments-Rückruf implementieren.

Melden von NDK-Abstürze

Melden von Abstürze

Um ordnungsgemäße Absturzberichte im App Center zu erhalten, stellen Sie zunächst sicher, dass das App Center Crashes SDK eingerichtet ist, indem Sie den oben aufgeführten Anweisungen folgen.

Erstellen der Breakpad-Bibliothek

Als Nächstes müssen Sie Google Breakpad einschließen und kompilieren, indem Sie den Anweisungen folgen, die im offiziellen Google Breakpad für Android README aufgeführt sind. 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 nicht standardmäßig.

Anfügen des Ausnahmehandlers

Nachdem Sie Google Breakpad eingebunden haben, binden Sie den NDK Crash Handler ein.

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

Sobald diese Methoden ordnungsgemäß eingerichtet wurden, sendet die App den Minidump automatisch beim Neustart an App Center. Zur Problembehandlung können Sie ausführliche Protokolle verwenden, um zu überprüfen, ob Minidumps gesendet werden, nachdem die App neu gestartet wurde.

Hinweis

App Center verwendet den reservierten Namen minidump.dmp für Minidump-Anhänge. 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 im 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 .