Broadcast Receiver: Was es ist, Arten von Broadcasts und Funktionsprinzip

Was ist ein Broadcast Receiver?

Broadcast Receiver ist eine Android-Komponente, die zum Empfangen und Verarbeiten von Intent-Nachrichten entwickelt wurde, die vom Betriebssystem oder anderen Anwendungen verteilt werden. Im Gegensatz zu Activity und Service hat Broadcast Receiver keine Benutzeroberfläche – seine Aufgabe ist es, bei Eintreten eines Ereignisses eine kurze Aktion auszuführen.

Broadcast Receiver arbeitet über den Intent-Mechanismus. Das System oder eine Anwendung sendet einen Intent über sendBroadcast oder sendOrderedBroadcast, und das Betriebssystem stellt ihn registrierten Empfängern zu. Jeder Empfänger erhält den Intent in der onReceive-Methode, die im Hauptthread ausgeführt wird.

Laut dem Android Compatibility Definition Document muss ein Broadcast Receiver onReceive innerhalb von 10 Sekunden abschließen – andernfalls betrachtet das System ihn als hängend und beendet den Prozess. Für langlaufende Hintergrundaufgaben verwenden Sie JobScheduler oder WorkManager, die vom Empfänger gestartet werden.

Arten von Broadcasts in Android

Android unterstützt zwei Hauptarten von Broadcasts: Normal Broadcast und Ordered Broadcast. Der Unterschied liegt in der Zustellreihenfolge und der Möglichkeit, die Verarbeitungskette zu unterbrechen. Darüber hinaus werden Broadcasts in System- (vom OS erzeugt) und benutzerdefinierte (von der Anwendung erstellt) unterteilt.

Normal Broadcast

Normal Broadcast wird allen registrierten Empfängern asynchron und ohne garantierte Reihenfolge zugestellt. Das System kann solche Broadcasts parallel verarbeiten – jeder Empfänger erhält den Intent in seinem eigenen Thread. Der Aufruf von abortBroadcast bei Normal Broadcast hat keine Wirkung: Die Zustellung an andere Empfänger kann nicht abgebrochen werden.

Ordered Broadcast

Ordered Broadcast wird sequenziell zugestellt – an jeden Empfänger in absteigender Reihenfolge des android:priority-Attributs (von 0 bis 999). Nach der Verarbeitung kann der Empfänger das Ergebnis über setResultExtras an den nächsten weitergeben oder die Kette durch Aufruf von abortBroadcast unterbrechen. Dies wird für Szenarien verwendet, bei denen die Verarbeitungsreihenfolge wichtig ist – zum Beispiel SMS-Empfänger.

System-Broadcasts

Android erzeugt viele System-Broadcasts: ACTION_BOOT_COMPLETED (Gerätestart), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED und andere. Jeder Intent enthält zusätzliche Daten in Extras – Akkustand, Verbindungstyp, Paketname.

Sticky Broadcast ist ein veralteter Typ, der den letzten gesendeten Wert behielt. Verwenden Sie stattdessen LiveData, StateFlow oder gemeinsame SharedPreferences, um den letzten Zustand zu speichern.

Broadcast Receiver Registrierung

Broadcast Receiver kann auf zwei Arten registriert werden: statisch über AndroidManifest.xml oder dynamisch im Code über registerReceiver. Die Wahl hängt vom Szenario ab: Die statische Registrierung funktioniert auch wenn die Anwendung nicht ausgeführt wird, die dynamische Registrierung nur solange die registrierende Komponente aktiv ist.

Statische Registrierung

Die statische Registrierung wird im Manifest mit dem <receiver>-Tag innerhalb von <application> deklariert. Für jeden Empfänger werden die Handler-Klasse und ein Intent-Filter mit den abzufangenden Aktionen angegeben. Das System lädt solche Empfänger bei Eintreten eines Broadcasts, auch wenn die Anwendung nicht ausgeführt wird.

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

Dynamische Registrierung

Die dynamische Registrierung erfolgt mit der registerReceiver-Methode im Code von Activity, Service oder Fragment. Der Empfänger lebt nur so lange wie die Komponente, die ihn registriert hat. Rufen Sie in onPause oder onDestroy immer unregisterReceiver auf – andernfalls tritt ein Speicherleck auf und das System kann den Prozess beenden.

Priorität und Verarbeitungsreihenfolge

Für Ordered Broadcast wird die Zustellreihenfolge durch das android:priority-Attribut bestimmt. Ein Empfänger mit höherer Priorität erhält den Intent zuerst. Wenn er nach der Verarbeitung abortBroadcast aufruft, erhalten Empfänger mit niedrigerer Priorität den Intent nicht. Für statische Empfänger wird die Priorität im Intent-Filter des Manifests festgelegt.

Datenübergabe zwischen Empfängern

Empfänger in Ordered Broadcast können Daten über setResultExtras oder setResultData an den nächsten in der Kette übergeben. Dies ermöglicht eine Pipeline-Verarbeitung: Der erste Empfänger reichert den Intent mit zusätzlichen Daten an, der zweite verwendet sie, der dritte schließt die Kette ab. Die getResultExtras-Methode liest vom vorherigen Empfänger übergebene Daten.

Bei Normal Broadcast ist die Reihenfolge nicht garantiert, daher erhalten alle Empfänger den ursprünglichen Intent unverändert. Wenn Empfänger sich gegenseitig beeinflussen sollen, verwenden Sie sendOrderedBroadcast anstelle von sendBroadcast.

Einschränkungen in Android 8 und neuer

Android 8 (API 26, Oreo) führte bedeutende Einschränkungen für Hintergrund-Broadcasts ein. Die meisten impliziten Broadcasts – solche, die nicht an eine bestimmte Anwendung adressiert sind – funktionieren mit statischer Registrierung nicht mehr. Das System blockiert im Manifest registrierte Empfänger für Aktionen wie CONNECTIVITY_ACTION oder ACTION_BATTERY_LOW.

Was hat sich geändert

Google hat eine Liste von Broadcasts festgelegt, die weiterhin mit statischer Registrierung funktionieren: BOOT_COMPLETED, TIME_TICK, Alarm und Paketänderungen – insgesamt etwa ein Dutzend Ausnahmen. Alle anderen impliziten Broadcasts erfordern jetzt eine dynamische Registrierung über Context.registerReceiver, die nur funktioniert, wenn die App im Vordergrund ist.

Alternativen zu Broadcast Receiver

Für Hintergrundaufgaben, die früher über Broadcast Receiver erledigt wurden, empfiehlt Android WorkManager (verzögerte Aufgaben mit Ausführungsgarantie), JobScheduler (periodische Aufgaben unter Berücksichtigung des Gerätezustands) und NotificationListenerService (Benachrichtigungsüberwachung). Diese Komponenten arbeiten ohne Android 8-Einschränkungen und sind für den Energieverbrauch optimiert.

Broadcast Receiver Beispiel in Kotlin

Erstellen wir einen Broadcast Receiver zur Überwachung der Netzwerkkonnektivität. Der Empfänger fängt den CONNECTIVITY_ACTION-Broadcast und protokolliert den Verbindungstyp. Für Android 8+ registrieren wir ihn dynamisch, da es sich um einen impliziten Broadcast handelt, der von der statischen Registrierung ausgeschlossen ist.

// Broadcast Receiver zur Netzwerkzustandsverfolgung
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", "Verbindungstyp: $connectionType")
    }
}

// Dynamische Registrierung 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)
    }
}

Heben Sie die Registrierung des Empfängers immer in onStop auf – wenn die Activity in den Hintergrund geht, der Empfänger aber registriert bleibt, kann das System keine Ressourcen freigeben. Für Service verwenden Sie onDestroy. In Fragmenten registrieren Sie den Empfänger in onStart und heben die Registrierung in onStop auf, dem Fragment-Lebenszyklus folgend.