ANR en Android: qué es, causas y métodos de solución

Qué es ANR en Android

ANR (Application Not Responding) es un mecanismo de protección al usuario en Android que se activa cuando la aplicación deja de responder a la entrada. El sistema realiza un seguimiento del tiempo de procesamiento de eventos: si BroadcastReceiver no completa onReceive en 10 segundos, Service no regresa de onCreate en 20 segundos, o ContentProvider no responde en 15 segundos — Android genera un ANR.

Cómo se ve ANR para el usuario

Cuando ocurre un ANR, Android muestra un diálogo del sistema sobre todas las ventanas: “La aplicación no responde. ¿Cerrarla o esperar?” El usuario puede cerrar la aplicación o esperar a que se recupere. Si los ANR ocurren con frecuencia, el usuario desinstala la aplicación. Google Play considera la tasa de ANR — el porcentaje de sesiones con ANR — en sus algoritmos de clasificación.

Diferencia entre ANR y bloqueos en iOS

iOS no tiene un equivalente de ANR con un diálogo del sistema. En su lugar, Apple utiliza Watchdog, que finaliza el proceso con el código 0x8badf00d. El usuario no ve un diálogo — la aplicación simplemente se cierra a la pantalla de inicio. Esto hace que ANR en Android sea más notable para el usuario, pero le da al sistema más información de diagnóstico.

Principales causas de ANR

ANR ocurre cuando el sistema rastrea un tiempo de espera para uno de los cuatro tipos de componentes. Cada componente tiene su propio límite de tiempo.

Bloqueo en BroadcastReceiver

BroadcastReceiver se ejecuta en el hilo principal. Si onReceive inicia una solicitud de red sincrónica, una escritura larga en la base de datos o espera un bloqueo — se produce un ANR en 10 segundos. Solución: usa goAsync() y WorkManager para el procesamiento en segundo plano. Un escenario típico es recibir una notificación Push de FCM y guardarla sincrónicamente en Room.

Operación prolongada en Service

Service.onCreate y Service.onStartCommand tienen un límite de 20 segundos. Si el servicio inicia una inicialización pesada (carga de librerías, lectura de configuración desde la red) en el hilo principal — el ANR es inevitable. Usa IntentService (obsoleto) o WorkManager para una ejecución garantizada en segundo plano.

ContentProvider con inicialización lenta

ContentProvider.onCreate se ejecuta antes de Application.onCreate y tiene un límite de 15 segundos. Si el proveedor realiza una migración de base de datos, carga diccionarios o inicializa SDK desde la red — esto causa ANR al iniciar la aplicación. Solución: inicialización perezosa, descarga de operaciones pesadas a WorkManager.

• BroadcastReceiver — 10 segundos para onReceive; usa goAsync() para procesamiento en segundo plano
• Service — 20 segundos para onCreate/onStartCommand; usa WorkManager o CoroutineWorker
• ContentProvider — 15 segundos para onCreate; traslada la inicialización a Application.onCreate con inicio retardado
• Hilo de UI — 5 segundos sin procesar eventos; cualquier bloqueo superior a 5 segundos provoca ANR

Cómo diagnosticar ANR

Android proporciona varias herramientas para el análisis de ANR: desde registros del sistema hasta librerías especializadas.

Análisis de traces.txt

En cada ANR, Android guarda el archivo /data/anr/traces.txt con un volcado de pila de todos los hilos de la aplicación. Encuentra el hilo “main” — el último método en la pila indica la causa. Patrones típicos: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Para extraer el archivo del dispositivo, usa adb con privilegios de superusuario.

Firebase Crashlytics con informes ANR

Firebase Crashlytics recopila automáticamente los ANR y los muestra en el panel con trazados. Para Android 11+, los informes ANR vienen con la pila completa del hilo principal. La integración requiere agregar una dependencia e inicializar FirebaseApp en Application.onCreate.

Android Studio Profiler con trazado de hilos

CPU Profiler en Android Studio permite registrar la trazada de la aplicación y ver qué métodos consumen tiempo de CPU. Activa “Record with method traces” y reproduce el escenario que causa el ANR. La línea de tiempo mostrará qué métodos se estaban ejecutando en el hilo principal en el momento del bloqueo.

Ejemplo de integración de Firebase Crashlytics para la recopilación de ANR en Android:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        FirebaseCrashlytics.getInstance()
            .setCrashlyticsCollectionEnabled(true)
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build())
    }
}

Métodos para solucionar ANR

Solucionar ANR significa principalmente mover todas las operaciones de larga duración del hilo principal a hilos secundarios. Veamos técnicas específicas para cada tipo de componente.

Uso de WorkManager para tareas en segundo plano

WorkManager es la solución recomendada por Google para el trabajo en segundo plano. Garantiza la ejecución de tareas en un hilo secundario teniendo en cuenta el estado del dispositivo. A diferencia de Service, WorkManager no bloquea el hilo principal y es resistente a los reinicios de la aplicación. Para BroadcastReceiver, usa goAsync() y pasa el PendingResult a WorkManager.

Kotlin Coroutines con los despachadores adecuados

Ejecuta todas las solicitudes de red, operaciones de base de datos y E/S de archivos con Dispatchers.IO. El hilo principal solo debe actualizar la UI. Usa viewModelScope para la cancelación automática de corutinas cuando se destruye la Activity. Evita runBlocking() en cualquier contexto — bloquea sincrónicamente el hilo actual.

Inicialización perezosa de ContentProvider

Si ContentProvider realiza una inicialización lenta, usa un mecanismo de carga diferida: crea un proveedor que devuelva datos inmediatamente e inicia la inicialización pesada a través de WorkManager con un retardo. Esto evita ANR al iniciar la aplicación, cuando el sistema es más sensible a los retrasos.

Ejemplo de uso correcto de BroadcastReceiver con goAsync en Android:

class FcmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        val pendingResult = goAsync()
        WorkManager.getInstance(context!!)
            .enqueue(OneTimeWorkRequest.from(NotificationWorker::class.java))
        pendingResult.finish()
    }
}

Prevención de ANR en el desarrollo

La mejor manera de combatir los ANR es prevenirlos durante el desarrollo mediante herramientas y decisiones arquitectónicas.

StrictMode para detectar bloqueos del hilo principal

StrictMode con las políticas detectNetwork() y detectDiskReads()/detectDiskWrites() habilitadas identifica posibles ANR durante el desarrollo. En compilaciones Debug, establece penaltyDeath — cualquier infracción causará un bloqueo inmediato y el desarrollador verá el problema antes de hacer commit.

Firebase Performance Monitoring para métricas de producción

Firebase Performance rastrea el tiempo de ejecución de operaciones clave y muestra qué escenarios superan el umbral de ANR. Configura trazados personalizados para cada pantalla y solicitud de red. Si el tiempo de ejecución supera los 3 segundos — es un ANR potencial que requiere optimización.

Pruebas con latencia de red y disco

Simula condiciones lentas: limita la velocidad de la red usando Network Link Conditioner en iOS o Android Emulator. Ralentiza las lecturas de disco mediante la emulación de memoria lenta. ANR a menudo se manifiesta precisamente en estas condiciones; en dispositivos rápidos de desarrollo son invisibles.

• BroadcastReceiver — usa siempre goAsync() para procesamiento de más de 1 segundo
• Service — reemplázalo con WorkManager o CoroutineWorker con un despachador en segundo plano
• ContentProvider — evita la red y la base de datos en onCreate, usa lazy-init con WorkManager
• Hilo de UI — StrictMode con penaltyDeath en Debug, Firebase Performance para monitoreo en producción