Bloqueos de App Center (Android)

Cada vez que tu aplicación se bloquee, la función Crashes de App Center generará automáticamente un registro de bloqueos. El registro se escribe primero en el almacenamiento del dispositivo y, cuando el usuario vuelve a iniciar la aplicación, el informe de bloqueo se enviará a App Center. La recopilación de fallos funciona tanto para aplicaciones beta como para aplicaciones en directo, incluyendo aquellas enviadas a Google Play. Los registros de fallos contienen información valiosa que puede ayudarle a corregir el fallo.

Siga la sección Introducción si aún no ha configurado el SDK en 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 solo se puede usar en compilaciones de depuración y no hará nada en las compilaciones de versión.

Crashes.generateTestCrash();

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:

Crashes.hasReceivedMemoryWarningInLastSession();

Crashes.hasReceivedMemoryWarningInLastSession()

Esta API es asincrónica, puede leer más sobre eso en nuestra guía de API asincrónicas de App Center .

¿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:

Crashes.hasCrashedInLastSession();

Crashes.hasCrashedInLastSession()

Esta API es asincrónica, puede leer más sobre eso en nuestra guía de API asincrónicas de App Center .

Esto resulta útil en caso de que quiera ajustar el comportamiento o la interfaz de usuario de la aplicación después de que se haya producido un bloqueo. Algunos desarrolladores optan por mostrar una interfaz de usuario adicional para disculparse con sus usuarios o quieren tener una manera de ponerse en contacto tras un bloqueo.

Detalles sobre el último fallo

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

Crashes.getLastSessionCrashReport();

Crashes.getLastSessionCrashReport()

Esta API es asincrónica, puede leer más sobre eso en nuestra guía de API asincrónicas de App Center .

Hay numerosos casos de uso para esta API, el más común es la gente que llama a esta API e implementa su crashesListener personalizado.

Personaliza tu uso de fallos de App Center

App Center Crashes proporciona callbacks para que los desarrolladores puedan realizar acciones adicionales antes y durante el envío de registros de incidencias a App Center.

Para controlar las devoluciones de llamada, implemente todos los métodos de la CrashesListener interfaz, o invalide la AbstractCrashesListener clase y elija solo las que le interesen.

Utiliza tu propio CrashesListener

Cree su propio CrashesListener y asígnelo de esta manera:

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

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

En caso de que solo le interese personalizar algunos de los callbacks, use el AbstractCrashesListener en su lugar.

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)

¿Debe procesarse el fallo?

Implemente este callback para decidir si es necesario procesar o no un bloqueo determinado. Por ejemplo, podría haber un bloqueo a nivel del sistema que prefiera omitir y que no desea enviar a App Center.

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

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 decide hacerlo, es responsable de obtener la confirmación del usuario, por ejemplo, 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 entrada, indicará a App Center qué hacer y, a continuación, se controlará el bloqueo 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.

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

Si devuelve true, la aplicación debe obtener (con su propio código) 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(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)

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 que es posible que quieras mostrar la interfaz de usuario que indica a los usuarios que la aplicación envía un informe de bloqueo o, en caso de que la aplicación se bloquee rápidamente después del inicio, quieres ajustar el comportamiento de la aplicación para asegurarte de que se pueden enviar los registros de bloqueo. Los bloqueos de App Center tienen tres devoluciones de llamada diferentes que puedes usar en la aplicación para recibir una notificación de lo que sucede:

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

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

En caso de que tengamos problemas de red o una interrupción en el punto de conexión y reinicie la aplicación, onBeforeSending 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.

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

Se invocará el siguiente callback si el SDK no pudo enviar un informe de error.

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

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

Recibir onSendingFailed 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).

Agregar datos adjuntos a un informe de fallos

Puede agregar datos adjuntos binarios y de texto a un informe de errores. El SDK los enviará junto con el fallo para que pueda verlos en el portal de App Center. La siguiente devolución de llamada se invocará justo antes de enviar la falla almacenada de lanzamientos de aplicaciones anteriores. No se invocará cuando se produzca el fallo. 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 bloqueo:

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

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 lo desactivas, el SDK no generará ningún informe de errores para la app.

Crashes.setEnabled(false);

Crashes.setEnabled(false)

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

Crashes.setEnabled(true);

Crashes.setEnabled(true)

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

Esta API es asincrónica, puede leer más sobre eso en nuestra guía de API asincrónicas de App Center .

Comprueba si los bloqueos de App Center están habilitados

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

Crashes.isEnabled();

Crashes.isEnabled()

Esta API es asincrónica, puede leer más sobre eso en nuestra guía de API asincrónicas de App Center .

Errores controlados

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

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

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

Opcionalmente, una aplicación puede adjuntar propiedades a un informe de errores controlado para proporcionar más contexto. Pase las propiedades como un mapa de pares clave-valor (solo cadenas) como se muestra en el ejemplo siguiente.

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

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 como Iterable se muestra en el ejemplo siguiente.

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

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, incluya y compile Google Breakpad siguiendo las instrucciones enumeradas en el archivo Léame oficial de Google Breakpad para Android.

Conexión del controlador de excepciones

Una vez que haya incluido Google Breakpad, adjunte el controlador de bloqueo de NDK después AppCenter.startde :

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

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

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

Dónde dumpCallback se usa para solucionar problemas:

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

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 (AppCenter.setLogLevel(Log.VERBOSE) antes AppCenter.start) para comprobar si se envían minidumps después de que se reinicie la aplicación.

Simbicación

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