Broadcast Receiver : qu’est-ce que c’est, types de Broadcast et principe de fonctionnement

Qu’est-ce qu’un Broadcast Receiver ?

Broadcast Receiver est un composant Android conçu pour recevoir et traiter les messages Intent distribués par le système d’exploitation ou d’autres applications. Contrairement à Activity et Service, Broadcast Receiver n’a pas d’interface utilisateur — sa tâche est d’exécuter une action courte lorsqu’un événement se produit.

Broadcast Receiver fonctionne via le mécanisme Intent. Le système ou une application envoie un Intent via sendBroadcast ou sendOrderedBroadcast, et le système d’exploitation le livre aux récepteurs enregistrés. Chaque récepteur reçoit l’Intent dans la méthode onReceive, qui s’exécute sur le thread principal.

Selon le Android Compatibility Definition Document, un Broadcast Receiver doit terminer onReceive dans les 10 secondes — sinon le système le considère comme bloqué et termine le processus. Pour les tâches d’arrière-plan longues, utilisez JobScheduler ou WorkManager lancés depuis le récepteur.

Types de Broadcast sur Android

Android prend en charge deux principaux types de Broadcast : Normal Broadcast et Ordered Broadcast. La différence réside dans l’ordre de livraison et la capacité d’interrompre la chaîne de traitement. De plus, les Broadcasts sont divisés en système (générés par l’OS) et personnalisés (créés par l’application).

Normal Broadcast

Normal Broadcast est livré à tous les récepteurs enregistrés de manière asynchrone sans ordre garanti. Le système peut traiter ces Broadcasts en parallèle — chaque récepteur reçoit l’Intent dans son propre thread. Appeler abortBroadcast sur Normal Broadcast n’a aucun effet : la livraison aux autres récepteurs ne peut pas être annulée.

Ordered Broadcast

Ordered Broadcast est livré séquentiellement — à chaque récepteur dans l’ordre décroissant de l’attribut android:priority (de 0 à 999). Après traitement, le récepteur peut passer le résultat au suivant via setResultExtras ou interrompre la chaîne en appelant abortBroadcast. Ceci est utilisé dans les scénarios où l’ordre de traitement est important — par exemple, les récepteurs SMS.

Broadcasts système

Android génère de nombreux Broadcasts système : ACTION_BOOT_COMPLETED (démarrage de l’appareil), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED et autres. Chaque Intent contient des données supplémentaires dans Extras — niveau de batterie, type de connexion, nom du paquet.

Sticky Broadcast est un type obsolète qui conservait la dernière valeur envoyée. À la place, utilisez LiveData, StateFlow ou des SharedPreferences partagées pour stocker le dernier état.

Enregistrement du Broadcast Receiver

Broadcast Receiver peut être enregistré de deux manières : statiquement via AndroidManifest.xml ou dynamiquement dans le code via registerReceiver. Le choix dépend du scénario : l’enregistrement statique fonctionne même si l’application n’est pas en cours d’exécution, l’enregistrement dynamique ne fonctionne que tant que le composant enregistreur est actif.

Enregistrement statique

L’enregistrement statique est déclaré dans le manifeste avec la balise <receiver> à l’intérieur de <application>. Pour chaque récepteur, la classe de gestion et un filtre Intent avec les actions à intercepter sont spécifiés. Le système charge ces récepteurs lors d’un Broadcast même si l’application n’est pas en cours d’exécution.

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

Enregistrement dynamique

L’enregistrement dynamique est effectué à l’aide de la méthode registerReceiver dans le code d’Activity, Service ou Fragment. Le récepteur ne vit que tant que le composant qui l’a enregistré est actif. Appelez toujours unregisterReceiver dans onPause ou onDestroy — sinon une fuite de mémoire se produit et le système peut terminer le processus.

Priorité et ordre de traitement

Pour Ordered Broadcast, l’ordre de livraison est déterminé par l’attribut android:priority. Un récepteur avec une priorité plus élevée reçoit l’Intent en premier. S’il appelle abortBroadcast après traitement, les récepteurs de priorité inférieure ne recevront pas l’Intent. Pour les récepteurs statiques, la priorité est définie dans le filtre Intent du manifeste.

Transfert de données entre récepteurs

Les récepteurs dans Ordered Broadcast peuvent passer des données au suivant dans la chaîne via setResultExtras ou setResultData. Cela permet un traitement en pipeline : le premier récepteur enrichit l’Intent avec des données supplémentaires, le second les utilise, le troisième complète la chaîne. La méthode getResultExtras lit les données transmises par le récepteur précédent.

Pour Normal Broadcast, l’ordre n’est pas garanti, donc tous les récepteurs reçoivent l’Intent original inchangé. Si vous avez besoin que les récepteurs s’influencent mutuellement, utilisez sendOrderedBroadcast au lieu de sendBroadcast.

Restrictions dans Android 8 et versions ultérieures

Android 8 (API 26, Oreo) a introduit des restrictions significatives sur les Broadcasts en arrière-plan. La plupart des Broadcasts implicites — ceux non adressés à une application spécifique — ne fonctionnent plus avec l’enregistrement statique. Le système bloque les récepteurs enregistrés dans le manifeste pour des actions telles que CONNECTIVITY_ACTION ou ACTION_BATTERY_LOW.

Ce qui a changé

Google a fixé une liste de Broadcasts qui continuent de fonctionner avec l’enregistrement statique : BOOT_COMPLETED, TIME_TICK, Alarm et les changements de paquet — environ une douzaine d’exceptions au total. Tous les autres Broadcasts implicites nécessitent désormais un enregistrement dynamique via Context.registerReceiver, qui ne fonctionne que lorsque l’application est au premier plan.

Alternatives à Broadcast Receiver

Pour les tâches d’arrière-plan qui étaient auparavant traitées via Broadcast Receiver, Android recommande WorkManager (tâches différées avec garantie d’exécution), JobScheduler (tâches périodiques tenant compte de l’état de l’appareil) et NotificationListenerService (surveillance des notifications). Ces composants fonctionnent sans les restrictions d’Android 8 et sont optimisés pour la consommation d’énergie.

Exemple de Broadcast Receiver en Kotlin

Créons un Broadcast Receiver pour suivre la connectivité réseau. Le récepteur capturera le Broadcast CONNECTIVITY_ACTION et enregistrera le type de connexion. Pour Android 8+, nous l’enregistrerons dynamiquement car il s’agit d’un Broadcast implicite exclu de l’enregistrement statique.

// Broadcast Receiver pour le suivi de l’état du réseau
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", "Type de connexion : $connectionType")
    }
}

// Enregistrement dynamique dans 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)
    }
}

Annulez toujours l’enregistrement du récepteur dans onStop — si l’Activity passe en arrière-plan mais que le récepteur reste enregistré, le système ne peut pas libérer les ressources. Pour Service, utilisez onDestroy. Dans les fragments, enregistrez le récepteur dans onStart et annulez l’enregistrement dans onStop, en suivant le cycle de vie du fragment.