Compartir a través de

Errores de App Center (React Native)

Importante

Visual Studio App Center se retiró el 31 de marzo de 2025, excepto las características de análisis y diagnóstico, que seguirán siendo compatibles hasta el 30 de junio de 2026. Más información.

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.

Cuando esté usando App Center Crashes, agregue la siguiente línea de importación en la parte superior del archivo.

// Import App Center Crashes at the top of the file.
import Crashes from 'appcenter-crashes';

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 aplicaciones de prueba o beta y no hará nada en aplicaciones de producción.

Crashes.generateTestCrash();

También es fácil generar un fallo de JavaScript. Agregue la siguiente línea al código, que produce un error de JavaScript y provoca un bloqueo.

throw new Error('This is a test javascript crash!');

Sugerencia

La aplicación React Native debe compilarse en modo de lanzamiento para que se envíe este fallo a App Center.

Nota:

En este momento, App Center no admite mapas de origen para desofuscar los rastros de pila de JavaScript para aplicaciones de React Native para Android.

Nota:

Es recomendable evitar la instrucción JavaScript throw con un valor de cadena (por ejemplo, throw 'message'), ya que en este escenario React Native no conserva la pila completa de JavaScript. En su lugar, throw un JavaScript Error (por ejemplo: throw Error('message')).

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:

const hadLowMemoryWarning = await Crashes.hasReceivedMemoryWarningInLastSession();

Nota:

En algunos casos, es posible que un dispositivo con poca memoria no envíe eventos.

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

const didCrash = await Crashes.hasCrashedInLastSession();

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.

const crashReport = await Crashes.lastSessionCrashReport();

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.

Procesamiento de fallos en JavaScript

Para que los Crash.setListener métodos funcionen según lo previsto, debe comprobar si la aplicación se ha configurado correctamente.

  1. Abra el archivo del ios/YourAppName/AppDelegate.m proyecto y compruebe que tiene [AppCenterReactNativeCrashes register]; en lugar de [AppCenterReactNativeCrashes registerWithAutomaticProcessing];.
  2. Abra el archivo android/app/src/main/res/values/strings.xml del proyecto y compruebe que appCenterCrashes_whenToSendCrashes esté establecido en ASK_JAVASCRIPT.

Todas las diferentes callbacks del listener de eventos se discuten una por una en este documento, pero debes configurar un listener de eventos que defina todas las callbacks a la vez.

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

Crashes.setListener({

    shouldProcess: function (report) {
        return true; // return true if the crash report should be processed, otherwise false.
    },

    // Other callbacks must also be defined at the same time if used.
    // Default values are used if a method with return parameter isn't defined.
});

Nota:

Para usar esa característica, debe configurar correctamente la aplicación para el servicio de fallos.

Esta característica depende de los bloqueos de procesamiento en JavaScript.

Si la privacidad del usuario es importante para usted, debe obtener la confirmación del usuario antes de enviar un informe de fallo 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.

Nota:

El SDK no muestra un cuadro de diálogo para esto, la aplicación debe proporcionar su propia interfaz de usuario para solicitar el consentimiento del usuario.

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

Crashes.setListener({

    shouldAwaitUserConfirmation: function (report) {

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

    // Other callbacks must also be defined at the same time if used.
    // Default values are used if a method with return parameter isn't defined.
});

Si devuelve true, la aplicación debe obtener (con su propio código) el permiso del usuario y actualizar el SDK con el resultado mediante la SIGUIENTE API:

import Crashes, { UserConfirmation } from 'appcenter-crashes';

// Depending on the user's choice, call Crashes.notifyUserConfirmation() with the right value.
Crashes.notifyUserConfirmation(UserConfirmation.DONT_SEND);
Crashes.notifyUserConfirmation(UserConfirmation.SEND);
Crashes.notifyUserConfirmation(UserConfirmation.ALWAYS_SEND);

Nota:

Para usar esta característica, configure la aplicación correctamente para el servicio Crash. La característica depende de los bloqueos de procesamiento en JavaScript.

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 fallos de App Center tienen tres diferentes devoluciones de llamada que puedes usar en tu aplicación para recibir notificaciones de lo que está ocurriendo.

Para ello, defina un agente de escucha de eventos en el código como se muestra en el ejemplo siguiente:

Crashes.setListener({
    onBeforeSending: function (report) {
        // called after Crashes.process and before sending the crash.
    },
    onSendingSucceeded: function (report) {
        // called when crash report sent successfully.
    },
    onSendingFailed: function (report) {
        // called when crash report couldn't be sent.
    }

    // Other callbacks must also be defined at the same time if used.
    // Default values are used if a method with return parameter isn't defined.
});

Todas las devoluciones de llamada son opcionales. No es necesario proporcionar los tres métodos en el objeto de escucha de eventos, por ejemplo, puede implementar solo onBeforeSending.

Nota:

Para usar esa característica, debe configurar correctamente la aplicación para el servicio de fallos.

Esta característica depende de los bloqueos de procesamiento en JavaScript.

Nota:

Si Crashes.setListener se llama más de una vez, el último gana; anula a las escuchas que se habían establecido previamente por Crashes.setListener.

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

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. El siguiente callback se invoca justo antes de enviar el fallo del almacenamiento desde los 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 una falla.

import Crashes, { ErrorAttachmentLog } from 'appcenter-crashes';

Crashes.setListener({
    getErrorAttachments(report) {
        const textAttachment = ErrorAttachmentLog.attachmentWithText('Hello text attachment!', 'hello.txt');
        const binaryAttachment = ErrorAttachmentLog.attachmentWithBinary(`${imageAsBase64string}`, 'logo.png', 'image/png');
        return [textAttachment, binaryAttachment];
    }

    // Other callbacks must also be defined at the same time if used.
    // Default values are used if a method with return parameter isn't defined.
});

El fileName parámetro es opcional (puede ser null) y solo se usa en el portal de App Center. Desde una incidencia de bloqueo específica en el portal, puede ver los archivos adjuntos y descargarlos. Si especificó un nombre de archivo, será el nombre de archivo que se va a descargar; de lo contrario, se generará el nombre de archivo automáticamente.

Para configurar el getErrorAttachments callback para que funcione con funciones asincrónicas utilizando async/await de ES2017, devuelva una Promesa cumplida en lugar de una promesa completada. En el ejemplo siguiente se adjunta un texto y una imagen a un fallo de forma asincrónica.

import Crashes, { ErrorAttachmentLog } from 'appcenter-crashes';

Crashes.setListener({
    getErrorAttachments(report) {
        return (async () => {
            const textContent = await readTextFileAsync(); // use your async function to read text file
            const binaryContent = await readBinaryFileAsync(); // use your async function to read binary file
            const textAttachment = ErrorAttachmentLog.attachmentWithText(textContent, 'hello.txt');
            const binaryAttachment = ErrorAttachmentLog.attachmentWithBinary(binaryContent, 'logo.png', 'image/png');
            return [textAttachment, binaryAttachment];
        })();
    }

    // Other callbacks must also be defined at the same time if used.
    // Default values are used if a method with return parameter isn't defined.
});

Nota:

Para usar esa característica, debe configurar correctamente la aplicación para el servicio de fallos.

Esta característica depende de los bloqueos de procesamiento en JavaScript.

Nota:

El límite de tamaño es actualmente de 1,4 MB en Android y 7 MB en iOS. Si intenta enviar datos adjuntos más grandes, se producirá un error.

Errores controlados

App Center también permite realizar un seguimiento de los errores mediante el uso de excepciones controladas a través del trackError método . Opcionalmente, una aplicación puede adjuntar propiedades o datos adjuntos a un informe de errores controlado para proporcionar más contexto.

try {
    // Throw error.
} catch (error) {

    // Prepare properties.
    const properties = { 'Category' : 'Music', 'Wifi' : 'On' };

    // Prepare attachments.
    const textAttachment = ErrorAttachmentLog.attachmentWithText('Hello text attachment!', 'hello.txt');
    const attachments = [textAttachment];

    // Create an exception model from error.
    const exceptionModel1 = ExceptionModel.createFromError(error);

    // ..or generate with your own error data.
    const exceptionModel2 = ExceptionModel.createFromTypeAndMessage("type", "message", "stacktrace");

    // Track error with custom data.
    Crashes.trackError(exceptionModel1, properties, attachments);
    Crashes.trackError(exceptionModel1, properties, nil);
    Crashes.trackError(exceptionModel2, nil, attachments);
    Crashes.trackError(exceptionModel2, nil, nil);
}

Breakpad

App Center soporta los bloqueos de Breakpad procedentes de Android NDK en aplicaciones de React Native.

Siga los pasos de configuración normales anteriores y, invalidando MainActivity.java, agregue la configuración de minidump y llame al código nativo que establece la configuración del Breakpad.

Ejemplo:

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Crashes.getMinidumpDirectory().thenAccept(new AppCenterConsumer<String>() {
      @Override
      public void accept(String path) {
        // Path is null when Crashes is disabled.
        if (path != null) {
          // links to NDK
          setupBreakpadListener(path);
        }
      }
    });
  }

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.

await Crashes.setEnabled(false);

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

await Crashes.setEnabled(true);

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 o no:

const enabled = await Crashes.isEnabled();