Crash Reporting no desenvolvimento móvel — o que é, serviços e configuração

O que é Crash Reporting?

Crash Reporting é o processo de coleta automática de informações técnicas sobre falhas do aplicativo e transmissão centralizada ao servidor para análise. Ao contrário do registro, o crash-reporting captura especificamente situações de emergência — o momento em que o aplicativo foi encerrado à força pelo sistema ou SO.

Cada relatório de falha contém três componentes principais: tipo de exceção (NullPointerException, SIGSEGV, NSInternalInconsistencyException), pilha de chamadas completa com números de linha e informações do ambiente — versão do SO, modelo do dispositivo, tamanho da memória livre. De acordo com Sentry Engineering, 2024, a combinação desses três elementos permite reproduzir e corrigir 85% dos erros críticos.

Sistemas modernos de crash-reporting estendem a funcionalidade além das falhas comuns. Firebase Crashlytics agrupa automaticamente falhas recorrentes em issues, Sentry rastreia regressões entre versões e Bugsnag mostra o caminho do usuário até o erro. Todos os três serviços suportam iOS, Android, React Native e Flutter.

De acordo com Google I/O 2024, aplicativos sem crash-reporting gastam em média 3–5 dias úteis diagnosticando um único erro crítico, enquanto com Crashlytics leva 15–30 minutos. A economia de tempo excede 90% para cada incidente.

Como funciona o sistema de coleta de relatórios de falha

Arquitetura do sistema crash-reporting consiste em três camadas: SDK cliente instalado no aplicativo, API do servidor para receber e processar relatórios e painel web para análise. O SDK cliente intercepta exceções não tratadas, serializa-as em JSON e as envia ao servidor na próxima inicialização do aplicativo.

O envio do relatório de falha ocorre de forma assíncrona após reiniciar o aplicativo. Este é um ponto fundamental: no momento da falha, o aplicativo não pode garantir a transmissão bem-sucedida de dados pela rede. O SDK grava o relatório no armazenamento local e, na próxima inicialização, o envia por uma thread em segundo plano. De acordo com Firebase Engineering, 2024, essa abordagem garante a entrega de 99.7% dos relatórios de falha.

Para exceções não fatais (exceções tratadas dentro de try-catch), o SDK envia o relatório imediatamente já que o aplicativo continua funcionando. Relatórios não fatais contêm os mesmos dados de uma falha, mas não interrompem a sessão do usuário. Isso é especialmente útil para rastrear erros de solicitações de API, validação de dados e lógica de negócios.

Agrupamento de falhas — um algoritmo do servidor que mescla falhas idênticas com base em um hash dos últimos 5–10 quadros da pilha. Isso permite ao desenvolvedor ver não 1000 relatórios individuais, mas um issue com 1000 ocorrências em diferentes dispositivos e versões do SO.

Firebase Crashlytics: integração e recursos

Firebase Crashlytics é o serviço de crash-reporting mais popular para aplicativos móveis, usado em mais de 3 milhões de projetos em todo o mundo. O plano gratuito inclui relatórios ilimitados, integração com Google Analytics e agrupamento automático de falhas.

Integração do Crashlytics no Android

Conexão Crashlytics no Android é mínima: adicione a dependência no build.gradle e inicialize o SDK no Application.onCreate. O Crashlytics define automaticamente seu próprio Thread.setDefaultUncaughtExceptionHandler, interceptando todas as exceções não tratadas.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

Recurso principal do Crashlytics — chaves e logs personalizados. O desenvolvedor pode adicionar até 64 pares chave-valor a cada relatório de falha: estado da tela, plano selecionado, nível do usuário. Mensagens de log personalizadas também estão disponíveis, que aparecem no relatório em ordem cronológica.

Velocity Alert — detecção automática de regressões

Velocity Alert é um recurso do Crashlytics que monitora aumentos bruscos na quantidade de falhas para um issue específico. Se após uma nova versão o número de falhas exceder um limite, a equipe recebe uma notificação push e e-mail 5–15 minutos antes das reclamações em massa dos usuários.

Configuração do limite de ativação: 2x em 1 hora para issues críticos. De acordo com Google, 2024, equipes com Velocity Alert ativado lançam versões hotfix em média 40% mais rápido que equipes que dependem de monitoramento manual do painel.

Integração do Crashlytics no iOS

No iOS o SDK do Crashlytics é integrado via CocoaPods ou Swift Package Manager. O SDK intercepta tanto exceções Objective-C (através de NSSetUncaughtExceptionHandler) quanto sinais do SO (SIGSEGV, SIGABRT) através de seu próprio manipulador de exceções mach.

De acordo com Apple Developer, 2024, o Crashlytics para iOS lida com até 98% de todos os tipos de falhas, incluindo erros de memória de baixo nível que não são detectados por ferramentas padrão. Isso torna o Crashlytics o padrão de facto para desenvolvimento iOS.

Sentry e Bugsnag: plataformas alternativas

Sentry é uma plataforma open-source de monitoramento de erros que suporta 80+ linguagens e frameworks. Ao contrário do Crashlytics, o Sentry é voltado para desenvolvedores backend, mas fornece SDKs completos para iOS, Android, React Native e Flutter.

A principal vantagem do Sentry é o Performance Monitoring em um único painel. Os desenvolvedores veem não apenas as falhas, mas também as transações que levaram a elas: requisições de rede lentas, congelamentos de UI, operações longas de banco de dados. De acordo com Sentry, 2024, 40% das falhas têm problemas de desempenho precedentes que passam despercebidos sem essa abordagem.

Bugsnag difere em sua abordagem de agrupamento de erros — em vez da pilha de chamadas, ele analisa a jornada do usuário. Cada relatório de falha contém a sequência de telas e ações do usuário que levaram ao erro. Isso é especialmente útil para processos de negócios complexos: realização de pedidos, registro, pagamento.

Os custos dos serviços variam: Crashlytics é gratuito dentro do Firebase, Sentry oferece um plano gratuito para 5000 eventos por mês, Bugsnag a partir de $29 por mês. As três plataformas fornecem SDKs de código aberto. A escolha do serviço depende do tamanho da equipe, orçamento e requisitos de segurança de dados.

Crash Reporting no iOS: características e NSException

Particularidade do iOS — arquitetura de tratamento de erros em múltiplas camadas. Os SDKs de crash-reporting devem interceptar exceções Objective-C (NSException), erros Swift (Error), sinais POSIX (SIGSEGV, SIGBUS) e exceções mach. Cada tipo requer um mecanismo de interceptação separado.

NSException é o tipo mais simples de interceptar via NSSetUncaughtExceptionHandler. No entanto, de acordo com Apple, 2024, apenas 30% das falhas em aplicativos Swift modernos são NSException. Os 70% restantes são sinais do SO e erros de runtime do Swift, que requerem um mecanismo de manipulador de exceções mach.

Desenvolvedores iOS devem testar o crash-reporting através de geração local de falhas de diferentes tipos: __builtin_trap() para sinais, [NSException raise:...] para exceções, fatalError() para Swift. Só assim é possível garantir que o SDK cobre todos os tipos de falhas.

Crash Reporting no Android: ANR e falhas nativas

Android adiciona dois tipos específicos de falhas que não existem no iOS: ANR (Application Not Responding) e falha nativa em código C/C++. ANR ocorre quando a thread da UI está bloqueada por mais de 5 segundos — o sistema mostra um diálogo "O aplicativo não está respondendo" e sugere fechá-lo.

O Thread.setDefaultUncaughtExceptionHandler padrão não intercepta ANR, já que não é uma exceção, mas um sinal do ActivityManager. Para rastrear ANR, Crashlytics e Sentry usam uma thread watchdog em segundo plano que verifica a capacidade de resposta da thread da UI a cada 5 segundos. De acordo com Firebase, 2024, 15% de todos os problemas no Android são ANR, não falhas.

Falhas nativas no Android ocorrem em código C/C++ executado via JNI (Java Native Interface). Essas falhas não são exceções Java e não são interceptadas por Thread.setDefaultUncaughtExceptionHandler. Para seu tratamento, são usados Google Breakpad ou Crashpad, que instalam manipuladores sigaction para os sinais SIGSEGV, SIGABRT, SIGBUS.

De acordo com Google I/O 2024, o número de falhas nativas está crescendo com a disseminação de motores de jogos (Unity, Unreal Engine) e bibliotecas de visão computacional (ML Kit, OpenCV). Recomenda-se que desenvolvedores de aplicativos híbridos sempre conectem o crash-reporting nativo.