Runtime Permission: welche Typen es gibt und Funktionsprinzip in Android

Was ist Runtime Permission?

Runtime Permission ist ein Android-Sicherheitsmodell, bei dem die App Zugriff auf vertrauliche Daten zu dem Zeitpunkt anfordert, an dem diese Funktionalität vom Benutzer tatsächlich benötigt wird. Vor Android 6.0 wurden alle Berechtigungen bei der Installation der App erteilt, und der Benutzer konnte sie nicht entziehen, ohne die App vollständig zu deinstallieren.

Entwicklung des Android-Berechtigungsmodells

Vor Android 6.0 sah der Benutzer bei der Installation eine Liste aller Berechtigungen und konnte entweder alle akzeptieren oder die Installation ablehnen. Eine Studie aus dem Jahr 2015 zeigte, dass 87% der Benutzer die Berechtigungsliste bei der Installation nicht lesen. Android 6.0 führte Runtime Permissions ein und teilte Berechtigungen in normale (automatische) und gefährliche (mit Anfrage) ein. Android 11 fügte einmalige Berechtigungen hinzu — automatischer Widerruf nach dem Schließen der App. Android 13 führte Photo Picker und Push-Benachrichtigungen als separate Runtime Permissions ein.

iOS verwendet seit iOS 10 ein ähnliches Modell, bei dem der Zugriff auf Kamera, Mikrofon und Geolokalisierung bei der ersten Nutzung angefordert wird. iOS kennt jedoch kein Konzept von „normalen Berechtigungen“ — jede Berechtigung wird explizit angefordert, und die Ablehnung bleibt bestehen, bis der Entwickler sie über die Systemeinstellungen erneut anfordert.

Wie funktioniert Runtime Permission in Android?

Runtime Permission funktioniert über einen Systemdialog, der durch die Methode requestPermissions() (AndroidX — ActivityResultLauncher) aufgerufen wird. Das System zeigt einen Standarddialog mit einer Erklärung an, und der Benutzer wählt „Erlauben“ oder „Ablehnen“. Nach der Antwort wird ein Callback ausgelöst, in dem die App die Entscheidung des Benutzers verarbeitet.

Berechtigungsanfrage über ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

private fun checkCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
                == PackageManager.PERMISSION_GRANTED -> {
            startCamera()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA) -> {
            showRationaleDialog { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }
        }
        else -> {
            requestPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

Die Methode shouldShowRequestPermissionRationale gibt true zurück, wenn der Benutzer die Anfrage bereits einmal abgelehnt hat. In diesem Fall wird empfohlen, einen Dialog mit einer Erklärung anzuzeigen, warum die App die Berechtigung benötigt, und erst dann erneut anzufragen. Dies erhöht die Wahrscheinlichkeit der Zustimmung des Benutzers um 30–40% (Daten von Google I/O 2024).

Arten von Berechtigungen in Android

Android klassifiziert alle Berechtigungen in mehrere Schutzstufen: normal, gefährlich, Signatur und speziell. Normale Berechtigungen werden bei der Installation automatisch erteilt. Gefährliche Berechtigungen erfordern eine Runtime-Anfrage. Signaturberechtigungen stehen nur Apps zur Verfügung, die mit demselben Zertifikat signiert sind.

Gruppen gefährlicher Berechtigungen

Spezielle Berechtigungen (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) erfordern eine zusätzliche Navigation zu den Systemeinstellungen über Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Diese Berechtigungen können nicht über den Standardsystemdialog angefordert werden und erfordern eine explizite Aktion des Benutzers auf dem Einstellungsbildschirm.

Berechtigungsanfragen in Android 12+

Android 12 führte bedeutende Änderungen am Runtime-Permissions-Modell ein. Einmalige Berechtigungen erlauben den Zugriff auf Kamera, Mikrofon oder Geolokalisierung nur für eine Sitzung. Sobald der Benutzer die App schließt, wird die Berechtigung automatisch widerrufen. Datenschutzindikatoren sind grüne Indikatoren in der Statusleiste, die anzeigen, wann eine App die Kamera oder das Mikrofon verwendet.

Behandlung einmaliger Berechtigungen

// Android 12+ — Behandlung der einmaligen Standortberechtigung
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Prüfen, ob die Berechtigung vom System widerrufen wurde (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 fügte die Berechtigung POST_NOTIFICATIONS zur gefährlichen Gruppe hinzu, was eine explizite Anfrage zum Senden von Push-Benachrichtigungen erfordert. Android 14 führte Einschränkungen für die Hintergrund-Geolokalisierung ein: Die App muss bei jeder Anfrage nach Hintergrundstandort die ausdrückliche Zustimmung des Benutzers einholen. Photo Picker (API 33+) ersetzte die Notwendigkeit von READ_EXTERNAL_STORAGE für die Bildauswahl.

Behandlung von Benutzerablehnungen

Die Ablehnung einer Berechtigungsanfrage durch den Benutzer ist eine normale Situation, die korrekt behandelt werden muss. Es gibt zwei Arten von Ablehnungen: einmalig (Benutzer hat „Ablehnen“ gedrückt) und dauerhaft (Benutzer hat „Nicht mehr fragen“ ausgewählt). Im zweiten Fall wird der Systemdialog nicht mehr angezeigt, und die App muss den Benutzer zu den Systemeinstellungen weiterleiten.

Strategie zur Behandlung von Ablehnungen

Nach der ersten Ablehnung sollte die App einen Begründungsdialog anzeigen — eine eigene Erklärung, warum die Berechtigung erforderlich ist. Wenn der Benutzer erneut ablehnt, sollte die App über Settings.ACTION_APPLICATION_DETAILS_SETTINGS zum App-Einstellungsbildschirm weiterleiten. Material 3 empfiehlt die Verwendung von PermissionRequestBottomSheet für eine natürlichere UX.

Es ist wichtig, die Funktionalität der App bei Ablehnung nicht vollständig zu blockieren. Wenn der Benutzer beispielsweise die Geolokalisierung ablehnt, sollte die App eine manuelle Adresseingabe anbieten. Für die Kamera ermöglichen Sie das Hochladen eines Bildes aus der Galerie. Google empfiehlt, für alle Runtime Permissions immer einen Fallback-Mechanismus bereitzustellen.

Sicherheitsempfehlungen

Runtime Permissions sind nicht nur ein technischer Mechanismus, sondern auch ein Element des Benutzervertrauens in die App. Die Anforderung einer Berechtigung zu einem unpassenden Zeitpunkt (z. B. beim ersten Start) verringert die Wahrscheinlichkeit der Zustimmung erheblich. Der Google Play Store analysiert die Häufigkeit und den Kontext von Berechtigungsanfragen: Apps mit aggressiven Anfragen erhalten niedrigere Positionen in der Suche.

Regeln für Berechtigungsanfragen

Kontext — fordern Sie die Berechtigung unmittelbar vor der Ausführung der Aktion an, die sie erfordert. Minimum — fordern Sie nur die Berechtigungen an, die für die Funktion tatsächlich erforderlich sind. Transparenz — erklären Sie dem Benutzer vor dem Systemdialog, warum die Berechtigung benötigt wird. Widerruf — abonnieren Sie ACTION_PERMISSION_REVOCATION, um den Widerruf von Berechtigungen zur Laufzeit korrekt zu behandeln.

Zum Testen von Runtime Permissions verwenden Sie adb-Befehle: adb shell pm revoke <package> android.permission.CAMERA ermöglicht die Simulation des Berechtigungswiderrufs ohne Neuinstallation der App. Espresso und UiAutomator unterstützen das Testen von Berechtigungsdialogen über GrantPermissionRule. Die Integration dieser Tools in die CI/CD-Pipeline ist für Apps mit Runtime Permissions obligatorisch.

Berechtigungsprüfung in der Google Play Console

Die Google Play Console bietet einen Bereich zur Berechtigungsprüfung, in dem Entwickler sehen können, wie oft Berechtigungen angefordert werden, wie viel Prozent der Benutzer Zugriff gewähren und welche Berechtigungen widerrufen wurden. Die Analyse dieser Daten hilft, ineffektive Anfragen zu identifizieren und die UX zu optimieren. Wenn beispielsweise weniger als 40% der Benutzer die Geolokalisierung gewähren, sollten Sie den Zeitpunkt der Anfrage überdenken und eine überzeugendere Begründung hinzufügen.

Die Verwendung von Android Vitals zur Überwachung berechtigungsbezogener ANR (Application Not Responding) ist ebenfalls kritisch. Wenn eine Berechtigungsanfrage im Hauptthread ausgeführt wird oder der Systemdialog die UI blockiert, kann dies auf langsamen Geräten zu ANR führen. Verlagern Sie die Berechtigungsprüfung und -anfrage in einen separaten Thread oder verwenden Sie Kotlin-Koroutinen für die asynchrone Verarbeitung, um eine Blockierung der Benutzeroberfläche zu vermeiden.