App Center bloqueos (Android)

App Center bloqueos generarán automáticamente un registro de bloqueos cada vez que se bloquea la aplicación. El registro se escribe primero en el almacenamiento del dispositivo y, cuando el usuario inicia de nuevo la aplicación, el informe de bloqueo se enviará a App Center. La recopilación de bloqueos funciona para las aplicaciones beta y en directo, es decir, las enviadas a Google Play. Los registros de bloqueo contienen información valiosa para ayudarle a corregir el bloqueo.

Siga la Tareas iniciales si aún no ha configurado el SDK en la aplicación.

Generación de un bloqueo de prueba

App Center crashes proporciona una API para generar un bloqueo de prueba para 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 bloqueo anterior

App Center bloqueos tiene dos API que le dan más información en caso de que la aplicación se haya estrellado.

¿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 esto en nuestra guía App Center API asincrónicas.

¿Se ha bloqueo la aplicación en la sesión anterior?

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

Crashes.hasCrashedInLastSession();

Crashes.hasCrashedInLastSession()

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

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 optaron por mostrar una interfaz de usuario adicional para lamentarse de sus usuarios, o quieren una manera de entrar en contacto después de que se haya producido un bloqueo.

Detalles sobre el último bloqueo

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

Crashes.getLastSessionCrashReport();

Crashes.getLastSessionCrashReport()

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

Hay numerosos casos de uso para esta API, el más común son las personas que llaman a esta API e implementan su CrashesListener personalizado.

Personalización del uso de App Center bloqueos

App Center crashes proporciona devoluciones de llamada para que los desarrolladores realicen acciones adicionales antes y al enviar registros de bloqueo a App Center.

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

Uso de su propio CrashesListener

Cree su propio CrashesListener y asígnelo de la siguiente 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 algunas de las devoluciones de llamada, use en su AbstractCrashesListener 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)

¿Se debe procesar el bloqueo?

Implemente esta devolución de llamada si desea decidir si es necesario procesar o no un bloqueo determinado. Por ejemplo, podría haber un bloqueo de nivel de sistema que le gustaría 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
}

Pedir el consentimiento del usuario para enviar un registro de bloqueos

Si la privacidad del usuario es importante para usted, es posible que desee obtener 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 bloqueos que esperen la confirmación del usuario antes de enviar los informes de bloqueo.

Si decide hacerlo, es responsable de obtener la confirmación del usuario, por ejemplo, a través de un símbolo del sistema de diálogo con una de las siguientes opciones: Enviar siempre, Enviar y No enviar. En función de la entrada, le dirá a App Center qué hacer y el bloqueo se controlará en consecuencia.

La devolución de llamada siguiente muestra cómo decir al SDK que espere la confirmación del usuario antes de enviar bloqueos:

@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 , la aplicación debe obtener (mediante su propio código) el permiso del usuario y enviar un mensaje al SDK con el resultado true 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)

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

Obtener información sobre el estado de envío de un registro de bloqueo

En ocasiones, quiere saber el estado del bloqueo de la aplicación. Un caso de uso común es que es posible que quiera 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 bloquea rápidamente después del inicio, quiere ajustar el comportamiento de la aplicación para asegurarse de que se pueden enviar los registros de bloqueo. App Center bloqueos tiene tres devoluciones de llamada diferentes que puede usar en la aplicación para recibir notificaciones de lo que sucede:

La devolución de llamada siguiente se invocará antes de que el SDK envíe un registro de bloqueo

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

Si tenemos problemas de red o una interrupción en el punto de conexión y reinicia la aplicación, se desencadena de onBeforeSending nuevo después del reinicio del proceso.

La devolución de llamada siguiente se invocará después de que el SDK haya enviado correctamente un registro de bloqueo.

@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á la devolución de llamada siguiente si el SDK no pudo enviar un registro de bloqueo

@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 significa que se ha producido un error no recuperable, como un código 4xx. Por ejemplo, 401 significa que appSecret es incorrecto.

Esta devolución de llamada no se desencadena si se trata de un problema de red. En este caso, el SDK sigue reintentar (y también pausa los reintentos mientras la conexión de red está sin conexión).

Agregar datos adjuntos a un informe de bloqueo

Puede agregar datos adjuntos binarios y de texto a un informe de bloqueo. El SDK los enviará junto con el bloqueo para que pueda verlos en App Center portal. La devolución de llamada siguiente se invocará justo antes de enviar el bloqueo almacenado desde inicios de aplicación anteriores. No se invocará cuando se produce el bloqueo. Asegúrese de que el archivo adjunto no tiene nombre, minidump.dmp ya que ese nombre está reservado para los archivos de minivolfón. 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)
}

Habilitación o deshabilitación App Center bloqueos en tiempo de ejecución

Puede habilitar y deshabilitar los bloqueos App Center en tiempo de ejecución. Si lo deshabilita, el SDK no hará ningún informe de bloqueo para la aplicación.

Crashes.setEnabled(false);

Crashes.setEnabled(false)

Para habilitar App Center bloqueos 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 esto en nuestra guía App Center API asincrónicas.

Comprobación de si App Center bloqueos está habilitado

También puede comprobar si App Center bloqueos está habilitado o no:

Crashes.isEnabled();

Crashes.isEnabled()

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

Errores manipulados

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 manipulado para proporcionar contexto adicional. 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)
}

Opcionalmente, también puede agregar datos adjuntos binarios y de texto a un informe de errores manipulado. Pase los datos adjuntos 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 bloqueos

Para recibir informes de bloqueo adecuados en App Center, primero asegúrese de que tiene configurado el SDK de bloqueos de App Center siguiendo las instrucciones indicadas anteriormente.

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

A continuación, incluya y compile Google Breakpad siguiendo las instrucciones que aparecen en el archivo LÉAME oficial de Google Breakpad para Android.

Adjuntar el controlador de excepciones

Una vez incluido Google Breakpad, adjunte el controlador de bloqueo de NDK después de 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);
        }
    }
});

El método setupNativeCrashesListener es un método nativo que 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 que estos métodos se han configurado correctamente, la aplicación envía el minivolumen para App Center automáticamente al reiniciar. Para solucionar problemas, puede usar registros detallados ( antes de ) para comprobar si AppCenter.setLogLevel(Log.VERBOSE) se envían minivolúmenes después de reiniciar AppCenter.start la aplicación.

Simbólico

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