Broadcast Receiver: qué es, tipos de Broadcast y principio de funcionamiento

¿Qué es un Broadcast Receiver?

Broadcast Receiver es un componente de Android diseñado para recibir y procesar mensajes Intent distribuidos por el sistema operativo u otras aplicaciones. A diferencia de Activity y Service, Broadcast Receiver no tiene interfaz de usuario — su tarea es ejecutar una acción breve cuando ocurre un evento.

Broadcast Receiver funciona a través del mecanismo Intent. El sistema o una aplicación envía un Intent mediante sendBroadcast o sendOrderedBroadcast, y el sistema operativo lo entrega a los receptores registrados. Cada receptor recibe el Intent en el método onReceive, que se ejecuta en el hilo principal.

Según el Android Compatibility Definition Document, un Broadcast Receiver debe completar onReceive en menos de 10 segundos — de lo contrario, el sistema lo considera bloqueado y finaliza el proceso. Para tareas prolongadas en segundo plano, use JobScheduler o WorkManager iniciados desde el receptor.

Tipos de Broadcast en Android

Android admite dos tipos principales de Broadcast: Normal Broadcast y Ordered Broadcast. La diferencia radica en el orden de entrega y la capacidad de interrumpir la cadena de procesamiento. Además, los Broadcast se dividen en del sistema (generados por el SO) y personalizados (creados por la aplicación).

Normal Broadcast

Normal Broadcast se entrega a todos los receptores registrados de forma asíncrona sin orden garantizado. El sistema puede procesar estos Broadcast en paralelo — cada receptor recibe el Intent en su propio hilo. Llamar a abortBroadcast en Normal Broadcast no tiene efecto: la entrega a otros receptores no se puede cancelar.

Ordered Broadcast

Ordered Broadcast se entrega secuencialmente — a cada receptor en orden descendente del atributo android:priority (de 0 a 999). Después del procesamiento, el receptor puede pasar el resultado al siguiente mediante setResultExtras o interrumpir la cadena llamando a abortBroadcast. Esto se utiliza en escenarios donde el orden de procesamiento es importante, como en los receptores de SMS.

Broadcast del sistema

Android genera muchos Broadcast del sistema: ACTION_BOOT_COMPLETED (inicio del dispositivo), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED y otros. Cada Intent contiene datos adicionales en Extras — nivel de batería, tipo de conexión, nombre del paquete.

Sticky Broadcast es un tipo obsoleto que conservaba el último valor enviado. En su lugar, use LiveData, StateFlow o SharedPreferences compartidas para almacenar el último estado.

Registro de Broadcast Receiver

Broadcast Receiver se puede registrar de dos formas: estáticamente mediante AndroidManifest.xml o dinámicamente en código mediante registerReceiver. La elección depende del escenario: el registro estático funciona incluso si la aplicación no se está ejecutando, el registro dinámico solo funciona mientras el componente que lo registra esté activo.

Registro estático

El registro estático se declara en el manifiesto con la etiqueta <receiver> dentro de <application>. Para cada receptor, se especifican la clase de manejo y un filtro Intent con las acciones a interceptar. El sistema carga estos receptores cuando ocurre un Broadcast incluso si la aplicación no se está ejecutando.

<!-- 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

El registro dinámico se realiza mediante el método registerReceiver en código de Activity, Service o Fragment. El receptor vive solo mientras el componente que lo registró esté activo. Siempre llame a unregisterReceiver en onPause o onDestroy — de lo contrario, se produce una fuga de memoria y el sistema puede finalizar el proceso.

Prioridad y orden de procesamiento

Para Ordered Broadcast, el orden de entrega se determina mediante el atributo android:priority. Un receptor con mayor prioridad recibe el Intent primero. Si después del procesamiento llama a abortBroadcast, los receptores con menor prioridad no recibirán el Intent. Para receptores estáticos, la prioridad se establece en el filtro Intent del manifiesto.

Transferencia de datos entre receptores

Los receptores en Ordered Broadcast pueden pasar datos al siguiente en la cadena mediante setResultExtras o setResultData. Esto permite el procesamiento en tubería: el primer receptor enriquece el Intent con datos adicionales, el segundo los usa, el tercero completa la cadena. El método getResultExtras lee los datos pasados por el receptor anterior.

Para Normal Broadcast, el orden no está garantizado, por lo que todos los receptores reciben el Intent original sin cambios. Si necesita que los receptores se afecten entre sí, use sendOrderedBroadcast en lugar de sendBroadcast.

Restricciones en Android 8 y versiones posteriores

Android 8 (API 26, Oreo) introdujo restricciones significativas en los Broadcast en segundo plano. La mayoría de los Broadcast implícitos — aquellos no dirigidos a una aplicación específica — ya no funcionan con registro estático. El sistema bloquea los receptores registrados en el manifiesto para acciones como CONNECTIVITY_ACTION o ACTION_BATTERY_LOW.

Qué cambió

Google ha fijado una lista de Broadcast que continúan funcionando con registro estático: BOOT_COMPLETED, TIME_TICK, Alarm y cambios de paquete — aproximadamente una docena de excepciones en total. Todos los demás Broadcast implícitos ahora requieren registro dinámico mediante Context.registerReceiver, que solo funciona cuando la aplicación está en primer plano.

Alternativas a Broadcast Receiver

Para tareas en segundo plano que antes se manejaban mediante Broadcast Receiver, Android recomienda WorkManager (tareas diferidas con garantía de ejecución), JobScheduler (tareas periódicas considerando el estado del dispositivo) y NotificationListenerService (monitoreo de notificaciones). Estos componentes funcionan sin las restricciones de Android 8 y están optimizados para el consumo de energía.

Ejemplo de Broadcast Receiver en Kotlin

Creemos un Broadcast Receiver para rastrear la conectividad de red. El receptor capturará el Broadcast CONNECTIVITY_ACTION y registrará el tipo de conexión. Para Android 8+, lo registraremos dinámicamente ya que es un Broadcast implícito excluido del registro estático.

// Broadcast Receiver para seguimiento del estado de la red
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 conexión: $connectionType")
    }
}

// Registro dinámico en 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)
    }
}

Siempre anule el registro del receptor en onStop — si la Activity pasa a segundo plano pero el receptor permanece registrado, el sistema no puede liberar recursos. Para Service, use onDestroy. En fragmentos, registre el receptor en onStart y anúle el registro en onStop, siguiendo el ciclo de vida del fragmento.