Berechtigungsstrategie: Zugriff nur zum richtigen Moment

Sensitive Berechtigungen sind keine Formalität — sie sind eine Vertrauensfrage. Jedes Mal, wenn deine App Zugriff auf Kamera, Standort oder Kontakte anfordert, entscheidet der Nutzer in Sekunden, ob er dir traut. Eine schlechte Strategie kostet nicht nur diesen einen Dialog, sondern langfristig auch die Bewertung im Play Store.

Was ist das?

Eine Berechtigungsstrategie legt fest, wann, warum und in welcher Reihenfolge deine App sensible Systemressourcen anfragt. Android unterscheidet zwischen zwei Hauptkategorien:

• Normal Permissions (z. B. INTERNET, VIBRATE) werden beim Installieren automatisch gewährt und erscheinen dem Nutzer nicht als Dialog.
• Dangerous Permissions (z. B. ACCESS_FINE_LOCATION, READ_CONTACTS, CAMERA) erfordern seit Android 6.0 (API 23) eine explizite Laufzeitanfrage — der Nutzer kann ablehnen oder eine bereits erteilte Berechtigung jederzeit widerrufen.

Das Kernprinzip hinter jeder guten Strategie ist Least Privilege: Fordere ausschließlich die Berechtigung an, die für die gerade aktive Funktion zwingend notwendig ist. Wer auf Vorrat fragt, signalisiert Misstrauen und riskiert eine sofortige Ablehnung. Googles Security-Best-Practices formulieren es direkt: Minimiere den Zugriff auf sensible Daten und reduziere damit gleichzeitig die Angriffsfläche deiner App.

Im Roadmap-Kontext dieser Phase gehört die Berechtigungsstrategie zum Türsteher vor jedem Sensorzugriff, Standort-Feature oder Hardware-Kanal. Ohne eine durchdachte Strategie werden selbst technisch sauber implementierte Features von Nutzern abgelehnt oder im Datenschutz-Audit beanstandet.

Wie funktioniert es?

Android stellt seit API 23 das ActivityResult-Framework bereit. Der empfohlene Weg führt über ActivityResultContracts.RequestPermission oder RequestMultiplePermissions. Du registrierst den Launcher einmalig, bevor die Activity gestartet wird, und rufst ihn erst auf, wenn der Nutzer eine Funktion bewusst aktiviert.

private val requestCameraPermission =
    registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
        if (isGranted) {
            openCamera()
        } else {
            showPermissionDeniedHint()
        }
    }

fun onScanButtonClicked() {
    when {
        ContextCompat.checkSelfPermission(
            requireContext(), Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED -> openCamera()

        shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) ->
            showRationaleDialog()

        else -> requestCameraPermission.launch(Manifest.permission.CAMERA)
    }
}

Der entscheidende Schritt ist die Abfrage von shouldShowRequestPermissionRationale. Das System gibt true zurück, wenn der Nutzer die Berechtigung bereits einmal abgelehnt hat, aber noch nicht „Nicht mehr fragen” gewählt hat. In diesem Fall zeigst du zuerst einen Rationale-Dialog — einen kurzen, verständlichen Hinweis in deiner eigenen UI, der erklärt, wozu die Berechtigung gebraucht wird. Danach erst öffnet sich der Systemdialog.

Timing: Der wichtigste Hebel

Der optimale Moment für eine Berechtigungsanfrage ist der unmittelbare Kontext einer Nutzeraktion. Wenn jemand auf „Foto aufnehmen” tippt, versteht er sofort, warum die App die Kamera braucht. Wenn beim App-Start ohne Erklärung mehrere Dialoge erscheinen, lehnt der Nutzer reflexartig ab — oft dauerhaft.

In der Praxis

Stell dir eine Lieferdienst-App vor: Sie braucht den genauen Standort, aber nur während einer aktiven Tour. Die falsche Strategie wäre, ACCESS_FINE_LOCATION beim ersten App-Start anzufragen. Die richtige Abfolge:

1. Der Fahrer tippt auf „Tour starten”.
2. Die App prüft, ob ACCESS_FINE_LOCATION vorliegt.
3. Falls nicht: Ein Bottom-Sheet erscheint — „Für die Navigation während der Fahrt benötigen wir deinen genauen Standort.”
4. Erst danach öffnet sich der Android-Systemdialog.

Typische Stolperfalle — dauerhafte Ablehnung: Wenn shouldShowRequestPermissionRationale den Wert false zurückgibt und du die Berechtigung noch nicht hast, hat der Nutzer entweder „Nicht mehr fragen” gewählt oder die Anfrage wurde noch nie gestellt. In diesem Fall öffnest du den Systemdialog nicht erneut — das hat keine Wirkung. Stattdessen leitest du den Nutzer zu den App-Einstellungen:

fun openAppSettings() {
    Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).also { intent ->
        intent.data = Uri.fromParts("package", requireContext().packageName, null)
        startActivity(intent)
    }
}

Zeige dazu eine klare Nachricht, die erklärt, was der Nutzer in den Einstellungen aktivieren soll — und biete optional eine Alternativfunktion an, die ohne die Berechtigung auskommt. Damit bleibt die App auch im Ablehnungsfall benutzbar.

Berechtigungen in Jetpack Compose

In Compose verwendest du rememberLauncherForActivityResult an derselben Stelle im Composable-Baum. Die Logik für Rationale und Fallback bleibt identisch:

val launcher = rememberLauncherForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted ->
    if (granted) openCamera() else showDeniedState()
}

Die Entscheidungslogik — checkSelfPermission, shouldShowRequestPermissionRationale, Fallback auf Einstellungen — ist Framework-unabhängig und lässt sich sauber in ein ViewModel auslagern, das sowohl von klassischen Fragments als auch von Composables genutzt werden kann.

Fazit

Eine durchdachte Berechtigungsstrategie ist keine Kleinigkeit am Ende der Entwicklung — sie ist Teil des UX-Designs von Anfang an. Timing und Rationale entscheiden, ob Nutzer zustimmen oder dauerhaft ablehnen. Überprüfe in deiner aktuellen App alle Stellen, an denen Dangerous Permissions angefragt werden: Geschieht das wirklich erst im direkten Kontext der jeweiligen Funktion? Zeigst du einen eigenen Rationale-Hinweis, bevor der Systemdialog erscheint? Behandelst du den dauerhaften Ablehnungsfall mit einem Weg zu den Einstellungen? Schreibe einen Espresso-Test oder nutze den Emulator, um alle drei Pfade aktiv durchzuspielen — Erlaubnis erteilt, einmalig abgelehnt, dauerhaft abgelehnt. Das ist der sicherste Weg, um keine Nutzer an einem schlecht platzierten Dialog zu verlieren.