Fallos de App Center (Unity)

Los registros de bloqueos de App Center se generan automáticamente cada vez que la aplicación se bloquea, y estos registros se guardan en el almacenamiento del dispositivo. Cuando un usuario vuelve a iniciar la aplicación, el SDK envía el informe de bloqueo a App Center. La recopilación de errores funciona tanto en aplicaciones beta como en aplicaciones en funcionamiento, es decir, errores enviados a Google Play. Los registros de fallos contienen información valiosa que puede ayudarle a corregir el fallo.

Siga las instrucciones de la sección Introducción a Unity si aún no ha configurado el SDK en la aplicación.

Los registros de bloqueo en iOS requieren la simbolización. Para habilitar la simbólica, consulte la documentación de Diagnósticos de App Center, que explica cómo proporcionar símbolos para la aplicación.

Generar un bloqueo de prueba

App Center Crashes proporciona una API para generar una falla de prueba y facilitar las pruebas del SDK. Esta API comprueba las configuraciones de depuración vs lanzamiento. Por lo tanto, solo puede usarlo al depurar, porque no funcionará en aplicaciones de producción.

Crashes.GenerateTestCrash();

Obtener más información sobre un fallo anterior

Las fallas de App Center tienen dos APIs que proporcionan más información en caso de que su aplicación se bloquee.

¿La aplicación recibió una advertencia de memoria baja en la sesión anterior?

En cualquier momento después de iniciar el SDK, puede comprobar si la aplicación recibió una advertencia de memoria en la sesión anterior:

bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;

¿Se bloqueó la aplicación en la sesión anterior?

En cualquier momento después de iniciar el SDK, puede comprobar si la aplicación se bloqueó en el inicio anterior:

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

Llamar HasCrashedInLastSessionAsync es útil si desea ajustar el comportamiento o la interfaz de usuario de la aplicación después de que se haya producido un fallo. Algunos desarrolladores muestran una interfaz de usuario adicional para disculparse a sus usuarios o quieren ponerse en contacto después de que se haya producido un bloqueo.

Detalles sobre el último fallo

Si la aplicación se bloqueó anteriormente, puede obtener detalles sobre el último bloqueo.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

El caso de uso más común para esta API es cuando un usuario implementa su delegado o agente de escucha personalizado para bloqueos.

Personaliza tu uso de fallos de App Center

App Center Crashes proporciona llamadas de retorno para que los desarrolladores realicen acciones adicionales antes de enviar y al enviar registros de bloqueo a App Center.

¿Debe procesarse el fallo?

Establezca la siguiente devolución de llamada si desea decidir si se debe procesar o no un fallo determinado. Por ejemplo, podría haber un error a nivel del sistema que quiera ignorar y no enviar a App Center.

Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
     // Check the report in here and return true or false depending on the ErrorReport.
    return true;
};

Solicitar el permiso del usuario para enviar un registro de errores

Si la privacidad del usuario es importante para ti, es posible que quieras recibir la confirmación del usuario antes de enviar un informe de bloqueo a App Center. El SDK expone una devolución de llamada que indica a App Center Crashes que espere la confirmación del usuario antes de enviar los informes de bloqueos.

Si su código utiliza esta devolución de llamada, usted es responsable de asegurarse de obtener la confirmación del usuario. Una opción es a través de un mensaje de diálogo con una de las siguientes opciones: Enviar siempre, Enviar y No enviar. En función de la información de entrada, instruirás a App Center Crashes sobre qué hacer y, a continuación, se gestionará el fallo en consecuencia.

La siguiente función de callback muestra cómo indicar al SDK que espere la confirmación del usuario antes de enviar errores.

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

Si el callback devuelve true, debe obtener el permiso del usuario y enviar un mensaje al SDK con el resultado mediante la siguiente API:

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

Como ejemplo, puede hacer referencia a nuestro ejemplo de diálogo personalizado.

Obtener información sobre el estado de envío de un informe de bloqueos

En ocasiones, quieres conocer el estado del bloqueo de la aplicación. Un caso de uso común es mostrar una interfaz de usuario que informa al usuario de que la aplicación está enviando un informe de fallos. Otro escenario es cuando desea ajustar el comportamiento de la aplicación para asegurarse de que los informes de fallos se puedan enviar inmediatamente después del reinicio. Proporciona tres tipos de funciones de retorno con las que puede obtener notificaciones sobre lo que ha ocurrido.

Se invocará la siguiente devolución de llamada antes de que el SDK envíe un informe de errores.

Crashes.SendingErrorReport += (errorReport) =>
{
    // Your code, e.g. to present a custom UI.
};

En caso de que tengamos problemas de red o una interrupción en el punto de conexión y reinicie la aplicación, SendingErrorReport se desencadena de nuevo después del reinicio del proceso.

La siguiente función de retorno se invocará después de que el SDK envíe correctamente un informe de bloqueos.

Crashes.SentErrorReport += (errorReport) =>
{
    // Your code, e.g. to hide the custom UI.
};

Se invocará la siguiente devolución de llamada si el SDK no pudo enviar un informe de fallos.

Crashes.FailedToSendErrorReport += (errorReport, exception) =>
{
    // Your code goes here.
};

Recibir FailedToSendErrorReport implica que se ha producido un error no recuperable, como puede ser un código 4xx. Por ejemplo, 401 significa que el appSecret está incorrecto.

Esta callback no se desencadena en caso de un problema de red. En este caso, el SDK sigue reintentando (y también pausa los reintentos mientras la conexión de red está inactiva).

Añadir datos adjuntos a un error o a un informe de excepciones no controladas

También puede agregar opcionalmente archivos adjuntos binarios y de texto a un informe de bloqueo o de excepción no controlada. El SDK los enviará junto con el informe para que pueda verlos en el portal de App Center. La siguiente devolución de llamada se invocará justo antes de enviar el informe almacenado. Para los bloqueos se produce en el siguiente inicio de la aplicación. Para las excepciones no controladas, debe optar por enviar datos adjuntos. Asegúrese de que el archivo adjunto no tiene nombre minidump.dmp , ya que ese nombre está reservado para los archivos minivolcados. Este es un ejemplo de cómo adjuntar texto y una imagen a un informe:

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

Los fallos se distinguen de las excepciones no controladas en los informes con la propiedad IsCrash. La propiedad será verdadera para bloqueos y falsa en caso contrario.

Habilitar o deshabilitar App Center Crashes en tiempo de ejecución

Puede habilitar y deshabilitar bloqueos de App Center en tiempo de ejecución. Si la deshabilita, el SDK no realizará ningún informe de fallos para la app.

Crashes.SetEnabledAsync(false);

Para habilitar los bloqueos de App Center de nuevo, use la misma API, pero pase true como parámetro.

Crashes.SetEnabledAsync(true);

No es necesario esperar esta llamada para que otras llamadas API (como IsEnabledAsync) sean coherentes.

El estado se conserva en el almacenamiento del dispositivo en los inicios de la aplicación.

Comprueba si los bloqueos de App Center están habilitados

También puede comprobar si los bloqueos de App Center están habilitados:

bool isEnabled = await Crashes.IsEnabledAsync();

Excepciones controladas en Unity

App Center también permite realizar un seguimiento de los errores mediante excepciones controladas en Unity. Para ello, use el TrackError método :

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

Para obtener más contexto sobre el error, también puede adjuntar propiedades al error. Pase las propiedades como un diccionario de cadenas. Este paso es opcional.

try {
    // your code goes here.
} catch (Exception exception) {
    var properties = new Dictionary<string, string>
    {
        { "Category", "Music" },
        { "Wifi", "On" }
    };
    Crashes.TrackError(exception, properties);
}

También tiene la opción de agregar archivos adjuntos binarios y de texto a un informe de errores controlado. Pase los datos adjuntos como una matriz de ErrorAttachmentLog objetos como se muestra en el ejemplo siguiente.

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

Excepciones no controladas en Unity

Notificar excepciones no controladas

De forma predeterminada, el SDK de App Center no informa sobre excepciones no controladas que ocurren en tu aplicación y que no provocan un fallo fatal. Para habilitar esta funcionalidad, llame al método siguiente:

Crashes.ReportUnhandledExceptions(true);

Después de llamar a esta API, App Center registra todas las excepciones no controladas como Problemas en el portal de App Center, de forma similar a las excepciones controladas mencionadas anteriormente. Para deshabilitar esta funcionalidad, llame a la misma API pasando false como parámetro.

Crashes.ReportUnhandledExceptions(false);

Agregar datos adjuntos a un informe de excepciones no controladas

De forma predeterminada, el SDK de App Center no habilita los datos adjuntos en excepciones no controladas. Para habilitar esta funcionalidad, establezca el enableAttachmentsCallback parámetro booleano del ReportUnhandledExceptions método en true:

Crashes.ReportUnhandledExceptions(true, true);

A continuación, puede opcionalmente agregar datos adjuntos a un informe de excepciones no controladas mediante la implementación de la devolución de llamada GetErrorAttachments.

Informes de bloqueos de NDK

Informes de fallos

Para recibir informes de fallos apropiados en App Center, primero asegúrese de tener configurado el SDK de fallos de App Center siguiendo las instrucciones indicadas arriba.

Creación de la biblioteca del panel de interrupción

A continuación, debes incluir y compilar Google Breakpad siguiendo las instrucciones indicadas en el archivo Léame oficial de Google Breakpad para Android. Para usarlo en Unity, incluya el binario con la aplicación.

Conexión del controlador de excepciones

Una vez que haya incluido Google Breakpad, adjunte el manejador de fallos de NDK.

/* Attach NDK Crash Handler. */
var minidumpDir = Crashes.GetMinidumpDirectoryAsync();
setupNativeCrashesListener(minidumpDir.Result);

...

[DllImport("YourLib")]
private static extern void setupNativeCrashesListener(string path);

El método setupNativeCrashesListener es un método nativo que se debe implementar en C/C++.

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

Dónde dumpCallback se usa para solucionar problemas:

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

Una vez configurados correctamente estos métodos, la aplicación envía el minivolcado a App Center automáticamente tras reiniciarse. Para solucionar problemas, puede usar registros detallados para comprobar si se envían minivolcados después de reiniciar la aplicación.

Simbicación

Consulte la documentación sobre diagnósticos para obtener más información sobre el procesamiento de fallos.