Solución de problemas y preguntas frecuentes de Crashlytics

Ver diferentes formatos (y, a veces, "variantes") de algunos problemas en la tabla Problemas

Puede que observes dos formatos diferentes para los problemas que se muestran en la tabla Problemas de la consola Firebase. También puede que veas una función llamada "variantes" en algunos de tus problemas. A continuación, te explicamos por qué.

A principios del 2023, lanzamos un motor de análisis mejorado para agrupar eventos, así como un diseño actualizado y algunas funciones avanzadas para nuevos problemas (como las variantes). Consulta nuestra entrada de blog para obtener todos los detalles, o bien lee los aspectos más destacados a continuación.

Crashlytics analiza todos los eventos de tu aplicación (como fallos, errores no fatales y errores ANR) y crea grupos de eventos llamados problemas. Todos los eventos de un problema tienen un punto de fallo común.

Para agrupar los eventos en estos problemas, el motor de análisis mejorado ahora tiene en cuenta muchos aspectos del evento, como los marcos del rastreo de la pila, el mensaje de excepción, el código de error y otras características de la plataforma o del tipo de error.

Sin embargo, dentro de este grupo de eventos, los seguimientos de pila que llevan al fallo pueden ser diferentes. Un rastreo de la pila diferente podría significar una causa raíz diferente. Para representar esta posible diferencia en un problema, ahora creamos variantes dentro de los problemas. Cada variante es un subgrupo de eventos de un problema que tienen el mismo punto de fallo y un rastreo de la pila similar. Con las variantes, puedes depurar los seguimientos de pila más habituales de un problema y determinar si diferentes causas raíz están provocando el fallo.

Estas son las ventajas que disfrutarás con estas mejoras:

• Metadatos renovados que se muestran en la fila del problema
  Ahora es más fácil entender y clasificar los problemas de tu aplicación.

• Menos problemas duplicados
  Si cambia el número de línea, no se crea un problema nuevo.

• Depuración más sencilla de problemas complejos con varias causas principales
  Usa variantes para depurar las trazas de pila más comunes de un problema.

• Alertas y señales más significativas
  Un nuevo problema representa un nuevo error.

• Búsqueda más potente
  Cada incidencia contiene más metadatos en los que se pueden realizar búsquedas, como el tipo de excepción y el nombre del paquete.

Así se implementarán estas mejoras:

• Cuando recibamos eventos nuevos de tu aplicación, comprobaremos si coinciden con un problema ya registrado.

• Si no hay ninguna coincidencia, aplicaremos automáticamente nuestro algoritmo de agrupación de eventos más inteligente al evento y crearemos un nuevo problema con el diseño de metadatos renovado.

Esta es la primera actualización importante que hacemos en la agrupación de eventos. Si tienes alguna sugerencia o detectas algún problema, envíanos un informe.

No veo registros de rutas de exploración

Si no ves registros de ruta de exploración (iOS+ | Android | Flutter | Unity), te recomendamos que compruebes la configuración de tu aplicación para Google Analytics. Debes cumplir los siguientes requisitos:

• Has habilitado Google Analytics en tu proyecto de Firebase.

• Ha habilitado la opción Compartir datos para Google Analytics. Consulte más información sobre esta opción en el artículo Gestionar las opciones para compartir datos de Analytics.

• Ha añadido a su aplicación el SDK de Firebase para Google Analytics: iOS+ | Android | Flutter | Unity.
  Este SDK debe añadirse además del SDK de Crashlytics.

• Usa las versiones más recientes del SDK de Firebase para todos los productos que utilices en tu aplicación (iOS+ | Android | Flutter | Unity).

  En el caso de las plataformas de Apple y las aplicaciones Android, compruebe que esté usando como mínimo la siguiente versión 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+).

No veo alertas de velocidad

Si no ves alertas de velocidad, asegúrate de que estás usando:

No veo métricas sin fallos (o las métricas que veo no son fiables)

Si no ve métricas sin fallos (como usuarios y sesiones sin fallos) o si las métricas no son fiables, compruebe lo siguiente:

• Asegúrate de que usas la

• Asegúrate de que tu configuración de recogida de datos no afecte a la calidad de tus métricas sin fallos:

  • Si habilitas los informes de participación inhabilitando los informes de fallos automáticos, la información sobre fallos solo se podrá enviar a Crashlytics de los usuarios que hayan habilitado explícitamente la recogida de datos. Por lo tanto, la precisión de las métricas sin fallos se verá afectada, ya que Crashlytics solo tendrá información sobre fallos de estos usuarios (en lugar de todos los usuarios). Esto significa que las métricas sin fallos pueden ser menos fiables y reflejar menos la estabilidad general de tu aplicación.

  • Si has inhabilitado la recogida automática de datos, puedes usar sendUnsentReports para enviar informes almacenados en caché en el dispositivo a Crashlytics. Si usa este método, se enviarán datos de fallos a Crashlytics, pero no datos de sesiones, lo que provocará que los gráficos de la consola muestren valores bajos o nulos en las métricas sin fallos.

¿Cómo se calcula el número de usuarios sin fallos?

Consulta Información sobre las métricas sin fallos.

¿Quién puede ver, escribir y eliminar notas en un problema?

Las notas permiten a los miembros del proyecto comentar problemas específicos con preguntas, actualizaciones de estado, etc.

Cuando un miembro del proyecto publica una nota, se etiqueta con el correo de su cuenta de Google. Esta dirección de correo se muestra, junto con la nota, a todos los miembros del proyecto que tengan permiso para verla.

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 de un problema, así como escribir notas nuevas.

  • Propietario o editor del proyecto, Administrador de Firebase, Administrador de calidad, o Administrador de Crashlytics

• Los miembros del proyecto que tengan uno de los siguientes roles pueden ver las notas publicadas en un problema, pero no pueden eliminarlas ni escribir ninguna.

  • Lector, Lector de Firebase, Lector de calidad o Lector de Crashlytics

¿Qué es un problema regresado?

Un problema ha tenido una regresión cuando lo has cerrado anteriormente, pero Crashlyticsrecibe un nuevo informe de que ha vuelto a ocurrir. Crashlytics vuelve a abrir automáticamente estos problemas con regresión para que puedas abordarlos según corresponda en tu aplicación.

A continuación, se muestra un ejemplo de cómo categoriza Crashlytics un problema como regresión:

1. Por primera vez, Crashlytics recibe un informe sobre fallos de Crash "A". Crashlytics abre un problema correspondiente a ese fallo (problema "A").
2. Corriges este error rápidamente, cierras el problema "A" y publicas una nueva versión de tu aplicación.
3. Crashlytics recibe otro informe sobre el problema "A" después de que lo hayas cerrado.
   • Si el informe procede de una versión de la aplicación que Crashlytics conocía cuando cerraste el problema (es decir, la versión había enviado un informe de fallo por cualquier fallo), Crashlytics no considerará que el problema se ha repetido. El problema seguirá cerrado.
   • Si el informe procede de una versión de la aplicación que Crashlytics no conocía cuando cerraste el problema (es decir, la versión nunca había enviado ningún informe de fallo), Crashlytics considera que el problema ha empeorado y lo volverá a abrir.

Cuando un problema empeora, enviamos una alerta de detección de regresión y añadimos una señal de regresión al problema para informarte de que Crashlytics ha vuelto a abrir el problema. Si no quieres que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "siléncialo" en lugar de cerrarlo.

¿Por qué veo problemas de regresión en versiones anteriores de la aplicación?

Si un informe procede de una versión antigua de la aplicación que nunca había enviado informes de fallos cuando cerraste el problema, Crashlytics considera que el problema ha empeorado y lo volverá a abrir.

Esto puede ocurrir en la siguiente situación: has corregido un error y has lanzado una nueva versión de tu aplicación, pero algunos usuarios siguen usando versiones anteriores que no tienen la corrección. Si, por casualidad, una de esas versiones anteriores nunca envió ningún informe de fallos cuando cerraste el problema y esos usuarios empiezan a detectar el error, esos informes de fallos activarían un problema regresivo.

Si no quieres que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "siléncialo" en lugar de cerrarlo.

Faltan archivos dSYM o no se suben

Para subir los dSYMs de tu proyecto y obtener un resultado detallado, comprueba lo siguiente:

1. Asegúrate de que la fase de compilación de tu proyecto contenga el Crashlytics script de ejecución, que permite a Xcode subir los dSYMs de tu proyecto durante el tiempo de compilación (consulta Inicializar Crashlytics para obtener instrucciones sobre cómo añadir el script). Después de actualizar tu proyecto, fuerza un fallo y confirma que el fallo aparece en el panel de control de Crashlytics.

2. Si ves una alerta "Falta dSYM" en la consola de Firebase, comprueba en Xcode que se generen dSYMs correctamente para la compilación.

3. Si Xcode genera dSYMs correctamente y sigues viendo que faltan dSYMs, es probable que la herramienta de script de ejecución se quede bloqueada al subir los dSYMs. En ese caso, prueba lo siguiente:

   • Asegúrate de que estás usando la versión más reciente de Crashlytics.

   • Sube los archivos dSYM que faltan manualmente:

     • Opción 1: Usa la opción "Arrastrar y soltar" basada en la consola de la pestaña dSYMs para subir un archivo ZIP que contenga los archivos dSYM que faltan.
     • Opción 2: Usa la secuencia de comandos upload-symbols para subir los archivos dSYM que faltan de los UUIDs proporcionados en la pestaña dSYMs.

4. Si sigues viendo que faltan dSYMs o las subidas siguen sin completarse, ponte en contacto con el equipo de Asistencia de Firebase e incluye tus registros.

Los fallos están mal simbolizados

Si parece que tus seguimientos de pila no tienen símbolos, comprueba lo siguiente:

• Si los marcos de la biblioteca de tu aplicación no tienen referencias al código de tu aplicación, asegúrate de que -fomit-frame-pointer no esté definido como una marca de compilación.

• Si ves varios marcos (Missing) en la biblioteca de tu aplicación, comprueba si faltan dSYMs opcionales (en la versión de la aplicación afectada) en la pestaña Crashlytics dSYMs de la consola Firebase. Si es así, sigue el paso para solucionar problemas "Alerta de dSYM que falta" de la pregunta frecuente sobre los dSYMs que faltan o no se suben de esta página. Ten en cuenta que, al subir estos dSYMs, no se simbolizarán los fallos que ya se hayan producido, pero sí se simbolizarán los futuros.

¿Puedo usar Crashlytics en macOS o tvOS?

Sí, puedes implementar Crashlytics en proyectos de macOS y tvOS. Asegúrate de incluir la versión 8.9.0 o una posterior del SDK de Firebase para Google Analytics para que los fallos tengan acceso a las métricas recogidas por Google Analytics (usuarios sin fallos, última versión, alertas de velocidad y registros de ruta de exploración).

¿Puedo usar Crashlytics en un proyecto de Firebase con varias aplicaciones en diferentes plataformas de Apple?

Ahora puedes informar de los fallos de varias aplicaciones en un solo proyecto de Firebase, incluso cuando las aplicaciones se hayan creado para diferentes plataformas de Apple (por ejemplo, iOS, tvOS y Mac Catalyst). Antes, tenías que separar las aplicaciones en proyectos de Firebase individuales si contenían el mismo ID de bundle.

¿Por qué solo se informan errores ANR en Android 11 y versiones posteriores?

Crashlytics admite informes de errores ANR para aplicaciones Android en dispositivos con Android 11 y versiones posteriores. La API subyacente que usamos para recoger errores ANR (getHistoricalProcessExitReasons) es más fiable que los enfoques basados en SIGQUIT o en el watchdog. Esta API solo está disponible en dispositivos con Android 11 o versiones posteriores.

¿Por qué faltan BuildIds en algunos errores ANR?

Si faltan BuildIds en algunas de tus ANRs, sigue estos pasos para solucionar el problema:

• Asegúrate de que estás usando una versión actualizada del Crashlytics SDK para Android y del Crashlytics complemento de Gradle.

  Si faltan BuildIds de Android 11 y algunos ANRs de Android 12, es probable que estés usando un SDK o un complemento de Gradle obsoletos, o ambos. Para recoger correctamente los BuildIds de estos errores ANR, debes usar las siguientes versiones:

  • Crashlytics SDK para Android v18.3.5 o versiones posteriores (Firebase BoM v31.2.2 o versiones posteriores)
  • Crashlytics Complemento de Gradle v2.9.4 o posterior

• Comprueba si estás usando una ubicación no estándar para tus bibliotecas compartidas.

  Si solo faltan BuildIds para 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 es así, es posible que Crashlytics no pueda localizar los BuildIds asociados. Te recomendamos que uses la ubicación estándar para las bibliotecas compartidas.

• Asegúrate de que no se quiten las BuildIds durante el proceso de compilación.

  Ten en cuenta que los siguientes consejos para solucionar problemas se aplican tanto a los errores ANR como a los fallos nativos.

  • Comprueba si existen BuildId ejecutando readelf -n en tus archivos binarios. Si no están presentes, añade -Wl,--build-id a las marcas de tu sistema de compilación.BuildId

  • Comprueba que no estés eliminando sin querer los BuildIds para reducir el tamaño del APK.

  • Si mantienes versiones con y sin símbolos de una biblioteca, asegúrate de apuntar a la versión correcta en tu código.

Diferencias entre los informes de errores ANR del panel de control Crashlytics y Google Play Console

Puede haber una discrepancia entre el recuento de errores ANR de Google Play y el de Crashlytics. Esto es normal debido a la diferencia en el mecanismo de recogida y registro de datos de errores ANR. Crashlytics registra los errores ANR cuando la aplicación se inicia, mientras que Android Vitals envía los datos de errores ANR después de que se produzcan.

Además, Crashlytics solo muestra los errores ANR que se producen en dispositivos con Android 11 o versiones posteriores, mientras que Google Play muestra los errores ANR de dispositivos con Servicios de Google Play y con el consentimiento de recogida de datos aceptado.

¿Por qué veo fallos de archivos .kt etiquetados como problemas .java?

Cuando una aplicación usa un ofuscador que no expone la extensión del archivo, Crashlytics genera cada problema con la extensión de archivo .java de forma predeterminada.

Para que Crashlytics pueda generar problemas con la extensión de archivo correcta, asegúrate de que tu aplicación use la siguiente configuración:

• Usa Android Gradle 4.2.0 o una versión posterior
• Usa R8 con la ofuscación activada. Para actualizar tu aplicación a R8, consulta esta documentación.

Ten en cuenta que, después de actualizar a la configuración descrita anteriormente, es posible que empieces a ver .ktproblemas nuevos que sean duplicados de problemas .javaya existentes. Consulta las preguntas frecuentes para obtener más información sobre esta situación.

¿Por qué veo problemas de .kt que son duplicados de problemas de .java?

Desde mediados de diciembre del 2021, Crashlytics se ha mejorado la compatibilidad con las aplicaciones que usan Kotlin.

Hasta hace poco, los ofuscadores disponibles no exponían la extensión del archivo, por lo que Crashlyticsgeneraba cada problema con la 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 en la aplicación está escrita en Kotlin e incluir el nombre de archivo correcto en la firma del problema. Ahora, los fallos se atribuyen correctamente a los archivos .kt (según corresponda) si tu aplicación tiene la siguiente configuración:

• Tu aplicación usa Android Gradle 4.2.0 o una versión posterior.
• Tu aplicación usa R8 con la ofuscación activada.

Como las nuevas fallos ahora incluyen la extensión de archivo correcta en sus firmas de problemas, es posible que veas nuevos problemas .kt que en realidad son duplicados de problemas .java. En la consola Firebase, intentamos identificar y comunicarte si un nuevo problema de .kt es un posible duplicado de un problema de .java.

No se producen fallos 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 provoca un fallo en tu aplicación, pero impide que envíe informes de fallos. Para solucionar este problema, haz lo siguiente:

1. Asegúrate de que estás usando la versión más reciente de DexGuard 8.x. La versión más reciente contiene reglas que requiere el SDK de Firebase Crashlytics.

2. Si no quieres cambiar la versión de DexGuard, prueba a añadir la siguiente línea a tus reglas de ofuscación (en el archivo de configuración de DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

¿Cómo puedo actualizar al complemento de Crashlytics Gradle v3?

La última versión del complemento de Crashlytics Gradle es una versión principal (v3.0.0) y moderniza el SDK al dejar de admitir versiones anteriores de Gradle y del complemento de Android para Gradle. Además, los cambios de esta versión resuelven problemas con AGP 8.1 y versiones posteriores, y mejoran la compatibilidad con aplicaciones nativas y compilaciones personalizadas.

Requisitos mínimos

El complemento Crashlytics de Gradle v3 tiene los siguientes requisitos mínimos:

• Complemento de Android para Gradle 8.1 o versiones posteriores
  Actualiza este complemento con el Asistente de actualización del complemento de Android para Gradle en la versión más reciente de Android Studio.

• Complemento de Gradle de Firebase 4.4.1 o una versión posteriorgoogle-services
  Para actualizar este complemento, especifica la versión más reciente en el archivo de compilación de Gradle de tu proyecto, de la siguiente manera:

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.4.4" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' apply false
  ...
}

Cambios en la extensión Crashlytics

En la versión 3 del complemento de Gradle Crashlytics, la extensión Crashlytics tiene los siguientes cambios que provocan errores:

• Se ha quitado la extensión del bloque defaultConfigandroid. En su lugar, debes configurar cada variante.

• Se ha quitado el campo obsoleto mappingFile. En su lugar, ahora se proporciona automáticamente el archivo de asignación combinado.

• Se ha quitado el campo obsoleto strippedNativeLibsDir. En su lugar, debes usar unstrippedNativeLibsDir para todas las bibliotecas nativas.

• Se ha cambiado el campo unstrippedNativeLibsDir para que sea acumulativo.

  Ver un ejemplo con varios directorios

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  La tarea uploadCrashlyticsSymbolFilesBasicRelease solo subirá los símbolos de MY/NATIVE/LIBS, pero uploadCrashlyticsSymbolFilesFeatureXRelease subirá los símbolos de MY/NATIVE/LIBS y MY/FEATURE_X/LIBS.

• Se ha sustituido el campo de cierre symbolGenerator por dos nuevos campos de nivel superior:

  • symbolGeneratorType, una cadena que puede ser "breakpad" (valor predeterminado) o "csym".
  • breakpadBinary, un archivo de una anulación binaria dump_syms local.

Ejemplo de cómo actualizar la extensión

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

Diferencias entre los seguimientos de pila del NDK en el panel de control Crashlytics y en logcat

Las cadenas de herramientas LLVM y GNU tienen valores predeterminados y tratamientos distintos para el segmento de solo lectura de los archivos binarios de tu aplicación, lo que puede generar seguimientos de pila incoherentes en la consola Firebase. Para mitigar este problema, añade las siguientes marcas de vinculación al proceso de compilación:

• Si usas el enlazador lld de la cadena de herramientas LLVM, añade lo siguiente:

  -Wl,--no-rosegment

• Si usas el enlazador ld.gold de la cadena de herramientas de GNU, añade lo siguiente:

  -Wl,--rosegment

Si sigues viendo incoherencias en el rastreo de la pila (o si ninguna de las dos marcas es pertinente para tu cadena de herramientas), prueba a añadir lo siguiente a tu proceso de compilación:

-fno-omit-frame-pointer

¿Cómo puedo usar mi propio archivo binario del generador de archivos de símbolos de Breakpad para NDK?

El complemento Crashlytics incluye un generador de archivos de símbolos de Breakpad personalizado. Si prefieres usar tu propio archivo binario para generar archivos de símbolos de Breakpad (por ejemplo, si prefieres compilar todos los ejecutables nativos de tu cadena de compilación a partir del código fuente), usa la propiedad de extensión symbolGeneratorBinary opcional para especificar la ruta al ejecutable.

Puedes especificar la ruta al archivo binario del generador de archivos de símbolos de Breakpad de dos formas:

• Opción 1: Especificar la ruta mediante la extensión firebaseCrashlytics en el archivo build.gradle

  Añade lo siguiente a tu archivo build.gradle.kts a nivel de aplicación:

  Complemento de Gradle v3.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 del complemento

  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: Especificar la ruta mediante una línea de propiedad en el archivo Gradle.properties

  Puede usar la propiedad com.google.firebase.crashlytics.breakpadBinary para especificar la ruta al archivo ejecutable.

  Puedes actualizar manualmente el archivo gradle.properties o hacerlo a través de la línea de comandos. Por ejemplo, para especificar la ruta mediante 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
  

¿Crashlytics es compatible con armeabi?

El NDK Firebase Crashlytics no es compatible con ARMv5 (armeabi). La compatibilidad con esta ABI se retiró en NDK r17.

Ver rastreos de la pila sin simbolizar de aplicaciones Android en el panel de control Crashlytics

Si usas IL2CPP de Unity y ves seguimientos de pila sin simbolizar, prueba lo siguiente:

1. Asegúrate de que estás usando la versión 8.6.1 o una posterior del SDK de CrashlyticsUnity.

2. Asegúrate de que tienes configurada y en ejecución la CLI Firebase crashlytics:symbols:upload 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 cualquier otra compilación de la que quieras ver rastreos de pila simbolizados en la consola Firebase. Consulta más información en Obtener informes de fallos legibles.

¿Se puede usar Crashlytics con aplicaciones que usan IL2CPP?

Sí, Crashlytics puede mostrar los seguimientos de pila simbolizados de tus aplicaciones que usen IL2CPP. Esta función está disponible para las aplicaciones lanzadas en plataformas Android o Apple. Esto es lo que tienes que hacer:

1. Asegúrate de usar la versión 8.6.0 o una posterior del SDK de Crashlytics Unity.

2. Completa las tareas necesarias para tu plataforma:

   • En el caso de las aplicaciones de la plataforma Apple: no es necesario realizar ninguna acción especial. En el caso de las aplicaciones de la plataforma Apple, el complemento Firebase Unity Editor configura automáticamente tu proyecto de Xcode para subir símbolos.

   • En el caso de las aplicaciones Android: asegúrate de que has configurado y ejecutado el comando Firebase CLI crashlytics:symbols:upload 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 cualquier otra compilación de la que quieras ver rastreos de pila simbolizados en la consola Firebase. Consulta más información en Obtener informes de fallos legibles.

¿Por qué debería una aplicación informar de excepciones no controladas como errores críticos?

Si informa de las excepciones no detectadas como errores fatales, obtendrá una indicación más realista de qué excepciones pueden provocar que no se pueda jugar al juego, aunque la aplicación siga ejecutándose.

Ten en cuenta que, si empiezas a registrar errores fatales, es probable que el porcentaje de usuarios sin fallos disminuya, pero la métrica de usuarios sin fallos representará mejor las experiencias de los usuarios finales con tu aplicación.

¿Qué excepciones se notificarán como errores graves?

Para que Crashlytics informe de una excepción no controlada como fatal, se deben cumplir las dos condiciones siguientes:

• Durante la inicialización en tu aplicación, la propiedad ReportUncaughtExceptionsAsFatal debe tener el valor true.

• Tu aplicación (o una biblioteca incluida) genera una excepción que no se detecta. Una excepción que se crea, pero no se genera, no se considera no controlada.

Después de habilitar los informes de excepciones no detectadas como errores fatales, ahora tengo muchos errores fatales nuevos. ¿Cómo puedo gestionar estas excepciones correctamente?

Cuando empieces a recibir informes de tus excepciones no controladas como errores fatales, aquí tienes algunas opciones para gestionar estas excepciones no controladas:

• Piensa en cómo puedes empezar a detectar y gestionar estas excepciones no controladas.
• Considera diferentes opciones para registrar excepciones en la consola de depuración de Unity y en Crashlytics.

Detectar y gestionar excepciones lanzadas

Las excepciones se crean y se lanzan para reflejar estados inesperados o excepcionales. Para resolver los problemas reflejados por una excepción generada, se debe devolver el programa a un estado conocido (un proceso denominado gestión de excepciones).

Es una práctica recomendada detectar y gestionar todas las excepciones previstas, a menos que el programa no pueda volver a un estado conocido.

Para controlar qué tipos de excepciones se detectan y gestionan con qué código, encapsula el código que pueda generar una excepción en un bloque try-catch. Asegúrate de que las condiciones de las instrucciones catch sean lo más específicas posible para gestionar las excepciones concretas de forma adecuada.

Registrar excepciones en Unity o Crashlytics

Hay varias formas de registrar excepciones en Unity o Crashlytics para ayudar a depurar el problema.

Cuando se usa Crashlytics, estas son las dos opciones más habituales y recomendadas:

• Opción 1: Imprimir en la consola de Unity, pero no informar 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 lanzar la excepción.

• Opción 2: Subir a Crashlytics para obtener informes consolidados en el panel de control de Crashlytics en las siguientes situaciones:

  • Si merece la pena registrar una excepción para depurar un posible evento Crashlytics posterior, usa Crashlytics.Log(exception.ToString()).
  • Si se debe seguir informando de una excepción a Crashlytics a pesar de que se haya detectado y gestionado, utiliza Crashlytics.LogException(exception) para registrarla como evento no fatal.

Sin embargo, si quieres informar manualmente de un evento fatal a Unity Cloud Diagnostics, puedes usar Debug.LogException. Esta opción imprime la excepción en la consola de Unity como la opción 1, pero también genera la excepción (tanto si se ha generado como si no). Genera el error de forma no local. Esto significa que, aunque haya un Debug.LogException(exception) con bloques try-catch, se producirá una excepción no controlada.

Por lo tanto, llama a Debug.LogException si y solo si quieres hacer todo lo siguiente:

• Para imprimir la excepción en la consola de Unity.
• Para subir la excepción a Crashlytics como evento grave.
• Para 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 evento no fatal, haz lo siguiente:

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
    //
}

La aplicación también usa el SDK Google Mobile Ads, pero no falla

Si tu proyecto usa Crashlytics junto con el SDK de Google Mobile Ads, es probable que los registradores de fallos interfieran al registrar controladores de excepciones. Para solucionar el problema, desactiva los informes de fallos en el SDK de Mobile Ads llamando a disableSDKCrashReporting.

¿Dónde se encuentra mi conjunto de datos de BigQuery?

Firebase exporta los datos a la ubicación del conjunto de datos que hayas seleccionado al configurar la exportación de datos a BigQuery.

• Esta ubicación se aplica tanto al conjunto de datos Crashlytics como al conjunto de datos de sesiones de Firebase (si la exportación de datos de sesiones está habilitada).

• Esta ubicación solo se aplica a los datos exportados a BigQuery y no afecta a la ubicación de los datos almacenados para usarse en el panel de control Crashlytics de la consola Firebase o en Android Studio.

• Una vez creado un conjunto de datos, no se puede cambiar su ubicación, pero puede copiarlo en otra ubicación o moverlo (volver a crearlo) manualmente a una ubicación diferente. Para obtener más información, consulta Cambiar la ubicación de las exportaciones actuales.

¿Tienes problemas después de actualizar a la nueva infraestructura de exportación de BigQuery?

A mediados de octubre del 2024, Crashlytics lanzó una nueva infraestructura para la exportación por lotes de datos de Crashlytics a BigQuery.

Todos los proyectos de Firebase se han actualizado automáticamente a la nueva infraestructura de exportación por lotes desde el 2 de marzo del 2026.

Diferencias importantes entre la infraestructura de exportación antigua y la nueva

• La nueva infraestructura admite Crashlyticsubicaciones de conjuntos de datos fuera de Estados Unidos.

  • Exportación habilitada antes de mediados de octubre del 2024 y actualización a la nueva infraestructura de exportación: ahora puedes cambiar la ubicación de la exportación de datos.

  • Exportación habilitada a mediados de octubre del 2024 o más tarde: durante la configuración, se te pidió que seleccionaras una ubicación para la exportación de datos.

• La nueva infraestructura no admite el relleno de datos anteriores a la habilitación de la exportación.

  • La infraestructura antigua permitía rellenar datos hasta 30 días antes de la fecha en la que habilitaste la exportación.

  • La nueva infraestructura admite rellenos de hasta los últimos 30 días o hasta la fecha más reciente en la que habilitó la exportación a BigQuery (lo que sea más reciente).

• La nueva infraestructura asigna nombres a las BigQuerytablas de datos por lotes con los identificadores definidos para tus aplicaciones de Firebase en tu proyecto de Firebase.

  • La antigua infraestructura escribía datos en tablas de lotes con nombres basados en los IDs de paquete o los nombres de paquete del archivo binario de tu aplicación.

  • La nueva infraestructura escribe datos en tablas de lotes con nombres basados en los IDs de bundle o nombres de paquete definidos para tus aplicaciones de Firebase registradas en tu proyecto de Firebase.

Si el nombre de tu tabla de lote antigua no coincide con el identificador de tu aplicación de Firebase

Si el nombre de tu tabla de lote antigua no coincide con el ID de bundle o el nombre de paquete definidos para tu aplicación de Firebase registrada, implementa una de estas opciones para evitar más interrupciones en los datos de lote exportados.

Entender cómo usa la infraestructura de exportación los identificadores para escribir datos en las tablas BigQuery

A continuación, se explica cómo escriben las dos infraestructuras de exportación los datos de Crashlytics en las tablas de lotes de BigQuery:

• Infraestructura de exportación antigua: escribía datos en una tabla con un nombre basado en el ID de bundle o el nombre de paquete del archivo binario de tu aplicación.

• Nueva infraestructura de exportación: escribe datos en una tabla con un nombre basado en el ID de bundle o el nombre del paquete definido para tu aplicación de Firebase registrada en tu proyecto de Firebase.

Por desgracia, a veces el ID de bundle o el nombre del paquete del archivo binario de tu aplicación no coincide con el ID de bundle o el nombre del paquete definido para tu aplicación de Firebase registrada en tu proyecto de Firebase. Esto suele ocurrir si alguien no ha introducido el identificador real durante el registro de la aplicación.

¿Qué ocurre si no se ha corregido antes de actualizar?

Si los identificadores de estas dos ubicaciones no coinciden, significa que ha ocurrido lo siguiente:

• Tus datos de Crashlytics ahora se escriben en una nueva tabla de lotes de BigQuery, es decir, una tabla con un nombre basado en el ID de bundle o el nombre de paquete definido para tu aplicación de Firebase registrada en tu proyecto de Firebase.

• Ya no se escriben datos en ninguna tabla antigua cuyo nombre se base en el identificador del archivo binario de tu aplicación.

Ejemplos de situaciones en las que los identificadores no coinciden

Ten en cuenta que los nombres de las tablas de BigQuerylotes se añaden automáticamente con _IOS o _ANDROID para indicar la plataforma de la aplicación.

^{* Si el identificador del archivo binario de tu aplicación coincide con uno de los identificadores definidos para una aplicación de Firebase, la nueva infraestructura de exportación no ha creado una tabla para ese identificador. En su lugar, seguirá escribiendo datos en él para esa aplicación concreta. El resto de las aplicaciones se escribirán en tablas nuevas.}

^{** Si uno de los identificadores del archivo binario de tu aplicación coincide con el identificador definido para la aplicación de Firebase, la nueva infraestructura de exportación no creará una tabla. En su lugar, mantendrá esa tabla y empezará a escribir datos de todas las aplicaciones en ella.}

Opciones para minimizar las interrupciones

• OPCIÓN 1:
  Usa la tabla que cree la nueva infraestructura de exportación. Copiarás los datos de la tabla antigua en la nueva.

  1. En la consola Google Cloud, copia todos los datos de la tabla antigua en la nueva que se creó durante la actualización de la infraestructura.

  2. Si tienes alguna dependencia posterior que dependa de tu tabla de lotes, cámbiala para que use la nueva tabla.

• OPCIÓN 2:
  Vuelve a configurar la escritura en tu tabla antigua. Para ello, tendrás que anular algunos valores predeterminados en un archivo de configuración BigQuery.

  1. En la consola de Firebase, busque el ID de aplicación de Firebase (por ejemplo, 1:1234567890:ios:321abc456def7890) de la aplicación con el nombre y el identificador de la tabla de lote que no coinciden y anótelo:
     Vaya a settings Configuración del proyecto y, a continuación, a la tarjeta Tus aplicaciones para ver todas sus aplicaciones de Firebase y su información.

  2. En la consola Google Cloud, cambia la nueva configuración de transferencia de datos que se ha creado al actualizar la infraestructura para que los datos se escriban en tu tabla antigua:

     1. Ve a BigQuery > Transferencias de datos para ver tu configuración de transferencia de datos.

     2. Selecciona la configuración que tenga la fuente Firebase Crashlytics with Multi-Region Support.

     3. En la esquina superior derecha, haz clic en Editar.

     4. En la sección Detalles de la fuente de datos, busque una lista de gmp_app_id y otra de client_namespace.

        En BigQuery, el ID de aplicación de Firebase se denomina gmp_app_id. De forma predeterminada, el valor client_namespace de BigQuery es el ID de bundle o el nombre de paquete únicos correspondientes de la aplicación, pero vas a anular esta configuración predeterminada.

        BigQuery usa el valor de client_namespace para el nombre de la tabla de lotes en la que escribe cada aplicación de Firebase vinculada.

     5. Busca el gmp_app_id de la aplicación de Firebase para la que quieras anular la configuración predeterminada. Cambia su valor client_namespace por el nombre de la tabla en la que quieras que escriba la aplicación de Firebase (normalmente, es el nombre de la tabla antigua en la que escribía la aplicación con la infraestructura de exportación antigua).

     6. Guarda el cambio de configuración.

  3. Programa una carga retroactiva para los días en los que falten datos en tu tabla antigua.

  4. Una vez que se haya completado el relleno, elimina la nueva tabla que ha creado automáticamente la nueva infraestructura de exportación.