Preguntas frecuentes y solución de problemas de Crashlytics

Es posible que observes dos formatos diferentes de problemas que aparecen en la tabla de Problemas de Firebase console. También es posible que veas una función llamada “variantes” en algunos de tus problemas. Estas son las razones.

A principios de 2023, lanzamos un motor de análisis mejorado para agrupar eventos, un diseño actualizado y algunas funciones avanzadas para problemas nuevos (como las variantes). Consulta nuestra entrada de blog reciente para obtener todos los detalles. También puedes leer la siguiente información si quieres conocer los aspectos más destacados.

Crashlytics analiza todos los eventos de tu app (como fallas, errores recuperables y ANR) y crea grupos de eventos llamados problemas. Todos los eventos en un problema tienen un punto común de falla.

Para agrupar los eventos en estos problemas, el motor de análisis mejorado ahora analiza muchos aspectos de cada evento, incluidos los fotogramas del seguimiento de pila, el mensaje de excepción, el código de error y otras características de los tipos de errores o las plataformas.

Sin embargo, incluso dentro de este grupo de eventos, los seguimientos de pila que llevan al error pueden ser diferentes. Un seguimiento de pila diferente puede implicar una causa raíz diferente. Para representar esta posible diferencia dentro de un problema, creamos variantes dentro de ellos. Cada variante es un subgrupo de eventos en un problema que tienen el mismo punto de falla y un seguimiento de pila similar. Con las variantes, puedes depurar los seguimientos de pila más comunes dentro de un problema y determinar si distintas causas raíz llevan al error.

A continuación, te indicamos lo que experimentarás con estas mejoras:

• Metadatos renovados que se muestran en la fila de problemas
  Ahora es más fácil comprender y clasificar los problemas de tu app.

• Una menor cantidad de problemas duplicados
  Un cambio en el número de línea no genera un problema nuevo.

• Depuración más sencilla de problemas complejos con varias causas raíz
  Usa variantes para depurar los seguimientos de pila más comunes dentro de un problema.

• Indicadores y alertas más significativos
  Un nuevo problema en realidad representa un error nuevo.

• Búsqueda más eficaz
  Cada problema contiene metadatos más fáciles de buscar, como el tipo de excepción y el nombre del paquete.

A continuación, te mostramos cómo se implementan estas mejoras:

• Cuando recibamos eventos nuevos de tu app, verificaremos si coinciden con un problema existente.

• Si no hay ninguna coincidencia, aplicaremos automáticamente nuestro algoritmo más inteligente de agrupación de eventos y crearemos un problema nuevo con el diseño de metadatos renovado.

Esta es la primera actualización importante que realizamos en nuestra agrupación de eventos. Si tienes comentarios o tienes algún problema, completa un informe para informarnos al respecto.

Si no ves los registros de rutas de navegación, te recomendamos verificar la configuración de tu app para Google Analytics. Asegúrate de cumplir con los siguientes requisitos:

• Haber habilitado Google Analytics en tu proyecto de Firebase

• Haber habilitado el uso compartido de datos para Google Analytics. Obtén más información sobre este parámetro de configuración en Administra la configuración de uso compartido de datos de Analytics.

• Agregaste el SDK de Firebase para Google Analytics a tu app. Este SDK se debe agregar además del SDK de Crashlytics.

• Estás usando las las versiones más recientes del SDK de Firebase para todos los productos que usas en tu app.

Si no ves alertas de velocidad, asegúrate de usar la La versión 11.7.0 o una posterior del SDK de Crashlytics.

Si no ves métricas sin fallas (como sesiones y usuarios que no experimentaron fallas) o ves métricas poco confiables, verifica lo siguiente:

• Asegúrate de usar la La versión 11.7.0 o una posterior del SDK de Crashlytics.

• Asegúrate de que la configuración de recopilación de datos no afecte la calidad de tus métricas sin fallas:

  • Si habilitas los informes de aceptación inhabilitando los informes de fallas automáticos, la información de fallas solo se puede enviar a Crashlytics desde los usuarios que aceptaron explícitamente la recopilación de datos. Por lo tanto, la exactitud de las métricas sin fallas se verá afectada, ya que Crashlytics solo tiene información de fallas de estos usuarios que habilitaron la opción (en lugar de todos tus usuarios). Esto significa que tus métricas sin fallas pueden ser menos confiables y reflejar en menor medida la estabilidad general de tu app.

  • Si inhabilitaste la recopilación automática de datos, puedes usar sendUnsentReports para enviar informes almacenados en caché en el dispositivo a Crashlytics. Si usas este método, se enviarán datos de fallas a Crashlytics, pero no datos de sesiones, lo que hace que los gráficos de la consola muestren valores bajos o cero para las métricas sin fallas.

Consulta Información sobre las métricas sin fallas.

Si usas IL2CPP de Unity y ves seguimientos de pila no simbolizados, prueba lo siguiente:

1. Asegúrate de usar la versión 8.6.1 o posterior del SDK de Crashlytics para Unity.

2. Asegúrate de configurar y ejecutar el comando crashlytics:symbols:upload de Firebase CLI para generar y subir tu archivo de símbolos.

   Debes ejecutar este comando de la CLI cada vez que crees una compilación de lanzamiento, o bien una en la que quieras ver seguimientos de pila simbolizados Firebase console. Para saber más, visita la página Obtén informes de fallas legibles.

Sí, Crashlytics puede mostrar seguimientos de pila simbolizados de las apps que usan IL2CPP. Esta función se encuentra disponible para las apps que se lanzan en plataformas de Android o Apple. Sigue estos pasos:

1. Asegúrate de usar la versión 8.6.0 o posterior del SDK de Crashlytics para Unity.

2. Completa las tareas que son necesarias para tu plataforma:

   • En apps de plataformas de Apple: No se requieren acciones especiales. En el caso de las apps de plataformas de Apple, el complemento Firebase Unity Editor configura automáticamente tu proyecto de Xcode para subir símbolos.

   • En apps para Android: Asegúrate de configurar y ejecutar el comando crashlytics:symbols:upload de Firebase CLI para generar y subir tu archivo de símbolos.

     Debes ejecutar este comando de la CLI cada vez que crees una compilación de lanzamiento, o bien una en la que quieras ver seguimientos de pila simbolizados Firebase console. Para saber más, visita la página Obtén informes de fallas legibles.

Las notas permiten a los miembros del proyecto comentar problemas específicos con preguntas, actualizaciones de estado, etcétera.

Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su Cuenta de Google. Todos los miembros del proyecto con acceso para ver la nota pueden verla junto con la dirección de correo electrónico.

A continuación, se describe el acceso requerido para ver, escribir y borrar notas:

• Los miembros del proyecto con cualquiera de los siguientes roles pueden ver y borrar notas existentes y escribir notas nuevas sobre un problema.

  • Propietario o editor del proyecto, administrador de Firebase, administrador de calidad o administrador de Crashlytics

• Los miembros del proyecto con cualquiera de los siguientes roles pueden ver las notas publicadas sobre un problema, pero no pueden borrar ni escribir notas.

  • Visualizador del proyecto, visualizador de Firebase, visualizador de calidad o visualizador de Crashlytics

Si tu proyecto usa Crashlytics junto con el SDK de Google Mobile Ads, es probable que los generadores de informes de fallas interfieran cuando se registran controladores de excepciones. Para solucionar el problema, desactiva los informes de fallas en el SDK de Mobile Ads; para ello, llama a disableSDKCrashReporting.

Después de vincular Crashlytics con BigQuery, los nuevos conjuntos de datos que creas se ubican automáticamente en Estados Unidos, sin importar la ubicación de tu proyecto de Firebase.

Estos problemas suceden cuando ya se cerró un problema, pero Crashlytics informa que volvió a ocurrir. Crashlytics vuelve a abrir automáticamente el problema para que puedas solucionarlo según corresponda en tu app.

Aquí encontrarás un ejemplo en el que se explica cómo Crashlytics define que un problema es una regresión:

1. Crashlytics recibe un informe sobre la falla "A" por primera vez. Crashlytics abre un problema que corresponda a la falla (problema "A").
2. Para corregir el error rápidamente, debes cerrar el problema “A” y, luego, lanzar una nueva versión de tu app.
3. Crashlytics recibe otro informe sobre el problema "A" después de que lo cierras.
   • Si el informe es de una versión de la app que Crashlytics conocía cuando cerraste el problema (es decir, la versión envió un informe de fallas sobre cualquier falla), Crashlytics no considerará el problema como regresión y permanecerá cerrado.
   • Si el informe es de una versión de la app que Crashlytics no conocía cuando cerraste el problema (es decir, la versión nunca envió ningún informe de fallas), Crashlytics considera que el problema volvió a su estado original y lo abrirá de nuevo.

Cuando sucede una regresión de problema, enviamos una alerta de detección de regresión y agregamos un indicador al problema para informarte que Crashlytics lo volvió a abrir. Si no quieres que se vuelva a abrir un problema debido al algoritmo de regresión, “silencia” el problema en lugar de cerrarlo.

Si un informe es de una versión antigua de la app que no envió ningún informe de fallas cuando cerraste el problema, Crashlytics considera que el problema volvió a ocurrir y lo abrirá de nuevo.

Esto puede suceder en el siguiente caso: Corregiste un error y lanzaste una versión nueva de la app, pero aún tienes usuarios que utilizan versiones anteriores sin la corrección de errores. Si, por casualidad, una de esas versiones anteriores nunca envió ningún informe de fallas cuando cerraste el problema, y los usuarios comenzaron a detectar el error, esos informes de fallas activaron la regresión.

Si no quieres que se vuelva a abrir un problema debido al algoritmo de regresión, “silencia” el problema en lugar de cerrarlo.

Cuando informas las excepciones no detectadas como irrecuperables, obtienes una indicación más realista de las excepciones que pueden provocar que el juego no se pueda jugar, incluso si la app sigue ejecutándose.

Ten en cuenta que, si comienzas a informar errores irrecuperables, es probable que el porcentaje de usuarios que no experimentaron fallas (CFU) disminuya, pero la métrica de esta será más representativa de las experiencias de los usuarios finales con tu app.

Para que Crashlytics informe una excepción no detectada como irrecuperable, se deben cumplir estas dos condiciones:

• Durante la inicialización en tu app, la propiedad ReportUncaughtExceptionsAsFatal debe establecerse en true.

• Tu app (o una biblioteca incluida) arroja una excepción que no se detecta. Una excepción que se crea, pero no se arroja, no se considera no detectada.

Cuando comienzas a recibir informes de las excepciones no detectadas como irrecuperables, estas son algunas opciones para controlar estas excepciones no detectadas:

• Piensa en cómo puedes comenzar a capturar y manejar estas excepciones no detectadas.
• Considera diferentes opciones para registrar excepciones en la consola de depuración de Unity y en Crashlytics.

Detecta y maneja las excepciones arrojadas

Se crean y arrojan excepciones para reflejar estados inesperados o excepcionales. La resolución de los problemas reflejados por una excepción arrojada implica mostrar el programa a un estado conocido (un proceso conocido como manejo de excepciones).

Se recomienda detectar y manejar todas las excepciones previstas, a menos que el programa no pueda regresar a un estado conocido.

Para controlar qué tipos de excepciones captura y controla qué código, une el código que pueda generar una excepción en un bloque try-catch. Asegúrate de que las condiciones en las declaraciones catch sean lo más limitadas posible para manejar las excepciones específicas de manera adecuada.

Registra excepciones en Unity o Crashlytics

Existen varias formas de registrar excepciones en Unity o Crashlytics para depurar el problema.

Cuando usas Crashlytics, estas son las dos opciones más comunes y recomendadas:

• Opción 1: Imprime en la consola de Unity, pero no informes a Crashlytics, durante el desarrollo o la solución de problemas

  • Imprime en la consola de Unity con Debug.Log(exception), Debug.LogWarning(exception) y Debug.LogError(exception), que imprimen el contenido de la excepción en la consola de Unity y no vuelven a arrojarla.

• Opción 2: Sube a Crashlytics para obtener informes consolidados en el panel de Crashlytics en las siguientes situaciones:

  • Si vale la pena registrar una excepción para depurar un posible evento posterior de Crashlytics, usa Crashlytics.Log(exception.ToString()).
  • Si se debe informar una excepción a Crashlytics a pesar de que se detecta y maneja, usa Crashlytics.LogException(exception) para registrarla como un evento recuperable.

Sin embargo, si quieres informar de forma manual un evento irrecuperable a Unity Cloud Diagnostics, puedes usar Debug.LogException. Esta opción muestra la excepción en la consola de Unity como la opción 1, pero también arroja la excepción (sin importar si se la arrojó o se capturó). Arroja el error de forma no local. Esto significa que incluso un Debug.LogException(exception) circundante con bloques try-catch aún genera una excepción no detectada.

Por lo tanto, llama a Debug.LogException solo si deseas realizar todas las siguientes acciones:

• Imprimir la excepción en la consola de Unity:
• Subir la excepción a Crashlytics como un evento irrecuperable.
• Generar la excepción, haz que se trate como una excepción no detectada y que se informe a Unity Cloud Diagnostics.

Ten en cuenta que, si quieres imprimir una excepción detectada en la consola de Unity y subirla a Crashlytics como un evento recuperable, sigue estos pasos:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}