Esta página proporciona ayuda para la resolución de problemas y respuestas a preguntas frecuentes sobre el uso de Crashlytics. Si no puede encontrar lo que busca o necesita ayuda adicional, comuníquese con el soporte de Firebase .
Solución de problemas generales/Preguntas frecuentes
Si no ve usuarios sin bloqueos, registros de migas de pan o alertas de velocidad, le recomendamos verificar la configuración de su aplicación para Google Analytics.
Asegúrese de haber habilitado Google Analytics en su proyecto de Firebase.
Asegúrese de que el uso compartido de datos esté habilitado para Google Analytics en la página Integraciones > Google Analytics de Firebase console. Tenga en cuenta que la configuración de uso compartido de datos se muestra en la consola de Firebase, pero se administra en la consola de Google Analytics.
Además del SDK de Firebase Crashlytics, asegúrese de haber agregado el SDK de Firebase para Google Analytics a su aplicación ( iOS+ | Android ).
Asegúrate de estar usando las versiones más recientes para todos tus SDK de Firebase ( iOS+ | Android ).
Verifique especialmente que esté utilizando como mínimo las siguientes versiones del SDK de Firebase para Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ para macOS y tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
El valor sin fallas representa el porcentaje de usuarios que interactuaron con su aplicación pero no tuvieron una falla durante un período de tiempo específico.
Esta es la fórmula para calcular el porcentaje de usuarios sin fallas. Sus valores de entrada son proporcionados por Google Analytics.
1 - ( CRASHED_USERS / ALL_USERS )
Cuando ocurre un bloqueo, Google Analytics envía un tipo de evento
app_exceptiony CRASHED_USERS representa la cantidad de usuarios asociados con ese tipo de evento.ALL_USERS representa la cantidad total de usuarios que interactuaron con su aplicación durante el período de tiempo que seleccionó en el menú desplegable en la parte superior derecha del panel de control de Crashlytics.
Puede ver la cantidad de eventos app_exception para su aplicación en el panel de Analytics. Tenga en cuenta que, debido a pequeñas diferencias en la forma en que se procesan los bloqueos, el número app_exception se muestra en el panel de Analytics a veces puede diferir del número utilizado en el cálculo de usuarios sin bloqueos.
El porcentaje de usuarios sin fallas es una agregación a lo largo del tiempo , no un promedio.
Por ejemplo, imagine que su aplicación tiene tres usuarios; los llamaremos Usuario A, Usuario B y Usuario C. La siguiente tabla muestra qué usuarios interactuaron con su aplicación cada día y cuáles de esos usuarios tuvieron un bloqueo ese día:
| Lunes | martes | miércoles | |
|---|---|---|---|
| Usuarios que interactuaron con su aplicación | A B C | A B C | un, b |
| Usuario que tuvo un bloqueo | C | B | A |
El miércoles, su porcentaje de usuarios sin fallas es del 50 % (1 de cada 2 usuarios no tuvo fallas).
Dos de sus usuarios interactuaron con su aplicación el miércoles, pero solo uno de ellos (Usuario B) no tuvo fallas.Durante los últimos 2 días, el porcentaje de usuarios sin fallas es del 33,3 % (1 de cada 3 usuarios no tuvo fallas).
Tres de sus usuarios interactuaron con su aplicación en los últimos dos días, pero solo uno de ellos (Usuario C) no tuvo fallas.Durante los últimos 3 días, el porcentaje de usuarios sin fallas es del 0 % (0 de cada 3 usuarios no tuvieron fallas).
Tres de sus usuarios interactuaron con su aplicación durante los últimos tres días, pero ninguno de ellos tuvo fallas.
integraciones
Si su proyecto usa Crashlytics junto con el SDK de Google Mobile Ads, es probable que los reporteros de fallas estén interfiriendo al registrar controladores de excepciones. Para solucionar el problema, desactive los informes de fallas en el SDK de anuncios para dispositivos móviles llamando a disableSDKCrashReporting .
Después de vincular Crashlytics a BigQuery, los nuevos conjuntos de datos que cree se ubicarán automáticamente en los Estados Unidos, independientemente de la ubicación de su proyecto de Firebase.
Soporte de plataforma
problemas de regresión
Un problema tuvo una regresión cuando lo cerraste anteriormente, pero Crashlytics recibe un nuevo informe de que el problema ha vuelto a ocurrir. Crashlytics vuelve a abrir automáticamente estos problemas retrocedidos para que pueda abordarlos según corresponda para su aplicación.
Aquí hay un escenario de ejemplo que explica cómo Crashlytics categoriza un problema como una regresión:
- Por primera vez en la historia, Crashlytics obtiene un informe de bloqueo sobre Crash "A". Crashlytics abre un problema correspondiente a ese bloqueo (Problema "A").
- Arregle este error rápidamente, cierre el problema "A" y luego publique una nueva versión de su aplicación.
- Crashlytics obtiene otro informe sobre el problema "A" después de que haya cerrado el problema.
- Si el informe es 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 bloqueo para cualquier bloqueo), entonces Crashlytics no considerará el problema como regresivo. El tema permanecerá cerrado.
- Si el informe es 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 bloqueo para ningún bloqueo), entonces Crashlytics considera que el problema retrocedió y lo volverá a abrir. .
Cuando un problema retrocede, 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 se vuelva a abrir una incidencia debido a nuestro algoritmo de regresión, "silencia" la incidencia en lugar de cerrarla.
Si un informe es de una versión anterior de la aplicación que nunca envió ningún informe de bloqueo cuando cerró el problema, entonces Crashlytics considera que el problema retrocedió 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 todavía tiene usuarios en versiones anteriores sin la corrección del error. Si, por casualidad, una de esas versiones anteriores nunca envió ningún informe de bloqueo cuando cerró el problema, y esos usuarios comienzan a encontrar el error, entonces esos informes de bloqueo desencadenarían un problema de regresión.
Si no desea que se vuelva a abrir una incidencia debido a nuestro algoritmo de regresión, "silencia" la incidencia en lugar de cerrarla.