Dangerous Permission in Android: Was es ist, Liste der Berechtigungen und Runtime-Anfrage

Was ist Dangerous Permission in Android

Dangerous Permission ist eine Kategorie von Android-Systemberechtigungen, die Zugriff auf sensible Benutzerdaten gewähren. Im Gegensatz zu normalen Berechtigungen werden gefährliche Berechtigungen nicht automatisch bei der Installation erteilt — die App muss sie zur Laufzeit explizit über den in Android 6.0 Marshmallow (API 23) eingeführten Runtime-Mechanismus anfordern.

Die Notwendigkeit einer expliziten Anfrage ergibt sich aus der Art der Daten, die diese Berechtigungen schützen: Benutzerstandort, persönliche Kontakte, Kamera- und Mikrofoninhalte, Anrufverlauf und SMS. Android betrachtet diese Daten als sensibel und verlangt, dass der Benutzer den Zugriff bewusst gewährt. Laut Android Privacy Sandbox (2024) lehnen Benutzer durchschnittlich etwa 30 Prozent der Runtime-Anfragen ab.

Ein Hauptmerkmal von Dangerous Permission ist die Möglichkeit, es jederzeit zu widerrufen. Der Benutzer kann zu Einstellungen — Apps — Berechtigungen gehen und jede gefährliche Berechtigung deaktivieren. Die App muss darauf vorbereitet sein, dass eine zuvor erteilte Berechtigung jederzeit ohne Neustart widerrufen werden kann.

ProtectionLevel dangerous

Die Schutzstufe dangerous wird in den Systemberechtigungsdefinitionen auf OS-Ebene festgelegt. Wenn eine App uses-permission mit diesem protectionLevel deklariert, markiert das System die Berechtigung als runtime-anfragepflichtig. Im Gegensatz zu normal werden gefährliche Berechtigungen immer in der System-UI zur Berechtigungsverwaltung angezeigt und können widerrufen werden.

Permission Group und Dangerous

Alle gefährlichen Berechtigungen sind nach funktionaler Kategorie in Permission Groups gruppiert. Beispielsweise befinden sich CAMERA und CAMERA2 in der Gruppe CAMERA, ACCESS_FINE_LOCATION und ACCESS_COARSE_LOCATION in der Gruppe LOCATION. Wenn ein Benutzer eine Berechtigung aus einer Gruppe erteilt hat, werden die übrigen Berechtigungen derselben Gruppe automatisch ohne zusätzlichen Dialog erteilt.

Wie funktioniert die Runtime-Anfrage

Runtime-Anfrage ist ein Mechanismus, bei dem die App eine System-API aufruft, um einen Berechtigungsdialog anzuzeigen. Der Benutzer sieht ein modales Fenster mit dem Berechtigungsnamen und den Schaltflächen Erlauben und Verweigern. Nach der Antwort ruft das System den Callback onRequestPermissionsResult mit dem Ergebnis auf.

Der vollständige Zyklus umfasst drei Schritte: Statusprüfung über checkSelfPermission, Aufruf von requestPermissions bei fehlender Berechtigung und Ergebnisverarbeitung in onRequestPermissionsResult. Die Statusprüfung ist obligatorisch, da der Benutzer die Berechtigung jederzeit über die Einstellungen widerrufen haben könnte, und ein Funktionsaufruf ohne Prüfung führt zu einer SecurityException.

fun checkAndRequestCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED -> {
            openCamera()
        }
        else -> {
            ActivityCompat.requestPermissions(
                this,
                arrayOf(Manifest.permission.CAMERA),
                REQUEST_CAMERA_CODE
            )
        }
    }
}

Die Ergebnisverarbeitung erfolgt in ActivityResultLauncher oder onRequestPermissionsResult. Der empfohlene moderne Ansatz ist die Verwendung von ActivityResultContracts.RequestPermission, der eine sauberere API ohne explizite Anfragecodes bietet. Dieser Vertrag gibt einen Boolean zurück — ob die Berechtigung erteilt wurde oder nicht.

Best Practices für Anfragen

Fordern Sie gefährliche Berechtigungen strikt im Kontext der Funktionsnutzung an, nicht beim App-Start. Wenn der Benutzer die Kamerataste gedrückt hat — fordern Sie CAMERA an. Wenn er eine Karte geöffnet hat — fordern Sie LOCATION an. Kontextuelle Anfragen erzielen doppelt so viele Erteilungen wie das Anfordern aller Berechtigungen beim ersten Start. Es wird auch empfohlen, nicht mehr als eine Berechtigung gleichzeitig anzufordern, damit der Benutzer versteht, welche Funktion Zugriff benötigt.

Liste der gefährlichen Berechtigungen in Android

Android definiert mehrere Gruppen gefährlicher Berechtigungen, jede enthält eine oder mehrere Konstanten. Die vollständigste Liste ist in der Klasse Manifest.permission verfügbar. Nachfolgend sind die wichtigsten Gruppen und Berechtigungen aufgeführt, die in der Entwicklung verwendet werden.

Neue Berechtigungen in Android 12+

Ab Android 12 hat Google die Anforderungen für einige Berechtigungen verschärft. Beispielsweise wurden BLUETOOTH_CONNECT und BLUETOOTH_SCAN gefährlich und erfordern eine Runtime-Anfrage. Die Berechtigung BODY_SENSORS_BACKGROUND wurde für den Hintergrundzugriff auf Sensoren hinzugefügt. Entwickler müssen targetSdkVersion aktualisieren und Anfragen auf aktuellen OS-Versionen testen.

Berechtigungen für Android 13+

Android 13 (API 33) führte neue Berechtigungen für Benachrichtigungen (POST_NOTIFICATIONS) und Mediendateien (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO) ein, die das allgemeine READ_EXTERNAL_STORAGE ersetzten. Der Zugriff auf Fotos, Videos und Audio wird jetzt separat über spezialisierte Berechtigungen ohne einen einzigen Dialog angefordert.

Dangerous vs Normal Permission

Dangerous und Normal Permission unterscheiden sich grundlegend in der Art der Erteilung, der Widerrufbarkeit und der UX. Normal wird bei der Installation automatisch erteilt, Dangerous erfordert einen expliziten Runtime-Dialog. Normal kann nicht über die Einstellungen widerrufen werden, Dangerous kann jederzeit deaktiviert werden. Diese Asymmetrie schafft unterschiedliche Entwicklungsmuster.

Aus Codesicht erfordern gefährliche Berechtigungen mehr Arbeit: checkSelfPermission, requestPermissions, Ablehnungsbehandlung. Für normale reicht eine Zeile in AndroidManifest.xml. Allerdings gibt Dangerous Permission dem Benutzer Kontrolle, was das Vertrauen erhöht, insbesondere bei sensiblen Funktionen wie Kamera oder Standort.

Die Wahl zwischen den Kategorien liegt nicht beim Entwickler — sie wird vom System bestimmt. Der Entwickler deklariert lediglich uses-permission, und das System bestimmt die Kategorie basierend auf protectionLevel. Die Strategie zur Anforderung gefährlicher Berechtigungen beeinflusst jedoch die Benutzererfahrung: Häufige oder unangemessene Dialoge senken die Bewertung der App.

Wie man Berechtigungen in Kotlin anfordert

Der moderne Weg, Berechtigungen in Kotlin anzufordern, ist die Verwendung von ActivityResultContracts.RequestMultiplePermissions oder RequestPermission. Diese Verträge sind Teil der androidx.activity-Bibliothek und bieten eine saubere, auf Lambdas basierende API, ohne onRequestPermissionsResult überschreiben zu müssen.

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                showPermissionDeniedMessage()
            }
        }

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

Mehrere Berechtigungen gleichzeitig anfordern

Wenn eine App mehrere gefährliche Berechtigungen gleichzeitig benötigt, verwenden Sie RequestMultiplePermissions. Der Vertrag gibt Map<String, Boolean> zurück, wobei der Schlüssel der Berechtigungsname und der Wert das Ergebnis ist. Dies ist beim ersten Start nützlich, wenn CAMERA und RECORD_AUDIO für die Videoaufnahme angefordert werden müssen.

Behandlung der ersten Ablehnung

Wenn der Benutzer die Anfrage ablehnt, gibt die Methode shouldShowRequestPermissionRationale true zurück. Dies signalisiert, dass eine Erklärung angezeigt werden sollte, warum die Berechtigung benötigt wird. Die beste Praxis ist, einen benutzerdefinierten Dialog mit einer Erklärung und einer Wiederholen-Schaltfläche anzuzeigen. Wenn der Benutzer die Anfrage erneut mit aktiviertem Kontrollkästchen Never Ask Again ablehnt, gibt shouldShowRequestPermissionRationale false zurück, und Sie müssen zu den Einstellungen weiterleiten.

Behandlung von Ablehnung und Never Ask Again

Never Ask Again ist ein Flag, das der Benutzer beim zweiten Ablehnen des Runtime-Dialogs setzen kann. Danach wird der Standarddialog für diese Berechtigung nicht mehr angezeigt. Die einzige Möglichkeit, Zugriff zu gewähren, besteht darin, den Benutzer zu den System-App-Einstellungen weiterzuleiten.

Der Entwickler muss zwischen zwei Ablehnungsszenarien unterscheiden: erstens, wenn shouldShowRequestPermissionRationale true zurückgibt (der Benutzer hat abgelehnt, aber der Dialog kann noch angezeigt werden), und zweitens, wenn die Methode false zurückgibt (Never Ask Again ist aktiv oder die Berechtigung ist durch Richtlinien blockiert). Im zweiten Fall sollten Sie eine Schaltfläche Einstellungen öffnen anzeigen.

fun handlePermissionDenied(permission: String) {
    if (ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
    )) {
        showRationaleDialog(permission)
    } else {
        showSettingsRedirectDialog(permission)
    }
}

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Zugriff verweigert")
        .setMessage(
            "Berechtigung blockiert. Einstellungen öffnen."
        )
        .setPositiveButton("Einstellungen") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Es ist wichtig, die Berechtigung nicht erneut anzufordern, wenn shouldShowRequestPermissionRationale false zurückgegeben hat. Ein wiederholter Aufruf von requestPermissions zeigt in diesem Fall keinen Dialog an — das Ergebnis kommt sofort mit DENIED ohne Erklärung zurück. Der Benutzer stößt auf unklares Verhalten, was sich negativ auf die App-Erfahrung auswirkt.