Preguntas frecuentes y solución de problemas de Crashlytics

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 muestran los registros de la ruta de navegación

Si no ves los registros de rutas de navegación (iOS+ | Android | Flutter | Unity), te recomendamos que verifiques 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 a tu app el SDK de Firebase para Google Analytics: iOS+ | Android | Flutter | Unity.
  Este SDK se debe agregar además del SDK de Crashlytics.

• Usas las versiones más recientes del SDK de Firebase para todos los productos que usas en tu app (iOS+ | Android | Flutter | Unity).

  En el caso de las plataformas de Apple y las apps para Android, asegúrate de usar como mínimo las siguientes versiones del SDK de Firebase para Google Analytics: iOS+: v6.3.1 y versiones posteriores (v8.9.0 y versiones posteriores para macOS y tvOS) | Android: v17.2.3 y versiones posteriores (BoM v24.7.1 y versiones posteriores).

No se ven las alertas de velocidad

Si no ves alertas de velocidad, asegúrate de usar la

No se ven las métricas sin fallas (o se ven métricas poco confiables)

Si no ves métricas sin fallas (como sesiones y usuarios que no experimentaron fallas) o ves métricas poco confiables, verifica lo siguiente:

• Asegúrate de usar la

• Asegúrate de que la configuración de recopilación de datos no afecte la calidad de tus métricas sin fallas:

  • Si habilitas los informes de aceptación inhabilitando los informes de fallas automáticos, la información de fallas solo se puede enviar a Crashlytics desde los usuarios que aceptaron explícitamente la recopilación de datos. Por lo tanto, la exactitud de las métricas sin fallas se verá afectada, ya que Crashlytics solo tiene información de fallas de estos usuarios que habilitaron la opción (en lugar de todos tus usuarios). Esto significa que tus métricas sin fallas pueden ser menos confiables y reflejar en menor medida la estabilidad general de tu app.

  • Si inhabilitaste la recopilación automática de datos, puedes usar sendUnsentReports para enviar informes almacenados en caché en el dispositivo a Crashlytics. Si usas este método, se enviarán datos de fallas a Crashlytics, pero no datos de sesiones, lo que hace que los gráficos de la consola muestren valores bajos o cero para las métricas sin fallas.

¿Cómo se calculan los usuarios que no experimentaron fallas?

Consulta Información sobre las métricas sin 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.

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

• 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.

  • Visualizador del proyecto, visualizador de Firebase, visualizador de calidad o visualizador de Crashlytics

¿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:

1. Crashlytics recibe un informe sobre la falla "A" por primera vez. Crashlytics abre un problema que corresponda a la falla (problema "A").
2. Para corregir el error rápidamente, debes cerrar el problema “A” y, luego, lanzar una nueva versión de tu app.
3. 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.

Faltan archivos dSYM o no se suben

Para subir los archivos dSYM de tu proyecto y obtener un resultado detallado, verifica lo siguiente:

1. Asegúrate de que la fase de compilación del proyecto contenga la secuencia de comandos de ejecución de Crashlytics, que permite que Xcode suba los archivos dSYM de tu proyecto en el momento de la compilación (consulta Inicializa Crashlytics si necesitas instrucciones para entregar la secuencia de comandos). Después de actualizar el proyecto, fuerza una falla y confirma que aparezca en el panel de Crashlytics.

2. Si ves la alerta "Missing dSYM" en Firebase console, revisa Xcode para asegurarte de que esté produciendo correctamente los archivos de dSYM de la compilación.

3. Si Xcode genera archivos dSYM de forma correcta y aún ves archivos dSYM faltantes, es probable que la herramienta de secuencia de comandos de ejecución se detenga mientras subes los dSYM. En ese caso, prueba cada uno de los siguientes pasos:

   • Asegúrate de usar la versión más reciente de Crashlytics.

   • Sube los archivos dSYM faltantes de forma manual:

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

4. Si todavía ves archivos dSYM faltantes o aún no se completan las cargas, comunícate con el equipo de Asistencia de Firebase y asegúrate de incluir tus registros.

Las fallas no se simbolizan de manera adecuada

Si los seguimientos de pila no tienen una buena simbolización, verifica lo siguiente:

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

• Si ves varios marcos (Missing) para la biblioteca de tu app, verifica si hay archivos dSYM opcionales enumerados como faltantes (en la versión de la app afectada) en la pestaña Crashlytics dSYMs de Firebase console. Si es así, sigue el paso para solucionar problemas de alertas sobre dSYM faltantes en las Preguntas frecuentes sobre dSYM faltantes o que no se suben en esta página. Ten en cuenta que subir estos archivos dSYM no simbolizará las fallas que ya ocurrieron, pero esto ayudará a garantizar la simbolización de las fallas futuras.

¿Puedo usar Crashlytics para macOS o tvOS?

Sí, puedes implementar Crashlytics en proyectos de macOS y tvOS. Asegúrate de incluir la versión 8.9.0 del SDK de Firebase para Google Analytics para que las fallas tengan acceso a las métricas que recopila Google Analytics (usuarios que no experimentaron fallas, versión más reciente, alertas de velocidad y registros de rutas de navegación).

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

Ahora puedes informar fallas de varias apps en un solo proyecto de Firebase, incluso si las apps se crearon para diferentes plataformas de Apple (por ejemplo, iOS, tvOS y Mac Catalyst). Anteriormente, se debían separar las apps en proyectos de Firebase individuales si contenían el mismo ID del paquete.

¿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 BuildId para 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 los BuildId de 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 BuildId para 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 los BuildId asociados. Te recomendamos que consideres usar la ubicación estándar para las bibliotecas compartidas.

• Asegúrate de no quitar BuildId durante 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 -n en tus objetos binarios para verificar si los BuildId existen. Si los BuildId no están, agrega -Wl,--build-id a las marcas de tu sistema de compilación.

  • Asegúrate de no quitar los BuildId de 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.

¿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.

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:

1. 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.

2. 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

¿Cómo actualizar a la versión 3 del complemento de Gradle de Crashlytics?

La versión más reciente del complemento de Gradle de Crashlytics es una versión principal (v3.0.0) y moderniza el SDK, ya que deja de ser compatible con versiones anteriores. de Gradle y el complemento de Android para Gradle. Además, los cambios en esta versión resuelven problemas con AGP v8.1 y mejoran la compatibilidad para apps nativas y compilaciones personalizadas.

Requisitos mínimos

La versión 3 del complemento de Gradle de Crashlytics tiene los siguientes requisitos mínimos:

• Complemento de Android para Gradle 8.1 y 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 google-services de Firebase 4.4.1 y versiones posteriores
  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 de Crashlytics

Con la versión 3 del complemento de Gradle de Crashlytics, la extensión de Crashlytics tiene los siguientes cambios rotundos:

• Se quitó la extensión del bloque defaultConfig de Android. En cambio, deberás configurar cada variante.

• Se quitó el campo obsoleto mappingFile. En cambio, el archivo de asignación combinado ahora se proporciona automáticamente.

• Se quitó el campo obsoleto strippedNativeLibsDir. En cambio, deberás usar unstrippedNativeLibsDir para todas las bibliotecas nativas.

• Se cambió el campo unstrippedNativeLibsDir para que sea acumulativo.

  Ve 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 en MY/NATIVE/LIBS, pero uploadCrashlyticsSymbolFilesFeatureXRelease subirá los símbolos en MY/NATIVE/LIBS y MY/FEATURE_X/LIBS.

• Se reemplazó el campo de cierre symbolGenerator por dos campos de nivel superior nuevos:

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

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 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 lld de la cadena de herramientas de LLVM, agrega lo siguiente:

  -Wl,--no-rosegment

• Si usas el vinculador ld.gold de 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 firebaseCrashlytics en tu archivo build.gradle

  Agrega lo siguiente al archivo build.gradle.kts a 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.breakpadBinary para 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
  

¿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.

Cómo ver seguimientos de pila no simbolizados de apps para Android en el panel de Crashlytics

Si usas IL2CPP de Unity y ves seguimientos de pila no simbolizados, prueba lo siguiente:

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

2. Asegúrate de configurar y ejecutar el comando crashlytics:symbols:upload de Firebase CLI 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 bien una en la que quieras ver seguimientos de pila simbolizados Firebase console. Obtén más información en Cómo obtener informes de fallas legibles.

¿Se puede usar Crashlytics con apps que usan IL2CPP?

Sí, Crashlytics puede mostrar seguimientos de pila simbolizados de las apps que usan IL2CPP. Esta función se encuentra disponible para las apps que se lanzan en plataformas de Android o Apple. Sigue estos pasos:

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

2. Completa las tareas que son necesarias para tu plataforma:

   • En apps de plataformas de Apple: No se requieren acciones especiales. En el caso de las apps de plataformas de Apple, el complemento Firebase Unity Editor configura automáticamente tu proyecto de Xcode para subir símbolos.

   • En apps para Android: Asegúrate de configurar y ejecutar el comando crashlytics:symbols:upload de Firebase CLI 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 bien una en la que quieras ver seguimientos de pila simbolizados Firebase console. Obtén más información en Cómo obtener informes de fallas legibles.

¿Por qué una app debería informar las excepciones no detectadas como irrecuperables?

Cuando informas las excepciones no detectadas como irrecuperables, obtienes una indicación más realista de las excepciones que pueden provocar que el juego no se pueda jugar, incluso si la app sigue ejecutándose.

Ten en cuenta que, si comienzas a informar errores irrecuperables, es probable que el porcentaje de usuarios que no experimentaron fallas (CFU) disminuya, pero la métrica de esta será más representativa de las experiencias de los usuarios finales con tu app.

¿Qué excepciones se informarán como irrecuperables?

Para que Crashlytics informe una excepción no detectada como irrecuperable, se deben cumplir estas dos condiciones:

• Durante la inicialización en tu app, la propiedad ReportUncaughtExceptionsAsFatal debe establecerse en true.

• Tu app (o una biblioteca incluida) arroja una excepción que no se detecta. Una excepción que se crea, pero no se arroja, no se considera no detectada.

Después de habilitar los informes de excepciones no detectadas como irrecuperables, ahora tengo muchas irrecuperables nuevas. ¿Cómo me encargo correctamente de estas excepciones?

Cuando comienzas a recibir informes de las excepciones no detectadas como irrecuperables, estas son algunas opciones para controlar estas excepciones no detectadas:

• Piensa en cómo puedes comenzar a capturar y manejar estas excepciones no detectadas.
• Considera diferentes opciones para registrar excepciones en la consola de depuración de Unity y en Crashlytics.

Detecta y maneja las excepciones arrojadas

Se crean y arrojan excepciones para reflejar estados inesperados o excepcionales. La resolución de los problemas reflejados por una excepción arrojada implica devolver el programa a un estado conocido (un proceso conocido como manejo de excepciones).

Se recomienda detectar y manejar todas las excepciones previstas, a menos que el programa no pueda regresar a un estado conocido.

Para controlar qué tipos de excepciones captura y controla qué código, une el código que pueda generar una excepción en un bloque try-catch. Asegúrate de que las condiciones en las declaraciones catch sean lo más limitadas posible para manejar las excepciones específicas de manera adecuada.

Registra excepciones en Unity o Crashlytics

Existen varias formas de registrar excepciones en Unity o Crashlytics para depurar el problema.

Cuando usas Crashlytics, estas son las dos opciones más comunes y recomendadas:

• Opción 1: Imprime en la consola de Unity, pero no informes 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 arrojarla.

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

  • Si vale la pena registrar una excepción para depurar un posible evento posterior de Crashlytics, usa Crashlytics.Log(exception.ToString()).
  • Si se debe informar una excepción a Crashlytics a pesar de que se detecta y maneja, usa Crashlytics.LogException(exception) para registrarla como un evento recuperable.

Sin embargo, si quieres informar de forma manual un evento irrecuperable a Unity Cloud Diagnostics, puedes usar Debug.LogException. Esta opción muestra la excepción en la consola de Unity como la opción 1, pero también arroja la excepción (sin importar si se la arrojó o se capturó). Arroja el error de forma no local. Esto significa que incluso un Debug.LogException(exception) circundante con bloques try-catch aún genera una excepción no detectada.

Por lo tanto, llama a Debug.LogException solo si deseas realizar todas las siguientes acciones:

• Imprimir la excepción en la consola de Unity:
• Subir la excepción a Crashlytics como un evento irrecuperable.
• 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 un evento recuperable, sigue estos pasos:

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 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?

Firebase exporta los datos a la ubicación del conjunto de datos que seleccionaste cuando configuraste la exportación de datos a BigQuery.

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

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

• Después de crear un conjunto de datos, no se puede cambiar su ubicación, pero puedes copiarlo en otra ubicación o moverlo (volver a crearlo) manualmente a otra ubicación. Para obtener más información, consulta Cambia la ubicación de las exportaciones existentes.

¿Cómo actualizar a la nueva infraestructura de exportación para BigQuery?

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

• Si habilitaste la exportación por lotes después de octubre de 2024, tu proyecto de Firebase usará automáticamente la nueva infraestructura de exportación. No se requiere ninguna acción.

• Si habilitaste la exportación por lotes antes de octubre de 2024 o durante esa fecha, revisa la información de esta pregunta frecuente para determinar si debes realizar alguna acción.

Todos los proyectos de Firebase se actualizarán automáticamente a la nueva infraestructura de exportación por lotes a partir del 9 de enero de 2026. Puedes actualizar antes de esta fecha, pero asegúrate de que tus tablas por lotes de BigQuery cumplan con los requisitos para la actualización.

Puedes actualizar a la nueva infraestructura, pero asegúrate de que tus tablas por lotes de BigQuery cumplan con los requisitos para la actualización.

Determina si estás en la infraestructura nueva

Si habilitaste la exportación por lotes a mediados de octubre de 2024 o después de esa fecha, tu proyecto de Firebase usa automáticamente la nueva infraestructura de exportación.

Para verificar qué infraestructura usa tu proyecto, vete a la consola de Google Cloud y, si la "configuración de transferencia de datos" está etiquetada como Firebase Crashlytics with Multi-Region Support, entonces tu proyecto usa la nueva infraestructura de exportación.

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

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

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

  • Exportación habilitada a mediados de octubre de 2024 o después: Se te solicitó durante la configuración que seleccionaras una ubicación para la exportación de datos.

• La nueva infraestructura no admite reabastecimientos de datos de antes de que habilitaras la exportación.

  • La infraestructura anterior admitía el reabastecimiento hasta 30 días antes de la fecha en la que habilitaste la exportación.

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

• La nueva infraestructura asigna nombres a las tablas por lotes de BigQuery con los identificadores establecidos para tus apps de Firebase en tu proyecto de Firebase.

  • La infraestructura anterior escribía datos en tablas por lotes con nombres basados en los IDs o nombres de los paquetes en el objeto binario de tu app.

  • La nueva infraestructura escribe datos en tablas por lotes con nombres basados en los IDs o los nombres de los paquetes establecidos para tus apps de Firebase registradas en tu proyecto de Firebase.

Paso 1: Requisitos previos para la actualización

1. Verifica que tus tablas por lotes de BigQuery existentes usen identificadores que coincidan con los IDs o los nombres de los paquetes establecidos para tus apps de Firebase registradas en tu proyecto de Firebase. Si no coinciden, es posible que experimentes interrupciones en los datos de tu lote exportado. La mayoría de los proyectos estarán en un estado adecuado y compatible, pero es importante verificarlo antes de actualizar.

   • Puedes encontrar todas las apps de Firebase registradas en tu proyecto de Firebase en la consola de Firebase. Para ello, ve a Configuración del proyecto en settings y, luego, desplázate hasta la tarjeta Tus apps para ver todas tus apps de Firebase y su información.

   • Puedes encontrar todas tus tablas por lotes de BigQuery en la página BigQuery de la consola de Google Cloud.

   Por ejemplo, estos son los estados ideales en los que no tendrás ningún problema para actualizar:

   • Tienes una tabla por lotes llamada com_yourcompany_yourproject_IOS y una app para iOS+ de Firebase con el ID del paquete com.yourcompany.yourproject registrada en tu proyecto de Firebase.

   • Tienes una tabla por lotes llamada com_yourcompany_yourproject_ANDROID y una app para Android de Firebase con el nombre de paquete com.yourcompany.yourproject registrada en tu proyecto de Firebase.

2. Si tienes nombres de tablas por lotes que no coinciden con los identificadores establecidos para tus apps de Firebase registradas, entonces sigue las instrucciones más adelante en esta página antes de actualizar manualmente o antes del 9 de enero de 2026 para evitar interrupciones en la exportación por lotes.

Paso 2: Actualiza manualmente a la nueva infraestructura

Si habilitaste la exportación por lotes antes de mediados de octubre de 2024, puedes actualizar manualmente a la nueva infraestructura. Para ello, desactiva y vuelve a activar la exportación de datos de Crashlytics en la consola de Firebase.

Estos son los pasos detallados:

1. En Firebase console, ve a la página Integraciones.

2. En la tarjeta de BigQuery, haz clic en Administrar.

3. Desactiva el control deslizante de Crashlytics para inhabilitar la exportación. Cuando se te solicite, confirma que quieres que se detenga la exportación de datos.

4. Vuelve a activar inmediatamente el control deslizante Crashlytics para volver a habilitar la exportación. Cuando se te solicite, confirma que quieres exportar datos.

   La exportación de datos de Crashlytics a BigQuery ahora usa la nueva infraestructura de exportación.

El nombre de la tabla por lotes existente no coincide con el identificador de tu app de Firebase