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 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.
No se ven las métricas sin fallas ni las alertas de velocidad
Si no ves métricas que sin fallas (como sesiones y usuarios que no experimentaron fallas)
ni alertas de velocidad, asegúrate de usar la
versión 11.7.0 del SDK de Crashlytics o versiones posteriores.
No se muestran los registros de la ruta de navegación
Si no ves los
registros de la ruta de navegación,
te recomendamos verificar la configuración de tu app para Google Analytics.
Asegúrate de cumplir con los siguientes requisitos:
Cómo ver seguimientos de pila
no simbolizados de apps para Android en el panel de Crashlytics
Si usas IL2CPP
de Unity y ves seguimientos de pila no simbolizados, prueba lo siguiente:
Asegúrate de usar la versión 8.6.1 o posterior del SDK de Crashlytics
para Unity.
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
en Firebase console. Para saber más, visita la
página Obtén informes de fallas legibles.
¿Crashlytics puede usarse
con apps que utilizan IL2CPP?
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:
Asegúrate de usar la versión 8.6.0 o posterior del SDK de Crashlytics para
Unity.
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 a fin de 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
en Firebase console. Para saber más, visita la
página Obtén informes de fallas legibles.
¿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.
El valor de usuarios que no experimentaron fallas no se debe comparar en períodos diferentes.
La probabilidad de que un solo usuario experimente una falla aumenta a medida que usa tu app, por lo que es probable que el valor de los usuarios que no experimentaron fallas sea menor durante períodos más largos.
¿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.
¿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 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.
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 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.
Informa excepciones no detectadas como irrecuperables
Crashlytics puede informar las excepciones no detectadas como irrecuperables (a partir de la
versión 10.4.0
del SDK de Unity). Las siguientes preguntas frecuentes ayudan a explicar los motivos y las prácticas
recomendadas para usar esta función.
¿Por qué una app debería informar las excepciones no detectadas como irrecuperables?
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.
¿Qué excepciones se
informarán como irrecuperables?
Para que Crashlytics informe una excepción no detectada como irrecuperable,
se deben cumplir estas dos condiciones:
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.
Después de habilitar los informes de excepciones no detectadas como irrecuperables, ahora tengo muchas irrecuperables nuevas. ¿Cómo me encargo correctamente de estas excepciones?
Cuando comienzas a recibir informes de las excepciones no detectadas como irrecuperables, estas son
algunas opciones para controlar estas excepciones no detectadas:
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
//
}
