Notification Runtime Permission – Benachrichtigungen richtig anfragen

Seit Android 13 entscheiden Nutzer selbst, ob eine App überhaupt Benachrichtigungen senden darf. Was früher automatisch gewährt wurde, erfordert heute einen expliziten System-Dialog – und der Zeitpunkt, an dem du diesen Dialog zeigst, ist mindestens genauso wichtig wie die technische Implementierung dahinter.

Was ist das?

POST_NOTIFICATIONS ist eine Laufzeitberechtigung (Runtime Permission), die Android mit Version 13 (API Level 33) eingeführt hat. Vor Android 13 erhielten Apps beim Erstellen eines NotificationChannel automatisch das Recht, Benachrichtigungen zu senden. Nutzer konnten sie ausschließlich nachträglich in den Systemeinstellungen deaktivieren – ein passiver Opt-out-Mechanismus.

Mit Android 13 kehrte sich das Prinzip um: Die Berechtigung muss aktiv vom Nutzer gewährt werden, analog zu Kamera, Mikrofon oder Standort. Lehnt der Nutzer ab, ignoriert das Betriebssystem alle NotificationManager-Aufrufe still und ohne Fehlermeldung. Deine App bekommt keinerlei Rückmeldung darüber, dass keine Benachrichtigung zugestellt wurde.

Für Apps mit targetSdkVersion 32 oder niedriger, die auf einem Android-13-Gerät laufen, zeigt das Betriebssystem beim ersten Erstellen eines Notification Channels einmalig automatisch den Dialog. Sobald du auf targetSdkVersion 33 oder höher aktualisierst, liegt die gesamte Kontrolle bei dir: Wann du fragst, wie du den Nutzer vorbereitest und wie du mit einer Ablehnung umgehst.

Wie funktioniert es?

Die Berechtigung folgt dem Standard-Laufzeitpermission-Flow aus dem Jetpack Activity Result API. Der Ablauf besteht aus vier Schritten:

1. Du deklarierst POST_NOTIFICATIONS im Manifest.
2. Zur Laufzeit prüfst du mit ContextCompat.checkSelfPermission(), ob die Berechtigung bereits erteilt ist.
3. Optional wertest du shouldShowRequestPermissionRationale() aus: Gibt die Methode true zurück, hat der Nutzer den Dialog bereits einmal abgelehnt – zeige in diesem Fall zuerst eine eigene Erklärung, bevor du den System-Dialog öffnest.
4. Du startest den Dialog mit einem ActivityResultLauncher und reagierst im Callback auf das Ergebnis.

Android verwaltet intern einen Zähler für Ablehnungen. Lehnt der Nutzer zweimal ab – oder aktiviert er einmalig die Checkbox „Nicht mehr fragen” –, gibt shouldShowRequestPermissionRationale() dauerhaft false zurück, und der System-Dialog erscheint nicht mehr. Ab diesem Zeitpunkt ist die einzige Möglichkeit, die Berechtigung zu erhalten, das manuelle Öffnen der App-Einstellungen durch den Nutzer.

Wichtig: Dieser Zustand ist nicht dasselbe wie eine erteilte Berechtigung. Du musst explizit zwischen „noch nie gefragt”, „abgelehnt, kann erneut fragen” und „dauerhaft abgelehnt” unterscheiden und jeden Fall gesondert behandeln.

In der Praxis

Der entscheidende Gestaltungshinweis lautet: Zeige den Dialog nicht beim App-Start, sondern erst in dem Moment, in dem der Nutzer aktiv eine Funktion nutzt, die von Benachrichtigungen abhängt – etwa das Aktivieren von Kurs-Erinnerungen in einer Lern-App oder das Abonnieren von Lieferstatus-Updates in einer E-Commerce-App.

class MainActivity : AppCompatActivity() {

    private val requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted ->
            if (granted) {
                enableNotifications()
            } else {
                val canAskAgain = shouldShowRequestPermissionRationale(
                    Manifest.permission.POST_NOTIFICATIONS
                )
                if (!canAskAgain) {
                    showSettingsHint()
                }
            }
        }

    fun askForNotificationPermission() {
        when {
            ContextCompat.checkSelfPermission(
                this, Manifest.permission.POST_NOTIFICATIONS
            ) == PackageManager.PERMISSION_GRANTED -> {
                enableNotifications()
            }
            shouldShowRequestPermissionRationale(
                Manifest.permission.POST_NOTIFICATIONS
            ) -> {
                showRationaleDialogThenRequest()
            }
            else -> {
                requestPermissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS)
            }
        }
    }

    private fun showSettingsHint() {
        val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).apply {
            data = Uri.fromParts("package", packageName, null)
        }
        startActivity(intent)
    }
}

Vergiss nicht, die Berechtigung im Manifest zu deklarieren – ohne diesen Eintrag wirft das System beim Aufruf eine SecurityException:

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

Die häufigste Stolperfalle: zu früher Dialog

Der mit Abstand häufigste Fehler ist ein Berechtigungsdialog, der unmittelbar beim ersten App-Start erscheint – bevor der Nutzer überhaupt verstanden hat, welchen Mehrwert die App bietet. Der Nutzer kennt deine App noch nicht, hat kein Vertrauen aufgebaut und lehnt reflexartig ab. Hast du diese Chance erst einmal verpasst, kannst du den Dialog unter Umständen nie wieder zeigen.

Die bessere Strategie: Führe den Nutzer zunächst durch das Kern-Feature deiner App. Sobald er an einem Punkt angelangt ist, an dem Benachrichtigungen offensichtlich nützlich sind – etwa nach dem ersten abgeschlossenen Workout in einer Fitness-App –, fragst du erst dann. Zeige zusätzlich immer eine kurze eigene Erklärung, bevor der System-Dialog erscheint, falls shouldShowRequestPermissionRationale() true zurückgibt.

Fazit

Die Notification Runtime Permission ist ein kompaktes Feature mit direktem Einfluss auf die Nutzerbindung. Die technische Implementierung – Manifest-Eintrag, ActivityResultLauncher, Dreifach-Fallunterscheidung im Callback – ist schnell erledigt. Die eigentliche Aufgabe liegt im Timing und in der Nutzerkommunikation. Überprüfe dein Verständnis, indem du auf einem Testgerät die Berechtigung mit adb shell pm revoke <dein.package> android.permission.POST_NOTIFICATIONS widerrufst und alle drei Zustände manuell durchläufst: erstmalige Anfrage, Rationale-Dialog nach einmaliger Ablehnung und dauerhaft verweigert mit Weiterleitung in die Einstellungen. Wer diese Szenarien zusätzlich mit dem Jetpack GrantPermissionRule oder einem UI-Test automatisiert abdeckt, schützt sich zuverlässig vor Regressionen bei künftigen targetSdkVersion-Upgrades.