ANR no Android: o que é, causas e métodos de correção

O que é ANR no Android

ANR (Application Not Responding) é um mecanismo de proteção ao usuário no Android que é acionado quando o aplicativo para de responder à entrada. O sistema rastreia o tempo de processamento de eventos: se o BroadcastReceiver não concluir onReceive em 10 segundos, o Service não retornar de onCreate em 20 segundos, ou o ContentProvider não responder em 15 segundos — o Android gera um ANR.

Como o ANR aparece para o usuário

Quando ocorre um ANR, o Android exibe um diálogo do sistema sobre todas as janelas: “O aplicativo não responde. Fechar ou aguardar?” O usuário pode fechar o aplicativo ou aguardar sua recuperação. Se os ANRs ocorrerem com frequência, o usuário desinstala o aplicativo. O Google Play considera a taxa de ANR — a porcentagem de sessões com ANR — em seus algoritmos de classificação.

Diferença entre ANR e travamentos no iOS

O iOS não tem um equivalente de ANR com um diálogo do sistema. Em vez disso, a Apple usa Watchdog, que encerra o processo com o código 0x8badf00d. O usuário não vê um diálogo — o aplicativo simplesmente fecha para a tela inicial. Isso torna o ANR no Android mais perceptível para o usuário, mas dá ao sistema mais informações de diagnóstico.

Principais causas de ANR

O ANR ocorre quando o sistema rastreia um tempo limite para um dos quatro tipos de componentes. Cada componente tem seu próprio limite de tempo.

Bloqueio em BroadcastReceiver

BroadcastReceiver é executado na thread principal. Se onReceive iniciar uma requisição de rede síncrona, uma gravação longa no banco de dados, ou aguardar um bloqueio — um ANR ocorre dentro de 10 segundos. Solução: use goAsync() e WorkManager para processamento em segundo plano. Um cenário típico é receber uma notificação Push do FCM e salvar síncronamente no Room.

Operação longa em Service

Service.onCreate e Service.onStartCommand têm um limite de 20 segundos. Se o serviço iniciar uma inicialização pesada (carregar bibliotecas, ler configuração da rede) na thread principal — o ANR é inevitável. Use IntentService (obsoleto) ou WorkManager para execução garantida em segundo plano.

ContentProvider com inicialização lenta

ContentProvider.onCreate é executado antes de Application.onCreate e tem um limite de 15 segundos. Se o provedor realizar uma migração de banco de dados, carregar dicionários, ou inicializar SDK da rede — isso causa ANR na inicialização do aplicativo. Solução: inicialização preguiçosa, descarregar operações pesadas para WorkManager.

• BroadcastReceiver — 10 segundos para onReceive; use goAsync() para processamento em segundo plano
• Service — 20 segundos para onCreate/onStartCommand; use WorkManager ou CoroutineWorker
• ContentProvider — 15 segundos para onCreate; mova a inicialização para Application.onCreate com início atrasado
• Thread da IU — 5 segundos sem processar eventos; qualquer bloqueio superior a 5 segundos desencadeia ANR

Como diagnosticar ANR

O Android fornece várias ferramentas para análise de ANR: desde logs do sistema até bibliotecas especializadas.

Análise de traces.txt

Em cada ANR, o Android salva o arquivo /data/anr/traces.txt com um dump de pilha de todas as threads do aplicativo. Encontre a thread “main” — o último método na pilha indica a causa. Padrões típicos: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Para extrair o arquivo do dispositivo, use adb com privilégios de superusuário.

Firebase Crashlytics com relatórios ANR

Firebase Crashlytics coleta automaticamente ANRs e os exibe no painel com rastreamento. Para Android 11+, os relatórios ANR vêm com a pilha completa da thread principal. A integração requer adicionar uma dependência e inicializar FirebaseApp em Application.onCreate.

Android Studio Profiler com rastreamento de threads

CPU Profiler no Android Studio permite gravar rastreamentos do aplicativo e ver quais métodos consomem tempo de CPU. Ative “Record with method traces” e reproduza o cenário que causa o ANR. A linha do tempo mostrará quais métodos estavam sendo executados na thread principal no momento do travamento.

Exemplo de integração do Firebase Crashlytics para coleta de ANR no 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 corrigir ANR

Corrigir ANR significa principalmente mover todas as operações longas da thread principal para threads secundárias. Vamos ver técnicas específicas para cada tipo de componente.

Usando WorkManager para tarefas em segundo plano

WorkManager é a solução recomendada pelo Google para trabalho em segundo plano. Ele garante a execução da tarefa em uma thread secundária considerando o estado do dispositivo. Ao contrário do Service, o WorkManager não bloqueia a thread principal e é resiliente a reinicializações do aplicativo. Para BroadcastReceiver, use goAsync() e passe o PendingResult para WorkManager.

Kotlin Coroutines com despachantes adequados

Execute todas as requisições de rede, operações de banco de dados e E/S de arquivos com Dispatchers.IO. A thread principal deve apenas atualizar a IU. Use viewModelScope para cancelamento automático de corrotinas quando a Activity for destruída. Evite runBlocking() em qualquer contexto — ele bloqueia síncronamente a thread atual.

Inicialização preguiçosa de ContentProvider

Se o ContentProvider realizar inicialização lenta, use um mecanismo de carregamento preguiçoso: crie um provedor que retorne dados imediatamente e inicie a inicialização pesada através do WorkManager com um atraso. Isso evita ANR na inicialização do aplicativo, quando o sistema é mais sensível a atrasos.

Exemplo de uso correto do BroadcastReceiver com goAsync no 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()
    }
}

Prevenção de ANR no desenvolvimento

A melhor maneira de combater ANRs é preveni-los durante o desenvolvimento através de ferramentas e decisões arquiteturais.

StrictMode para detectar bloqueios da thread principal

StrictMode com as políticas detectNetwork() e detectDiskReads()/detectDiskWrites() habilitadas identifica potenciais ANRs durante o desenvolvimento. Em compilações Debug, defina penaltyDeath — qualquer violação causará uma falha imediata e o desenvolvedor verá o problema antes do commit.

Firebase Performance Monitoring para métricas de produção

Firebase Performance rastreia o tempo de execução de operações chave e mostra quais cenários excedem o limite de ANR. Configure traces personalizados para cada tela e requisição de rede. Se o tempo de execução exceder 3 segundos — é um ANR potencial que requer otimização.

Testes com latência de rede e disco

Simule condições lentas: limite a velocidade da rede usando Network Link Conditioner no iOS ou Android Emulator. Diminua a leitura de disco através da emulação de memória lenta. ANR frequentemente se manifesta precisamente nessas condições; em dispositivos rápidos de desenvolvimento eles são invisíveis.

• BroadcastReceiver — sempre use goAsync() para processamento superior a 1 segundo
• Service — substitua por WorkManager ou CoroutineWorker com um despachante em segundo plano
• ContentProvider — evite rede e banco de dados em onCreate, use lazy-init com WorkManager
• Thread da IU — StrictMode com penaltyDeath em Debug, Firebase Performance para monitoramento em produção