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+) .
Crashlytics admite informes ANR para aplicaciones de Android desde dispositivos que ejecutan Android 11 y versiones posteriores. La API subyacente que usamos para recopilar ANR ( getHistoricalProcessExitReasons ) es más confiable que SIGQUIT o enfoques basados en vigilancia. Esta API está disponible solo en dispositivos Android 11+.
Puede haber una discrepancia entre el recuento de ANR entre Google Play y Crashlytics. Esto se espera debido a la diferencia en el mecanismo de recopilación y notificación de datos ANR. Crashlytics informa los ANR la próxima vez que se inicia la aplicación, mientras que Android Vitals envía datos ANR después de que se produce el ANR.
Además, Crashlytics solo muestra ANR que ocurren en dispositivos con Android 11+, en comparación con Google Play, que muestra ANR de dispositivos con servicios de Google Play y consentimiento de recopilación de datos aceptado.
Las cadenas de herramientas LLVM y GNU tienen valores predeterminados y tratamientos distintos para el segmento de solo lectura de los archivos binarios de su aplicación, lo que puede generar seguimientos de pila incoherentes en Firebase console. Para mitigar esto, agregue los siguientes indicadores de vinculación a su proceso de compilación:
Si está utilizando el enlazador
lldde la cadena de herramientas LLVM, agregue:-Wl,--no-rosegmentSi está utilizando el enlazador
ld.goldde la cadena de herramientas GNU, agregue:-Wl,--rosegment
Si aún ve inconsistencias en el seguimiento de la pila (o si ninguno de los indicadores es pertinente para su cadena de herramientas), intente agregar lo siguiente a su proceso de compilación:
-fno-omit-frame-pointer
El complemento Crashlytics incluye un generador de archivos de símbolos Breakpad personalizado . Si prefiere usar su propio binario para generar archivos de símbolos Breakpad (por ejemplo, si prefiere compilar todos los ejecutables nativos en su cadena de compilación desde el origen), use la propiedad de extensión opcional symbolGeneratorBinary para especificar la ruta al ejecutable.
Puede especificar la ruta al binario del generador de archivos de símbolos Breakpad de una de dos maneras:
Opción 1 : especifique la ruta a través de la extensión
firebaseCrashlyticsen su archivobuild.gradleAgregue lo siguiente a su archivo
build.gradlea nivel de aplicación:android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }Opción 2 : especifique la ruta a través de una línea de propiedad en su archivo de propiedades de Gradle
Puede usar la propiedad
com.google.firebase.crashlytics.symbolGeneratorBinarypara especificar la ruta al ejecutable.Puede actualizar manualmente su archivo de propiedades de Gradle o actualizar el archivo a través de la línea de comando. Por ejemplo, para especificar la ruta a través de la línea de comando, use un comando como el siguiente:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Si ve la siguiente excepción, es probable que esté usando una versión de DexGuard que no es compatible con el SDK de Firebase Crashlytics:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Esta excepción no bloquea su aplicación, pero evita que envíe informes de fallas. Para arreglar esto:
Asegúrese de estar utilizando la versión más reciente de DexGuard 8.x. La última versión contiene reglas requeridas por el SDK de Firebase Crashlytics.
Si no desea cambiar su versión de DexGuard, intente agregar la siguiente línea a sus reglas de ofuscación (en su archivo de configuración de DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Cuando una aplicación usa un ofuscador que no expone la extensión del archivo, Crashlytics genera cada problema con una extensión de archivo .java de forma predeterminada.
Para que Crashlytics pueda generar problemas con la extensión de archivo correcta, asegúrese de que su aplicación utilice la siguiente configuración:
- Utiliza Android Gradle 4.2.0 o superior
- Utiliza R8 con la ofuscación activada. Para actualizar su aplicación a R8, siga esta documentación .
Tenga en cuenta que después de actualizar a la configuración descrita anteriormente, es posible que comience a ver nuevos problemas de .kt que son duplicados de problemas de .java existentes. Consulte las preguntas frecuentes para obtener más información sobre esa circunstancia.
A partir de mediados de diciembre de 2021, Crashlytics mejoró el soporte para aplicaciones que usan Kotlin.
Hasta hace poco, los ofuscadores disponibles no exponían la extensión del archivo, por lo que Crashlytics generaba cada problema con una extensión de archivo .java de manera predeterminada. Sin embargo, a partir de Android Gradle 4.2.0, R8 admite extensiones de archivo.
Con esta actualización, Crashlytics ahora puede determinar si cada clase utilizada dentro de la aplicación está escrita en Kotlin e incluir el nombre de archivo correcto en la firma del problema. Los bloqueos ahora se atribuyen correctamente a archivos .kt (según corresponda) si su aplicación tiene la siguiente configuración:
- Su aplicación utiliza Android Gradle 4.2.0 o superior.
- Tu aplicación usa R8 con la ofuscación activada.
Dado que los nuevos bloqueos ahora incluyen la extensión de archivo correcta en las firmas de sus problemas, es posible que vea nuevos problemas .kt que en realidad son solo duplicados de problemas existentes con la .java . En la consola de Firebase, tratamos de identificar y comunicarle si un nuevo problema de .kt es un posible duplicado de un problema existente con la .java .
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
El NDK de Firebase Crashlytics no es compatible con ARMv5 (armeabi). El soporte para esta ABI se eliminó a partir de NDK r17.
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.