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
No se muestran los usuarios que no experimentaron fallas, los registros de rutas de navegación ni las alertas de velocidad
Si no ves los usuarios que no experimentaron fallas, los registros de rutas de navegación ni las alertas de velocidad, te recomendamos verificar la configuración de tu app para Google Analytics.
Asegúrate de haber habilitado Google Analytics en el proyecto de Firebase.
Asegúrate de que el Uso compartido de datos esté habilitado para Google Analytics en la página Integraciones > Google Analytics de Firebase console. Ten en cuenta que la configuración del Uso compartido de datos se muestra en Firebase console, pero se administra en la consola de Google Analytics.
Además del SDK de Firebase Crashlytics, asegúrate de haber agregado el SDK de Firebase para Google Analytics a tu app (iOS+ o Android).
Asegúrate de usar las versiones más recientes de todos tus SDK de Firebase (iOS+ o Android).
Sobre todo, asegúrate de que estás usando como mínimo las siguientes versiones del SDK de Firebase para Google Analytics:iOS+: 6.3.1 o posterior (versión 8.9.0 o posterior para macOS y tvOS) |Android: 17.2.3 o posterior (BoM versión 24.7.1 o posterior) .
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 a continuació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 de 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.
¿Cómo se calculan los usuarios que no experimentaron fallas?
El valor sin fallas representa el porcentaje de usuarios que interactuaron con tu app, pero no experimentaron fallas durante un período específico.
Esta es la fórmula para calcular el porcentaje de usuarios que no experimentaron fallas. Google Analytics proporciona los valores de entrada.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Cuando ocurre una falla, Google Analytics envía un tipo de evento
app_exception, y CRASHED_USERS representa la cantidad de usuarios asociados con ese tipo de evento.ALL_USERS representa la cantidad total de usuarios que participaron con tu app durante el período que seleccionaste en el menú desplegable de la parte superior derecha del panel de Crashlytics.
Este porcentaje es una agregación a lo largo del tiempo, no un promedio.
Por ejemplo, imagina que tu app tiene tres usuarios. Los llamaremos Usuario A, Usuario B y Usuario C. En la siguiente tabla, se muestra qué usuarios participaron con tu app cada día y cuáles de ellos experimentaron una falla ese día:
| Lunes | Martes | Miércoles | |
|---|---|---|---|
| Usuarios que interactuaron con tu aplicación | A, B, C | A, B, C | A, B |
| Usuario que experimentó una falla | C | B | A |
El porcentaje de usuarios que no experimentaron fallas el miércoles es de un 50% (1 de 2 usuarios no experimentó fallas).
Dos de tus usuarios interactuaron con la app el miércoles, pero solo uno de ellos (Usuario B) no experimentó fallas.En los últimos 2 días, el porcentaje de usuarios que no experimentaron fallas fue de un 33.3% (1 de cada 3 usuarios no experimentó fallas).
Tres de tus usuarios interactuaron con la app en los últimos dos días, pero solo uno de ellos (Usuario C) no experimentó fallas.Durante los últimos 3 días, el porcentaje de usuarios que no experimentaron fallas fue de un 0% (0 de 3 usuarios no experimentaron fallas).
Tres de tus usuarios interactuaron con la app en los últimos tres días, pero todos ellos 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.
Integraciones
La app también usa el SDK de anuncios de Google para dispositivos móviles, pero no recibe fallas
Si tu proyecto usa Crashlytics junto con el SDK de anuncios de Google para dispositivos móviles,
es probable que los generadores de informes de fallas interfieran cuando
se registran controladores de excepciones. Para corregir el problema, desactiva el informe de fallas en
el SDK de anuncios para dispositivos móviles llamando 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 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 una regresión y permanecerá cerrado.
- Si el informe proviene 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.
¿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.