Esta página proporciona ayuda para la resolución de problemas y respuestas a preguntas frecuentes sobre el uso de Crashlytics. Si no encuentra lo que busca o necesita ayuda adicional, comuníquese con el soporte de Firebase .
Solución de problemas generales/Preguntas frecuentes
Es posible que observes dos formatos diferentes para los problemas enumerados en la tabla de Problemas de Firebase console. Y es posible que también notes una característica llamada "variantes" dentro de algunos de tus problemas. ¡Este es el por qué!
A principios de 2023, implementamos un motor de análisis mejorado para agrupar eventos, así como un diseño actualizado y algunas funciones avanzadas para nuevos problemas (¡como variantes!). Consulte nuestra publicación de blog reciente para conocer todos los detalles, pero puede leer a continuación los aspectos más destacados.
Crashlytics analiza todos los eventos de su aplicación (como fallas, no fatales y ANR) y crea grupos de eventos llamados problemas : todos los eventos de un problema tienen un punto de falla común.
Para agrupar eventos en estos problemas, el motor de análisis mejorado ahora analiza muchos aspectos del evento, incluidos los marcos en el seguimiento de la pila, el mensaje de excepción, el código de error y otras características de plataforma o tipo de error.
Sin embargo, dentro de este grupo de eventos, los seguimientos de la pila que conducen al error pueden ser diferentes. Un seguimiento de pila diferente podría significar una causa raíz diferente. Para representar esta posible diferencia dentro de un problema, ahora creamos variantes dentro de los problemas: cada variante es un subgrupo de eventos en un problema que tiene el mismo punto de falla y un seguimiento de pila similar. Con variantes, puede depurar los seguimientos de pila más comunes dentro de un problema y determinar si diferentes causas raíz están provocando el error.
Esto es lo que experimentará con estas mejoras:
Metadatos renovados que se muestran dentro de la fila del problema
Ahora es más fácil comprender y clasificar los problemas en su aplicación.Menos problemas duplicados
Un cambio de número de línea no genera un nuevo problema.Depuración más sencilla de problemas complejos con diversas causas fundamentales
Utilice variantes para depurar los seguimientos de pila más comunes dentro de un problema.Alertas y señales más significativas
Un nuevo problema en realidad representa un nuevo error.Búsqueda más poderosa
Cada problema contiene más metadatos de búsqueda, como el tipo de excepción y el nombre del paquete.
Así es como se están implementando estas mejoras:
Cuando recibamos nuevos eventos de su aplicación, verificaremos si coinciden con un problema existente.
Si no hay ninguna coincidencia, aplicaremos automáticamente nuestro algoritmo de agrupación de eventos más inteligente al evento y crearemos una nueva incidencia con el diseño de metadatos renovado.
Esta es la primera gran actualización que estamos realizando en nuestra agrupación de eventos. Si tiene comentarios o encuentra algún problema, háganoslo saber presentando un informe.
Si no ve métricas sin fallas (como usuarios y sesiones sin fallas) y/o alertas de velocidad, asegúrese de estar usando el SDK de CrashlyticsCrashlytics SDK v18.6.0+ (o Firebase BoM v32.6.0+).
Si no ve registros de ruta de navegación , le recomendamos verificar la configuración de su aplicación para Google Analytics. Asegúrate de cumplir con los siguientes requisitos:
Ha habilitado Google Analytics en su proyecto de Firebase.
Ha habilitado el uso compartido de datos para Google Analytics. Obtenga más información sobre esta configuración en Administrar la configuración para compartir datos de Analytics.
Ustedagregó el SDK de Firebase para Google Analyticsa su aplicación. Este SDK debe agregarse además del SDK de Crashlytics.
Estás utilizando las últimas versiones del SDK de Firebase l10nlas últimas versiones del SDK de Firebasepara todos los productos que usas en tu aplicación.
Verifique especialmente que esté utilizando como mínimo la siguiente versión del SDK de Firebase para Google Analytics:
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 utilizamos para recopilar ANR ( getHistoricalProcessExitReasons ) es más confiable que SIGQUIT o los enfoques basados en vigilancia. Esta API está disponible solo en dispositivos Android 11+.
Si a algunos de sus ANR les faltan sus BuildId , solucione el problema de la siguiente manera:
Asegúrate de estar utilizando una versión actualizada del SDK de Crashlytics para Android y del complemento Crashlytics Gradle.
Si le faltan
BuildIdpara Android 11 y algunos ANR de Android 12, es probable que esté utilizando un SDK, un complemento de Gradle o ambos desactualizados. Para recopilar correctamenteBuildIdpara estos ANR, debe utilizar las siguientes versiones:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Complemento Crashlytics Gradle v2.9.4+
Compruebe si está utilizando una ubicación no estándar para sus bibliotecas compartidas.
Si solo te faltan
BuildIdpara las bibliotecas compartidas de tu aplicación, es probable que no estés usando la ubicación predeterminada estándar para las bibliotecas compartidas. Si este es el caso, es posible que Crashlytics no pueda localizar losBuildIdasociados. Le recomendamos que considere utilizar la ubicación estándar para bibliotecas compartidas.Asegúrese de no eliminar los
BuildIddurante el proceso de compilación.Tenga en cuenta que los siguientes consejos para la solución de problemas se aplican tanto a los ANR como a los fallos nativos.
Compruebe si los
BuildIdexisten ejecutandoreadelf -nen sus archivos binarios. Si losBuildIdestán ausentes, agregue-Wl,--build-ida los indicadores de su sistema de compilación.Verifique que no esté eliminando involuntariamente los
BuildIden un esfuerzo por reducir el tamaño de su APK.Si mantiene versiones eliminadas y no eliminadas de una biblioteca, asegúrese de señalar la versión correcta en su código.
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 presentació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 los ANR que ocurren en dispositivos con Android 11+, en comparación con Google Play, que muestra los ANR de dispositivos con los servicios de Google Play y el consentimiento de recopilación de datos aceptado.
Las cadenas de herramientas LLVM y GNU tienen distintos valores predeterminados y tratamientos para el segmento de solo lectura de los archivos binarios de tu aplicación, lo que puede generar seguimientos de pila inconsistentes en Firebase console. Para mitigar esto, agregue los siguientes indicadores del vinculador a su proceso de compilación:
Si está utilizando el vinculador
lldde la cadena de herramientas LLVM, agregue:-Wl,--no-rosegmentSi está utilizando el vinculador
ld.goldde la cadena de herramientas GNU, agregue:-Wl,--rosegment
Si todavía ves inconsistencias en el seguimiento de la pila (o si ninguna de las marcas es pertinente para tu cadena de herramientas), intenta agregar lo siguiente a tu 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 código fuente), 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 utilizar 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 le impide enviar informes de fallos. Para arreglar esto:
Asegúrese de estar utilizando la última versión 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 utiliza 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 .kt que son duplicados de problemas .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 forma 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.
- Su aplicación usa R8 con la ofuscación activada.
Dado que los nuevos fallos ahora incluyen la extensión de archivo correcta en sus firmas de problemas, es posible que vea nuevos problemas .kt que en realidad son solo duplicados de problemas existentes etiquetados .java . En Firebase console, intentamos identificar y comunicarte si un nuevo problema .kt es un posible duplicado de un problema existente con etiqueta .java .
Las notas permiten a los miembros del proyecto comentar sobre temas específicos con preguntas, actualizaciones de estado, etc.
Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su cuenta de Google. Esta dirección de correo electrónico es visible, junto con la nota, para todos los miembros del proyecto con acceso para ver la nota.
A continuación se describe el acceso necesario para ver, escribir y eliminar notas:
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver y eliminar notas existentes y escribir nuevas notas sobre un tema.
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver las notas publicadas sobre un problema, pero no pueden eliminar ni escribir una nota.
- Visor de proyectos, Visor de Firebase , Visor de calidad o Visor de Crashlytics
Consulte Comprender las métricas sin fallos .
Las notas permiten a los miembros del proyecto comentar sobre temas específicos con preguntas, actualizaciones de estado, etc.
Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su cuenta de Google. Esta dirección de correo electrónico es visible, junto con la nota, para todos los miembros del proyecto con acceso para ver la nota.
A continuación se describe el acceso necesario para ver, escribir y eliminar notas:
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver y eliminar notas existentes y escribir nuevas notas sobre un tema.
Los miembros del proyecto con cualquiera de los siguientes roles pueden ver las notas publicadas sobre un problema, pero no pueden eliminar ni escribir una nota.
- Visor de proyectos, Visor de Firebase , Visor de calidad o Visor de Crashlytics
Integraciones
Si su proyecto utiliza Crashlytics junto con el SDK de anuncios de Google para móviles, es probable que los informadores de fallos estén interfiriendo al registrar controladores de excepciones. Para solucionar el problema, desactive los informes de fallos en el SDK de anuncios móviles llamando disableSDKCrashReporting .
Después de vincular Crashlytics a BigQuery, los nuevos conjuntos de datos que cree se ubican 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). La compatibilidad con esta ABI se eliminó a partir de NDK r17.
Problemas regresivos
Un problema ha tenido una regresión cuando lo cerró anteriormente, pero Crashlytics recibe un nuevo informe que indica que el problema ha vuelto a ocurrir. Crashlytics vuelve a abrir automáticamente estos problemas regresivos para que puedas abordarlos según corresponda para tu aplicación.
A continuación se muestra un escenario de ejemplo que explica cómo Crashlytics clasifica un problema como una regresión:
- Por primera vez, Crashlytics recibe un informe de fallo sobre el fallo "A". Crashlytics abre un problema correspondiente a ese bloqueo (Problema "A").
- Corrige este error rápidamente, cierra el problema "A" y luego publica una nueva versión de su aplicación.
- Crashlytics recibe otro informe sobre el problema "A" después de haber cerrado el problema.
- Si el informe proviene 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 falla por cualquier falla), entonces Crashlytics no considerará que el problema ha retrocedido. La cuestión permanecerá cerrada.
- Si el informe proviene 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 falla), entonces Crashlytics considera que el problema ha retrocedido y lo volverá a abrir. .
Cuando un problema regresa, 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 un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "silencia" el problema en lugar de cerrarlo.
Si un informe proviene de una versión anterior de la aplicación que nunca había enviado ningún informe de fallas cuando cerró el problema, Crashlytics considera que el problema ha retrocedido 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 aún tiene usuarios en versiones anteriores sin la corrección del error. Si, por casualidad, una de esas versiones anteriores nunca había enviado ningún informe de fallos cuando usted cerró el problema, y esos usuarios comienzan a encontrar el error, entonces esos informes de fallos desencadenarían un problema en regresión.
Si no desea que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "silencia" el problema en lugar de cerrarlo.