Broadcast Receiver: o que é, tipos de Broadcast e princípio de funcionamento

O que é um Broadcast Receiver?

Broadcast Receiver é um componente Android projetado para receber e processar mensagens Intent distribuídas pelo sistema operacional ou outros aplicativos. Ao contrário de Activity e Service, o Broadcast Receiver não possui interface de usuário — sua tarefa é executar uma ação curta quando um evento ocorre.

O Broadcast Receiver funciona através do mecanismo Intent. O sistema ou um aplicativo envia um Intent via sendBroadcast ou sendOrderedBroadcast, e o sistema operacional o entrega aos receptores registrados. Cada receptor recebe o Intent no método onReceive, que executa na thread principal.

De acordo com o Android Compatibility Definition Document, um Broadcast Receiver deve completar onReceive em 10 segundos — caso contrário, o sistema o considera travado e encerra o processo. Para tarefas longas em segundo plano, use JobScheduler ou WorkManager iniciados a partir do receptor.

Tipos de Broadcast no Android

O Android suporta dois tipos principais de Broadcast: Normal Broadcast e Ordered Broadcast. A diferença está na ordem de entrega e na capacidade de interromper a cadeia de processamento. Além disso, os Broadcasts são divididos em do sistema (gerados pelo SO) e personalizados (criados pelo aplicativo).

Normal Broadcast

Normal Broadcast é entregue a todos os receptores registrados de forma assíncrona sem ordem garantida. O sistema pode processar esses Broadcasts em paralelo — cada receptor recebe o Intent em sua própria thread. Chamar abortBroadcast em Normal Broadcast não tem efeito: a entrega a outros receptores não pode ser cancelada.

Ordered Broadcast

Ordered Broadcast é entregue sequencialmente — a cada receptor em ordem decrescente do atributo android:priority (de 0 a 999). Após o processamento, o receptor pode passar o resultado para o próximo via setResultExtras ou interromper a cadeia chamando abortBroadcast. Isso é usado em cenários onde a ordem de processamento é importante — por exemplo, receptores de SMS.

Broadcasts do sistema

O Android gera muitos Broadcasts do sistema: ACTION_BOOT_COMPLETED (inicialização do dispositivo), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED e outros. Cada Intent contém dados adicionais em Extras — nível da bateria, tipo de conexão, nome do pacote.

Sticky Broadcast é um tipo obsoleto que mantinha o último valor enviado. Em vez disso, use LiveData, StateFlow ou SharedPreferences compartilhadas para armazenar o último estado.

Registro do Broadcast Receiver

Broadcast Receiver pode ser registrado de duas formas: estaticamente via AndroidManifest.xml ou dinamicamente no código via registerReceiver. A escolha depende do cenário: o registro estático funciona mesmo se o aplicativo não estiver em execução, o registro dinâmico só funciona enquanto o componente registrador estiver ativo.

Registro estático

O registro estático é declarado no manifesto com a tag <receiver> dentro de <application>. Para cada receptor, são especificados a classe de manipulação e um filtro Intent com as ações a interceptar. O sistema carrega esses receptores quando ocorre um Broadcast mesmo se o aplicativo não estiver em execução.

<!-- Static Broadcast Receiver registration in manifest -->
<receiver android:name=".BootReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

Registro dinâmico

O registro dinâmico é realizado usando o método registerReceiver no código de Activity, Service ou Fragment. O receptor vive apenas enquanto o componente que o registrou estiver vivo. Sempre chame unregisterReceiver em onPause ou onDestroy — caso contrário, ocorre vazamento de memória e o sistema pode encerrar o processo.

Prioridade e ordem de processamento

Para Ordered Broadcast, a ordem de entrega é determinada pelo atributo android:priority. Um receptor com prioridade mais alta recebe o Intent primeiro. Se ele chamar abortBroadcast após o processamento, receptores com prioridade mais baixa não receberão o Intent. Para receptores estáticos, a prioridade é definida no filtro Intent do manifesto.

Transferência de dados entre receptores

Receptores em Ordered Broadcast podem passar dados para o próximo na cadeia via setResultExtras ou setResultData. Isso permite processamento em pipeline: o primeiro receptor enriquece o Intent com dados adicionais, o segundo os utiliza, o terceiro completa a cadeia. O método getResultExtras lê os dados passados pelo receptor anterior.

Para Normal Broadcast, a ordem não é garantida, então todos os receptores recebem o Intent original inalterado. Se você precisar que os receptores se afetem mutuamente, use sendOrderedBroadcast em vez de sendBroadcast.

Restrições no Android 8 e versões posteriores

Android 8 (API 26, Oreo) introduziu restrições significativas em Broadcasts em segundo plano. A maioria dos Broadcasts implícitos — aqueles não direcionados a um aplicativo específico — não funcionam mais com registro estático. O sistema bloqueia receptores registrados no manifesto para ações como CONNECTIVITY_ACTION ou ACTION_BATTERY_LOW.

O que mudou

O Google fixou uma lista de Broadcasts que continuam funcionando com registro estático: BOOT_COMPLETED, TIME_TICK, Alarm e alterações de pacote — cerca de uma dúzia de exceções no total. Todos os outros Broadcasts implícitos agora exigem registro dinâmico via Context.registerReceiver, que só funciona quando o aplicativo está em primeiro plano.

Alternativas ao Broadcast Receiver

Para tarefas em segundo plano que antes eram tratadas via Broadcast Receiver, o Android recomenda WorkManager (tarefas adiadas com garantia de execução), JobScheduler (tarefas periódicas considerando o estado do dispositivo) e NotificationListenerService (monitoramento de notificações). Esses componentes funcionam sem as restrições do Android 8 e são otimizados para consumo de energia.

Exemplo de Broadcast Receiver em Kotlin

Vamos criar um Broadcast Receiver para rastrear a conectividade de rede. O receptor capturará o Broadcast CONNECTIVITY_ACTION e registrará o tipo de conexão. Para Android 8+, vamos registrá-lo dinamicamente, pois é um Broadcast implícito excluído do registro estático.

// Broadcast Receiver para rastreamento de estado da rede
class NetworkReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        val network = cm.activeNetwork
        val caps = cm.getNetworkCapabilities(network)

        val connectionType = when {
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) == true -> "WiFi"
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) == true -> "Cellular"
            else -> "Disconnected"
        }

        Log.d("NetworkReceiver", "Tipo de conexão: $connectionType")
    }
}

// Registro dinâmico em Activity
class MainActivity : AppCompatActivity() {

    private val networkReceiver = NetworkReceiver()

    override fun onStart() {
        super.onStart()
        val filter = IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        registerReceiver(networkReceiver, filter)
    }

    override fun onStop() {
        super.onStop()
        unregisterReceiver(networkReceiver)
    }
}

Sempre cancele o registro do receptor em onStop — se a Activity for para segundo plano mas o receptor permanecer registrado, o sistema não pode liberar recursos. Para Service, use onDestroy. Em fragments, registre o receptor em onStart e cancele o registro em onStop, seguindo o ciclo de vida do fragment.