Preguntas frecuentes y solución de problemas de Crashlytics
En esta página, se proporciona ayuda para solucionar problemas y respuestas a preguntas
frecuentes sobre el uso de Crashlytics. Si no
encuentras lo que buscas o necesitas más ayuda, comunícate con el
equipo de asistencia de Firebase.
Preguntas frecuentes y solución de problemas generales
En la tabla Problemas,
se muestran diferentes formatos y, a veces, “variantes”, para algunos problemas
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.
No se muestran los registros de la ruta de navegación
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:
Agregaste
a tu app. Este SDK se debe agregar además del SDK de Crashlytics.
Estás usando las
para todos los productos que usas en tu app.
No se ven las alertas de velocidad
Si no ves alertas de velocidad, asegúrate de usar la
No se ven las métricas sin fallas (o se ven métricas poco confiables)
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
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.
¿Cómo se calculan los usuarios que no experimentaron fallas?
¿Quién puede ver, escribir y borrar notas sobre un problema?
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.
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.
La app también usa el
SDK de Google Mobile Ads, pero no recibe fallas
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.
¿Dónde se encuentra mi conjunto de datos de BigQuery?
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.
Plataformas compatibles
Problemas con regresiones
¿Qué es un problema
con regresión?
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:
Crashlytics recibe un informe sobre la falla
"A" por primera vez. Crashlytics abre un problema que corresponda a la falla (problema "A").
Para corregir el error rápidamente, debes cerrar el problema “A” y, luego, lanzar una nueva versión
de tu app.
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 Crashlyticsconocí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 Crashlyticsno
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.
¿Por qué veo regresiones en
versiones anteriores de la app?
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.
