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 ven las métricas sin fallas ni las alertas de velocidad
Si no ves métricas sin fallas (como usuarios y sesiones que no experimentaron fallas) ni alertas de velocidad, asegúrate de usar la La versión v18.6.0 del SDK de Crashlytics y versiones posteriores (o Firebase BoM v32.6.0 y versiones posteriores).
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:
Haber habilitado Google Analytics en tu proyecto de Firebase
Haber habilitado el uso compartido de datos para Google Analytics. Obtén más información sobre este parámetro de configuración en Administra la configuración de uso compartido de datos de Analytics.
Agregaste el SDK de Firebase para Google Analytics a tu app. Este SDK se debe agregar además del SDK de Crashlytics.
Estás usando las las versiones más recientes del SDK de Firebase para todos los productos que usas en tu app.
Sobre todo, asegúrate de estar usando como mínimo las siguientes versiones del SDK de Firebase para Google Analytics:
Android: versión v17.2.3 y posteriores (BoM v24.7.1 y versiones posteriores) .
¿Por qué los ANR solo se informan en Android 11 y versiones posteriores?
Crashlytics admite informes de ANR de apps para Android en dispositivos que ejecutan Android 11 y versiones posteriores. La API subyacente que usamos para recopilar ANR (getHistoricalProcessExitReasons) es más confiable que los métodos basados en SIGQUIT o perro guardián. Esta API solo está disponible en dispositivos con Android 11 y versiones posteriores.
¿Por qué faltan BuildId en
algunos ANR?
Si faltan BuildId en algunos de los errores ANR, soluciona el problema de la siguiente manera:
Asegúrate de usar una versión actualizada del SDK de Android de Crashlytics y del complemento de Gradle de Crashlytics.
Si faltan
BuildIdpara Android 11 y algunos errores ANR de Android 12, es probable que estés usando un SDK o un complemento de Gradle desactualizados, o ambos. Para recopilar correctamente losBuildIdde estos errores ANR, debes usar las siguientes versiones:- El SDK de Android de Crashlytics versión 18.3.5 y posteriores (Firebase BoM versión 31.2.2 y posteriores)
- Complemento de Gradle de Crashlytics v2.9.4 y versiones posteriores
Comprueba si usas una ubicación no estándar en tus bibliotecas compartidas.
Si solo te faltan
BuildIdpara las bibliotecas compartidas de tu app, es probable que no utilices la ubicación predeterminada y estándar en las bibliotecas compartidas. Si este es el caso, es posible que Crashlytics no pueda encontrar losBuildIdasociados. Te recomendamos que consideres usar la ubicación estándar para las bibliotecas compartidas.Asegúrate de no quitar
BuildIddurante el proceso de compilación.Ten en cuenta que las siguientes sugerencias para la solución de problemas se aplican a las fallas por errores ANR y en código nativo.
Ejecuta
readelf -nen tus objetos binarios para verificar si losBuildIdexisten. Si losBuildIdno están, agrega-Wl,--build-ida las marcas de tu sistema de compilación.Asegúrate de no quitar los
BuildIdde manera accidental para reducir el tamaño del APK.Si conservas las versiones de una biblioteca que incluyen y no incluyen estos elementos, asegúrate de apuntar a la versión correcta en tu código.
Diferencias entre los informes de ANR del panel de Crashlytics y los de Google Play Console
Puede haber discrepancias entre el recuento de ANR de Google Play y el de Crashlytics. Esto es esperable, ya que usan mecanismos distintos para recopilar los datos de ANR y para informarlos. Crashlytics informa sobre los ANR cuando se inicia la app, mientras que Android Vitals envía datos de ANR después de que se produce el error.
Además, Crashlytics solo muestra ANR que se producen en dispositivos con Android 11 y versiones posteriores, a diferencia de Google Play, que muestra ANR de dispositivos que tienen los Servicios de Google Play y en los que se acepta la recopilación de datos.
Diferencias entre los seguimientos de pila del NDK en el panel de Crashlytics y en Logcat
Las cadenas de herramientas de LLVM y GNU tienen opciones de configuración predeterminadas y tratamientos diferentes para el segmento de solo lectura de los objetos binarios de tu app, lo que puede generar incoherencias en los seguimientos de pila de Firebase console. Para mitigar este problema, agrega las siguientes marcas de vinculadores a tu proceso de compilación:
Si usas el vinculador
lldde la cadena de herramientas de LLVM, agrega lo siguiente:-Wl,--no-rosegmentSi usas el vinculador
ld.goldde la cadena de herramientas de GNU, agrega lo siguiente:-Wl,--rosegment
Si aún notas incoherencias en el seguimiento de pila (o si ninguna marca corresponde a tu cadena de herramientas), intenta agregar lo siguiente a tu proceso de compilación:
-fno-omit-frame-pointer¿Cómo uso mi propio objeto binario de generador de archivos de símbolos de Breakpad para el NDK?
El complemento de Crashlytics empaqueta un
generador de archivos de símbolos de Breakpad personalizado.
Si prefieres usar tu propio objeto binario para generar archivos de símbolos de Breakpad (por
ejemplo, si prefieres compilar todos los ejecutables nativos en la cadena de compilación a partir
del código fuente), usa la propiedad de extensión opcional symbolGeneratorBinary para especificar
la ruta de acceso al ejecutable.
Puedes especificar la ruta de acceso al objeto binario de generador de archivos de símbolos de Breakpad de dos maneras:
Opción 1: Especifica la ruta de acceso con la extensión
firebaseCrashlyticsen tu archivobuild.gradleAgrega lo siguiente al archivo
build.gradle.ktsa nivel de la app:Complemento de Gradle versión 3.0.0 o posterior
android { buildTypes { release { configure<CrashlyticsExtension> { nativeSymbolUploadEnabled = true // Add these optional fields to specify the path to the executable symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } }
Versiones anteriores de complementos
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: Especifica la ruta de acceso con una línea de propiedad en tu archivo de propiedades de Gradle
Puedes usar la propiedad
com.google.firebase.crashlytics.breakpadBinarypara especificar la ruta de acceso al ejecutable.Puedes actualizar manualmente el archivo de propiedades de Gradle o hacerlo con la línea de comandos. Por ejemplo, para especificar la ruta de acceso con la línea de comandos, usa un comando como el siguiente:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
No se reciben fallas con DexGuard
Si ves la siguiente excepción, es probable que estés 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 tu app, pero evita que envíe informes de fallas. Para solucionar este problema, haz lo siguiente:
Asegúrate de usar la versión más reciente de DexGuard 8.x, que incluye reglas necesarias para utilizar el SDK de Firebase Crashlytics.
Si no deseas cambiar la versión de DexGuard, agrega la siguiente línea a las reglas de ofuscación (en el archivo de configuración de DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
¿Por qué veo fallas
de archivos .kt etiquetados como errores .java?
Cuando una app usa un ofuscador que no expone la extensión de archivo,
Crashlytics genera cada error con una extensión de archivo .java de forma predeterminada.
Para que Crashlytics pueda generar errores con la extensión de archivo correcta, asegúrate de que la app use la siguiente configuración:
- Android para Gradle 4.2.0 o una versión posterior
- R8 con la ofuscación activada (para actualizar tu app a R8, revisa esta documentación)
Ten en cuenta que, después de actualizar a la configuración descrita anteriormente, es posible que comiences a ver
nuevos errores .kt que son duplicados de errores .java existentes. Consulta las
Preguntas frecuentes para obtener más información al respecto.
¿Por qué veo
errores de archivos .kt que son duplicados de errores
.java existentes?
A partir de mediados de diciembre de 2021, Crashlytics mejoró la compatibilidad con aplicaciones que usan Kotlin.
Hasta hace poco tiempo, los ofuscadores disponibles no exponían la extensión del archivo, por lo que
Crashlytics generaba cada error con una extensión de archivo .java de forma predeterminada.
Sin embargo, a partir de la versión 4.2.0 de Android para Gradle, R8 es compatible con extensiones de archivo.
Con esta actualización, ahora Crashlytics puede determinar si cada clase utilizada en
la app está escrita en Kotlin y, así, incluir el nombre de archivo correcto en la firma
del error. Ahora las fallas se atribuyen correctamente a los archivos .kt (según corresponda)
si tu app tiene la siguiente configuración:
- Tu app usa Android para Gradle 4.2.0 o una versión posterior.
- Tu app usa R8 con la ofuscación activada.
Debido a que las nuevas fallas ahora incluyen la extensión de archivo correcta en las firmas de los errores,
es posible que veas errores .kt nuevos que en realidad son duplicados de
otros existentes etiquetados como .java. En Firebase console, intentamos identificarte
y comunicarnos contigo si un nuevo error .kt es un posible duplicado de uno
existente etiquetado como .java.
¿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.
¿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.
Integraciones
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
¿Es Crashlytics compatible con armeabi?
El NDK de Firebase Crashlytics no es compatible con ARMv5 (armeabi). Se quitó la compatibilidad con esta ABI a partir de la versión r17 del NDK.
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 regresión y permanecerá cerrado.
- Si el informe es 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.