Esta página proporciona ayuda para la resolución de problemas y respuestas a preguntas frecuentes sobre el uso de Crashlytics. Si no encuentra lo que busca o necesita ayuda adicional, comuníquese con el soporte de Firebase .
Solución de problemas generales/Preguntas frecuentes
Es posible que observes dos formatos diferentes para los problemas enumerados en la tabla de Problemas de Firebase console. Y es posible que también notes una característica llamada "variantes" dentro de algunos de tus problemas. ¡Este es el por qué!
A principios de 2023, implementamos un motor de análisis mejorado para agrupar eventos, así como un diseño actualizado y algunas funciones avanzadas para nuevos problemas (¡como variantes!). Consulte nuestra publicación de blog reciente para conocer todos los detalles, pero puede leer a continuación los aspectos más destacados.
Crashlytics analiza todos los eventos de su aplicación (como fallas, no fatales y ANR) y crea grupos de eventos llamados problemas : todos los eventos de un problema tienen un punto de falla común.
Para agrupar eventos en estos problemas, el motor de análisis mejorado ahora analiza muchos aspectos del evento, incluidos los marcos en el seguimiento de la pila, el mensaje de excepción, el código de error y otras características de plataforma o tipo de error.
Sin embargo, dentro de este grupo de eventos, los seguimientos de la pila que conducen al error pueden ser diferentes. Un seguimiento de pila diferente podría significar una causa raíz diferente. Para representar esta posible diferencia dentro de un problema, ahora creamos variantes dentro de los problemas: cada variante es un subgrupo de eventos en un problema que tiene el mismo punto de falla y un seguimiento de pila similar. Con variantes, puede depurar los seguimientos de pila más comunes dentro de un problema y determinar si diferentes causas raíz están provocando el error.
Esto es lo que experimentará con estas mejoras:
Metadatos renovados que se muestran dentro de la fila del problema
Ahora es más fácil comprender y clasificar los problemas en su aplicación.Menos problemas duplicados
Un cambio de número de línea no genera un nuevo problema.Depuración más sencilla de problemas complejos con diversas causas fundamentales
Utilice variantes para depurar los seguimientos de pila más comunes dentro de un problema.Alertas y señales más significativas
Un nuevo problema en realidad representa un nuevo error.Búsqueda más poderosa
Cada problema contiene más metadatos de búsqueda, como el tipo de excepción y el nombre del paquete.
Así es como se están implementando estas mejoras:
Cuando recibamos nuevos eventos de su aplicación, verificaremos si coinciden con un problema existente.
Si no hay ninguna coincidencia, aplicaremos automáticamente nuestro algoritmo de agrupación de eventos más inteligente al evento y crearemos una nueva incidencia con el diseño de metadatos renovado.
Esta es la primera gran actualización que estamos realizando en nuestra agrupación de eventos. Si tiene comentarios o encuentra algún problema, háganoslo saber presentando un informe.
Si no ve métricas sin fallas (como usuarios y sesiones sin fallas) y/o alertas de velocidad, asegúrese de estar usando el SDK de Crashlytics
Si no ve registros de ruta de navegación , le recomendamos verificar la configuración de su aplicación para Google Analytics. Asegúrate de cumplir con los siguientes requisitos:
Ha habilitado Google Analytics en su proyecto de Firebase.
Ha habilitado el uso compartido de datos para Google Analytics. Obtenga más información sobre esta configuración en Administrar la configuración para compartir datos de Analytics.
Usteda su aplicación. Este SDK debe agregarse además del SDK de Crashlytics.
Estás utilizando las últimas versiones del SDK de Firebase l10npara todos los productos que usas en tu aplicación.
Las notas permiten a los miembros del proyecto comentar sobre temas específicos con preguntas, actualizaciones de estado, etc.
Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su cuenta de Google. Esta dirección de correo electrónico es visible, junto con la nota, para todos los miembros del proyecto con acceso para ver la nota.
A continuación se describe el acceso necesario para ver, escribir y eliminar notas:
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver y eliminar notas existentes y escribir nuevas notas sobre un tema.
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver las notas publicadas sobre un problema, pero no pueden eliminar ni escribir una nota.
- Visor de proyectos, Visor de Firebase , Visor de calidad o Visor de Crashlytics
Consulte Comprender las métricas sin fallos .
Las notas permiten a los miembros del proyecto comentar sobre temas específicos con preguntas, actualizaciones de estado, etc.
Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su cuenta de Google. Esta dirección de correo electrónico es visible, junto con la nota, para todos los miembros del proyecto con acceso para ver la nota.
A continuación se describe el acceso necesario para ver, escribir y eliminar notas:
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver y eliminar notas existentes y escribir nuevas notas sobre un tema.
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver las notas publicadas sobre un problema, pero no pueden eliminar ni escribir una nota.
- Visor de proyectos, Visor de Firebase , Visor de calidad o Visor de Crashlytics
Integraciones
Si su proyecto utiliza Crashlytics junto con el SDK de anuncios de Google para móviles, es probable que los informadores de fallos estén interfiriendo al registrar controladores de excepciones. Para solucionar el problema, desactive los informes de fallos en el SDK de anuncios móviles llamando disableSDKCrashReporting .
Después de vincular Crashlytics a BigQuery, los nuevos conjuntos de datos que cree se ubican automáticamente en los Estados Unidos, independientemente de la ubicación de su proyecto de Firebase.
Soporte de plataforma
Problemas regresivos
Un problema ha tenido una regresión cuando lo cerró anteriormente, pero Crashlytics recibe un nuevo informe que indica que el problema ha vuelto a ocurrir. Crashlytics vuelve a abrir automáticamente estos problemas regresivos para que puedas abordarlos según corresponda para tu aplicación.
A continuación se muestra un escenario de ejemplo que explica cómo Crashlytics clasifica un problema como una regresión:
- Por primera vez, Crashlytics recibe un informe de fallo sobre el fallo "A". Crashlytics abre un problema correspondiente a ese bloqueo (Problema "A").
- Corrige este error rápidamente, cierra el problema "A" y luego publica una nueva versión de su aplicación.
- Crashlytics recibe otro informe sobre el problema "A" después de haber cerrado el problema.
- Si el informe proviene de una versión de la aplicación que Crashlytics conocía cuando cerró el problema (lo que significa que la versión había enviado un informe de falla por cualquier falla), entonces Crashlytics no considerará que el problema ha retrocedido. La cuestión permanecerá cerrada.
- Si el informe proviene de una versión de la aplicación que Crashlytics no conocía cuando cerró el problema (lo que significa que la versión nunca había enviado ningún informe de falla), entonces Crashlytics considera que el problema ha retrocedido y lo volverá a abrir. .
Cuando un problema regresa, enviamos una alerta de detección de regresión y agregamos una señal de regresión al problema para informarle que Crashlytics ha vuelto a abrir el problema. Si no desea que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "silencia" el problema en lugar de cerrarlo.
Si un informe proviene de una versión anterior de la aplicación que nunca había enviado ningún informe de fallas cuando cerró el problema, Crashlytics considera que el problema ha retrocedido y lo volverá a abrir.
Esta situación puede ocurrir en la siguiente situación: corrigió un error y lanzó una nueva versión de su aplicación, pero aún tiene usuarios en versiones anteriores sin la corrección del error. Si, por casualidad, una de esas versiones anteriores nunca había enviado ningún informe de fallos cuando usted cerró el problema, y esos usuarios comienzan a encontrar el error, entonces esos informes de fallos desencadenarían un problema en regresión.
Si no desea que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "silencia" el problema en lugar de cerrarlo.