Firebase Crashlytics — qué es, fallos y diagnóstico de errores

Qué es Firebase Crashlytics

Firebase Crashlytics es un servicio gratuito de Google para monitorear la estabilidad de aplicaciones móviles, adquirido por Google en 2017 junto con la empresa Fabric. Crashlytics recopila automáticamente información sobre cada fallo de la aplicación, agrupa fallos idénticos por firma de pila y los muestra en la consola de Firebase priorizados por el número de usuarios afectados.

Historia y evolución

Crashlytics se lanzó en 2011 como parte de la plataforma Fabric y rápidamente se convirtió en el estándar de facto para la generación de informes de fallos en iOS. Después de su adquisición por Google en 2017 por un estimado de 2 mil millones de dólares (toda Fabric), Crashlytics se integró en el SDK de Firebase. La versión 18.0.0 (2021) añadió soporte para Kotlin Multiplatform, y la versión 19.0.0 (2024) introdujo la recopilación automática de ANR en Android sin configuración adicional. Según Google (2026), Crashlytics procesa más de 10 mil millones de fallos al mes.

Límites gratuitos de Crashlytics

Crashlytics se ofrece de forma gratuita con un límite de 500 mil sesiones al día por proyecto de Firebase. Esto es suficiente para la mayoría de las aplicaciones — según Google (2026), el 95% de los proyectos no superan el límite. Cuando se supera, la recopilación de datos no se detiene, pero los informes dejan de actualizarse hasta el día siguiente. Para proyectos de alto tráfico, están disponibles los planes Spark y Blaze de Firebase — Crashlytics sigue siendo gratuito en ambos planes, y el límite de sesiones se cuenta por separado.

Cómo detecta y recopila fallos Crashlytics

El mecanismo de recopilación de Crashlytics se basa en la interceptación de excepciones a nivel de plataforma y runtime. En Android, el SDK instala un UncaughtExceptionHandler que captura todas las excepciones no controladas de Kotlin y Java. En iOS, Crashlytics utiliza NSSetUncaughtExceptionHandler para Objective-C/Swift y su propio manejador de excepciones Mach para fallos de código nativo.

Tipos de fallos interceptados

Crashlytics distingue cinco tipos de fallos: fatal (fallos fatales), no fatal (excepciones no fatales pasadas manualmente), ANR (Android — aplicación no responde), señal (señales del SO — SIGSEGV, SIGABRT) y OOM (falta de memoria en iOS). Cada tipo se maneja mediante un mecanismo separado y se muestra en la consola con la etiqueta correspondiente.

Formato del informe de fallo

Cada informe de Crashlytics contiene información exhaustiva: una traza de pila completa con nombres de clase y números de línea, versión de la aplicación (versionName + versionCode), modelo del dispositivo, versión del SO, memoria disponible, orientación de la pantalla y tiempo desde el inicio. Si Firebase Analytics está conectado, el informe también incluye la ruta de los últimos 50 eventos del usuario antes del fallo — esto es fundamental para la reproducción del fallo.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Integración de Crashlytics en un proyecto Android

Conectar Crashlytics a una aplicación Android requiere añadir dos dependencias en build.gradle y configurar el plugin de Google Services. El SDK habilita automáticamente la generación de informes de fallos al inicializar Firebase sin código adicional. Para un funcionamiento correcto, también se necesitan el plugin google-services y el archivo google-services.json de la consola de Firebase.

// build.gradle (nivel de proyecto)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (nivel de aplicación)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Configuración del plugin Crashlytics

El plugin com.google.firebase.crashlytics realiza dos tareas: genera un identificador de compilación único (build ID) para el mapeo de pilas ofuscadas y crea automáticamente recursos para el SDK de Crashlytics. Sin el plugin, los fallos se marcarán como "unmapped" — solo verá nombres de clase ofuscados (a.b.c) sin posibilidad de encontrar el código fuente. El plugin se añade al build.gradle raíz y al build.gradle del módulo de la aplicación.

Verificación de la integración

Para probar la integración de Crashlytics se utiliza el método especial forceCrash(), que genera una excepción de prueba. Este método no está disponible en compilaciones de producción. Después de ejecutar un fallo de prueba, el informe aparece en la consola de Firebase en un plazo de 1 a 5 minutos. Si el informe no aparece, verifique que google-services.json coincida con el paquete de la aplicación y que no haya banderas en AndroidManifest que desactiven la recopilación de datos.

Análisis de fallos y agrupación de informes

La consola de Crashlytics ofrece dos niveles de visualización: una lista de todos los fallos (Issues) agrupados por tipo de fallo, y un informe detallado de cada Issue con traza, estadísticas y datos personalizados. Cada Issue combina todos los fallos con la misma firma — el mismo tipo de excepción y una traza de pila coincidente.

Issues y agrupación

La agrupación de fallos es una característica clave de Crashlytics. En lugar de mostrar miles de fallos individuales, el servicio los combina en Issues basándose en una huella digital (fingerprint) — una suma de verificación de la traza de pila. Un Issue puede contener desde 1 hasta varios millones de fallos. Cada Issue muestra: el número de ocurrencias fatales, el número de usuarios únicos, la versión de la aplicación en la que apareció el fallo y el porcentaje de usuarios que encontraron el problema.

Según Google (2026), en promedio el 20% de los Issues representan el 80% de todos los fallos fatales de la aplicación (principio de Pareto). Crashlytics ordena automáticamente los Issues por gravedad — cuantos más usuarios afectados, mayor prioridad. Esto permite al desarrollador corregir primero los problemas más masivos.

Estadísticas por versiones

Crashlytics rastrea la estabilidad de cada versión de la aplicación por separado. El gráfico de usuarios sin fallos (crash-free users) muestra el porcentaje de usuarios que no encontraron un fallo fatal en cada versión. Si el porcentaje cae por debajo de un umbral (por defecto 99%) al actualizar, Crashlytics envía una notificación por correo electrónico y en la consola de Firebase. Esto permite revertir rápidamente una versión problemática o lanzar un hotfix.

Claves personalizadas, registros y Breadcrumbs

Crashlytics proporciona tres mecanismos para enriquecer los informes con contexto: claves personalizadas (keys) para datos estructurados, registros (logs) para trazado textual y Breadcrumbs de Analytics para la ruta del usuario. Los tres tipos de datos se adjuntan al informe de fallo y son visibles en su tarjeta de detalle.

Claves personalizadas

Las Custom Keys son pares clave-valor que se envían junto con cada fallo. Máximo 64 claves por aplicación, cada clave es una cadena de hasta 1024 caracteres. Las claves son útiles para etiquetar el estado de la aplicación: nivel de suscripción, estado de autenticación, última pantalla, si VPN está activado. Los valores se sobrescriben — una nueva clave con el mismo nombre reemplaza a la anterior.

Registro de eventos

Los Custom Logs son mensajes de texto que Crashlytics almacena en un búfer circular de 64 KB. Los registros se adjuntan automáticamente al siguiente fallo. Si no ocurre ningún fallo, los registros no se envían al servidor (no consumen tráfico). El registro se utiliza para capturar los pasos del usuario antes del fallo: "payment_processing_started", "api_call_initiated", "response_received_200".

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs de Analytics

Si Firebase Analytics está conectado al proyecto, Crashlytics recibe automáticamente Breadcrumbs — los últimos 50 eventos de analítica antes del fallo. Cada breadcrumb contiene el nombre del evento y sus parámetros. Esto permite reconstruir la secuencia exacta de acciones que llevaron al fallo: el usuario abrió pantalla → añadió producto → procedió al pago → ocurrió el fallo. Los Breadcrumbs se muestran en la tarjeta del Issue en una pestaña separada "Logs".

Mejores prácticas para trabajar con fallos

Crashlytics es más efectivo cuando el contexto y el proceso de manejo de Issues están configurados correctamente. La práctica demuestra que los equipos que han implementado un flujo de trabajo de gestión de fallos reducen el tiempo de corrección de errores críticos en un 60% (datos de Google, 2026).

Priorización de Issues

No todos los fallos son igualmente importantes. La priorización por número de usuarios y frecuencia ayuda a centrarse en los problemas más críticos. Regla general: corregir Issues que afecten a más del 0.1% de los usuarios en un plazo de 24 horas. Los Issues con ocurrencias únicas (< 0.01%) pueden posponerse hasta el próximo lanzamiento planificado. Crashlytics marca automáticamente las regresiones — Issues que fueron corregidos pero reaparecieron en una nueva versión.

Integración con CI/CD

La API de Crashlytics permite integrar los informes de fallos en el pipeline de CI/CD a través de la API REST o Firebase CLI. Con cada nuevo lanzamiento, puede verificar automáticamente si el porcentaje de usuarios sin fallos supera un umbral. Si se supera el umbral, CI/CD bloquea el despliegue y envía una notificación al equipo. Firebase CLI admite el comando firebase crashlytics:builds:upload para cargar archivos de mapeo ProGuard/R8 — sin ellos, las pilas serán ilegibles.

Según Google (2026), las aplicaciones que utilizan la verificación automática de umbrales de usuarios sin fallos en CI/CD lanzan un 40% menos de regresiones a producción. Umbral recomendado: usuarios sin fallos >= 99.5% para lanzamientos críticos y >= 99.0% para los normales.