Broadcast Receiver: cos’è, tipi di Broadcast e principio di funzionamento

Cos’è un Broadcast Receiver?

Broadcast Receiver è un componente Android progettato per ricevere ed elaborare messaggi Intent distribuiti dal sistema operativo o da altre applicazioni. A differenza di Activity e Service, Broadcast Receiver non ha interfaccia utente — il suo compito è eseguire un’azione breve al verificarsi di un evento.

Broadcast Receiver funziona attraverso il meccanismo Intent. Il sistema o un’applicazione invia un Intent tramite sendBroadcast o sendOrderedBroadcast, e il sistema operativo lo consegna ai ricevitori registrati. Ogni ricevitore riceve l’Intent nel metodo onReceive, che viene eseguito nel thread principale.

Secondo il Android Compatibility Definition Document, un Broadcast Receiver deve completare onReceive entro 10 secondi — altrimenti il sistema lo considera bloccato e termina il processo. Per attività di lunga durata in background, utilizza JobScheduler o WorkManager avviati dal ricevitore.

Tipi di Broadcast in Android

Android supporta due tipi principali di Broadcast: Normal Broadcast e Ordered Broadcast. La differenza risiede nell’ordine di consegna e nella capacità di interrompere la catena di elaborazione. Inoltre, i Broadcast si dividono in di sistema (generati dal SO) e personalizzati (creati dall’applicazione).

Normal Broadcast

Normal Broadcast viene consegnato a tutti i ricevitori registrati in modo asincrono senza ordine garantito. Il sistema può elaborare questi Broadcast in parallelo — ogni ricevitore riceve l’Intent nel proprio thread. Chiamare abortBroadcast su Normal Broadcast non ha effetto: la consegna ad altri ricevitori non può essere annullata.

Ordered Broadcast

Ordered Broadcast viene consegnato sequenzialmente — a ciascun ricevitore in ordine decrescente dell’attributo android:priority (da 0 a 999). Dopo l’elaborazione, il ricevitore può passare il risultato al successivo tramite setResultExtras o interrompere la catena chiamando abortBroadcast. Viene utilizzato in scenari in cui l’ordine di elaborazione è importante — ad esempio, i ricevitori SMS.

Broadcast di sistema

Android genera molti Broadcast di sistema: ACTION_BOOT_COMPLETED (avvio del dispositivo), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED e altri. Ogni Intent contiene dati aggiuntivi in Extras — livello della batteria, tipo di connessione, nome del pacchetto.

Sticky Broadcast è un tipo deprecato che conservava l’ultimo valore inviato. Invece, utilizza LiveData, StateFlow o SharedPreferences condivise per memorizzare l’ultimo stato.

Registrazione del Broadcast Receiver

Broadcast Receiver può essere registrato in due modi: staticamente tramite AndroidManifest.xml o dinamicamente nel codice tramite registerReceiver. La scelta dipende dallo scenario: la registrazione statica funziona anche se l’applicazione non è in esecuzione, quella dinamica solo finché il componente registrante è attivo.

Registrazione statica

La registrazione statica viene dichiarata nel manifest con il tag <receiver> all’interno di <application>. Per ogni ricevitore, vengono specificati la classe handler e un filtro Intent con le azioni da intercettare. Il sistema carica questi ricevitori al verificarsi di un Broadcast anche se l’applicazione non è in esecuzione.

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

Registrazione dinamica

La registrazione dinamica viene eseguita utilizzando il metodo registerReceiver nel codice di Activity, Service o Fragment. Il ricevitore vive solo finché il componente che lo ha registrato è attivo. Chiama sempre unregisterReceiver in onPause o onDestroy — altrimenti si verifica una perdita di memoria e il sistema può terminare il processo.

Priorità e ordine di elaborazione

Per Ordered Broadcast, l’ordine di consegna è determinato dall’attributo android:priority. Un ricevitore con priorità più alta riceve l’Intent per primo. Se dopo l’elaborazione chiama abortBroadcast, i ricevitori con priorità inferiore non riceveranno l’Intent. Per i ricevitori statici, la priorità viene impostata nel filtro Intent del manifest.

Passaggio di dati tra ricevitori

I ricevitori in Ordered Broadcast possono passare dati al successivo nella catena tramite setResultExtras o setResultData. Ciò consente l’elaborazione in pipeline: il primo ricevitore arricchisce l’Intent con dati aggiuntivi, il secondo li utilizza, il terzo completa la catena. Il metodo getResultExtras legge i dati passati dal ricevitore precedente.

Per Normal Broadcast, l’ordine non è garantito, quindi tutti i ricevitori ricevono l’Intent originale invariato. Se hai bisogno che i ricevitori si influenzino a vicenda, utilizza sendOrderedBroadcast invece di sendBroadcast.

Restrizioni in Android 8 e versioni successive

Android 8 (API 26, Oreo) ha introdotto restrizioni significative sui Broadcast in background. La maggior parte dei Broadcast impliciti — quelli non indirizzati a un’applicazione specifica — non funzionano più con la registrazione statica. Il sistema blocca i ricevitori registrati nel manifest per azioni come CONNECTIVITY_ACTION o ACTION_BATTERY_LOW.

Cosa è cambiato

Google ha fissato un elenco di Broadcast che continuano a funzionare con la registrazione statica: BOOT_COMPLETED, TIME_TICK, Alarm e modifiche ai pacchetti — circa una dozzina di eccezioni in totale. Tutti gli altri Broadcast impliciti ora richiedono la registrazione dinamica tramite Context.registerReceiver, che funziona solo quando l’app è in primo piano.

Alternative a Broadcast Receiver

Per le attività in background che venivano precedentemente gestite tramite Broadcast Receiver, Android raccomanda WorkManager (attività differite con garanzia di esecuzione), JobScheduler (attività periodiche considerando lo stato del dispositivo) e NotificationListenerService (monitoraggio delle notifiche). Questi componenti funzionano senza le restrizioni di Android 8 e sono ottimizzati per il consumo energetico.

Esempio di Broadcast Receiver in Kotlin

Creiamo un Broadcast Receiver per monitorare la connettività di rete. Il ricevitore catturerà il Broadcast CONNECTIVITY_ACTION e registrerà il tipo di connessione. Per Android 8+, lo registreremo dinamicamente poiché si tratta di un Broadcast implicito escluso dalla registrazione statica.

// Broadcast Receiver per il monitoraggio dello stato della rete
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 di connessione: $connectionType")
    }
}

// Registrazione dinamica in 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)
    }
}

Annulla sempre la registrazione del ricevitore in onStop — se l’Activity va in background ma il ricevitore rimane registrato, il sistema non può liberare risorse. Per Service, usa onDestroy. Nei fragment, registra il ricevitore in onStart e annulla la registrazione in onStop, seguendo il ciclo di vita del fragment.