Dangerous Permission in Android: essentie, lijst van machtigingen en runtime-verzoek

Wat is Dangerous Permission in Android

Dangerous Permission is een categorie systeemmachtigingen in Android die toegang geven tot vertrouwelijke gebruikersgegevens. In tegenstelling tot normale machtigingen worden gevaarlijke machtigingen niet automatisch verleend bij installatie — de app moet er expliciet om vragen tijdens runtime via het mechanisme dat is geïntroduceerd in Android 6.0 Marshmallow (API 23).

De noodzaak van expliciete aanvraag komt voort uit de aard van de gegevens die deze machtigingen beschermen: gebruikerslocatie, persoonlijke contacten, camera- en microfooninhoud, belgeschiedenis en SMS. Android beschouwt deze gegevens als gevoelig en vereist geïnformeerde toestemming van de gebruiker. Volgens Android Privacy Sandbox (2024) wijzen gebruikers gemiddeld ongeveer 30 procent van de runtime-verzoeken af.

Een belangrijk kenmerk van Dangerous Permission is de mogelijkheid om op elk moment in te trekken. De gebruiker kan naar Instellingen — Apps — Machtigingen gaan en de schakelaar voor elke gevaarlijke machtiging omzetten. De app moet erop voorbereid zijn dat een verleende machtiging op elk moment zonder herstart kan worden ingetrokken.

ProtectionLevel dangerous

Het beveiligingsniveau dangerous wordt ingesteld in de systeemdefinities van machtigingen op OS-niveau. Wanneer een app uses-permission declareert met een dergelijk protectionLevel, markeert het systeem de machtiging als een die een runtime-verzoek vereist. In tegenstelling tot normal worden dangerous-machtigingen altijd weergegeven in de systeem-UI voor machtigingenbeheer en kunnen ze worden ingetrokken.

Permission Group en Dangerous

Alle gevaarlijke machtigingen zijn gegroepeerd in Permission Group op functionele basis. Bijvoorbeeld CAMERA en CAMERA2 zitten in de groep CAMERA, ACCESS_FINE_LOCATION en ACCESS_COARSE_LOCATION — in de groep LOCATION. Als de gebruiker één machtiging uit een groep heeft verleend, worden de overige machtigingen van dezelfde groep automatisch verleend zonder extra dialoog.

Hoe werkt een runtime-verzoek

Runtime-verzoek is het mechanisme waarbij de app de systeem-API aanroept om een dialoogvenster met een machtigingsverzoek weer te geven. De gebruiker ziet een modaal venster met de naam van de machtiging en de knoppen Allow en Deny. Na het antwoord roept het systeem de callback onRequestPermissionsResult aan met het resultaat.

De volledige cyclus omvat drie stappen: statuscontrole via checkSelfPermission, aanroep van requestPermissions bij afwezigheid van de machtiging en verwerking van het resultaat in onRequestPermissionsResult. Statuscontrole is verplicht omdat de gebruiker de machtiging op elk moment via instellingen kan intrekken en het aanroepen van de functie zonder controle leidt tot een 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
            )
        }
    }
}

De verwerking van het resultaat vindt plaats in ActivityResultLauncher of onRequestPermissionsResult. De aanbevolen moderne aanpak is het gebruik van ActivityResultContracts.RequestPermission, dat een schonere API biedt zonder expliciete verzoekcodes. Dit contract retourneert Boolean — of de machtiging is verleend of niet.

Beste praktijken voor aanvragen

Vraag gevaarlijke machtigingen strikt in de context van het gebruik van de functie, niet bij het starten van de app. Als de gebruiker op de cameraknop heeft gedrukt — vraag CAMERA aan. Als hij de kaart heeft geopend — vraag LOCATION aan. Contextueel verzoek levert twee keer zoveel toestemmingen op als het aanvragen van alle machtigingen bij de eerste start. Ook wordt aanbevolen om niet meer dan één machtiging tegelijk aan te vragen, zodat de gebruiker begrijpt welke functie toegang nodig heeft.

Lijst van gevaarlijke machtigingen in Android

Android definieert verschillende groepen gevaarlijke machtigingen, elk met één tot meerdere constanten. De meest volledige lijst staat in de klasse Manifest.permission. Hieronder staan de belangrijkste groepen en machtigingen die in ontwikkeling worden gebruikt.

Nieuwe machtigingen in Android 12+

Vanaf Android 12 heeft Google de vereisten voor sommige machtigingen aangescherpt. Zo zijn BLUETOOTH_CONNECT en BLUETOOTH_SCAN gevaarlijk geworden en vereisen ze een runtime-verzoek. Ook is de machtiging BODY_SENSORS_BACKGROUND verschenen voor achtergrondtoegang tot sensoren. Ontwikkelaars moeten targetSdkVersion updaten en verzoeken testen op de huidige OS-versies.

Machtigingen voor Android 13+

Android 13 (API 33) introduceerde nieuwe machtigingen voor meldingen (POST_NOTIFICATIONS) en voor mediabestanden (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), ter vervanging van de algemene READ_EXTERNAL_STORAGE. Nu wordt toegang tot foto, video en audio apart aangevraagd via gespecialiseerde machtigingen zonder één dialoogvenster.

Dangerous vs Normal Permission

Dangerous en Normal Permission verschillen fundamenteel in de manier van verlenen, de mogelijkheid tot intrekken en UX. Normal wordt automatisch verleend bij installatie, Dangerous vereist een expliciet runtime-dialoog. Normal kan niet worden ingetrokken via instellingen, Dangerous kan op elk moment worden uitgeschakeld. Deze asymmetrie legt verschillende ontwikkelingspatronen op.

Vanuit code-oogpunt vereisen gevaarlijke machtigingen meer werk: checkSelfPermission, requestPermissions, afwijzingsafhandeling. Voor normale is één regel in AndroidManifest.xml voldoende. Tegelijkertijd geeft Dangerous Permission de gebruiker controle, wat het vertrouwen vergroot, vooral voor gevoelige functies zoals camera of geolocatie.

De keuze tussen categorieën ligt niet bij de ontwikkelaar — deze wordt door het systeem bepaald. De ontwikkelaar declareert alleen uses-permission en het systeem bepaalt de categorie op basis van protectionLevel. De strategie voor het aanvragen van gevaarlijke machtigingen beïnvloedt echter de gebruikerservaring: frequente of ongepaste dialogen verlagen de beoordeling van de app.

Machtigingen aanvragen in Kotlin

De moderne manier om machtigingen aan te vragen in Kotlin is het gebruik van ActivityResultContracts.RequestMultiplePermissions of RequestPermission. Deze contracten maken deel uit van de androidx.activity-bibliotheek en bieden een schone API op basis van lambda's, zonder dat onRequestPermissionsResult hoeft te worden overschreven.

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
                )
        }
    }
}

Meerdere machtigingen tegelijk aanvragen

Wanneer een app meerdere gevaarlijke machtigingen tegelijk nodig heeft, gebruik dan RequestMultiplePermissions. Het contract retourneert Map<String, Boolean> waarbij de sleutel de naam van de machtiging is en de waarde het resultaat. Dit is handig bij de eerste start wanneer CAMERA en RECORD_AUDIO nodig zijn voor video-opname.

Afwijzing de eerste keer afhandelen

Als de gebruiker het verzoek heeft afgewezen, retourneert de methode shouldShowRequestPermissionRationale true. Dit is een signaal om een uitleg te tonen waarom de machtiging nodig is. Beste praktijk is het tonen van een aangepaste dialoog met uitleg en een knop Opnieuw. Als de gebruiker het verzoek opnieuw heeft afgewezen met het vinkje Never Ask Again, retourneert shouldShowRequestPermissionRationale false en moet worden doorgestuurd naar Instellingen.

Afwijzing en Never Ask Again afhandelen

Never Ask Again is een vlag die de gebruiker kan instellen bij het opnieuw afwijzen van het runtime-dialoogvenster. Daarna wordt het standaard dialoogvenster niet meer getoond voor deze machtiging. De enige manier om toegang te verlenen is door de gebruiker door te sturen naar de systeeminstellingen van apps.

De ontwikkelaar moet twee afwijzingsscenario's onderscheiden: de eerste — wanneer shouldShowRequestPermissionRationale true retourneert (de gebruiker heeft afgewezen maar de dialoog kan nog worden getoond) en de tweede — wanneer de methode false retourneert (Never Ask Again is actief of de machtiging is geblokkeerd door beleid). In het tweede geval moet een knop Instellingen openen worden getoond.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Toegang geweigerd")
        .setMessage(
            "Toestemming geblokkeerd. Open de instellingen."
        )
        .setPositiveButton("Instellingen") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Het is belangrijk om de machtiging niet opnieuw aan te vragen als shouldShowRequestPermissionRationale false heeft geretourneerd. Herhaalde aanroep van requestPermissions toont in dit geval geen dialoog — het resultaat komt onmiddellijk met DENIED zonder uitleg. De gebruiker wordt geconfronteerd met onbegrijpelijk gedrag, wat een negatieve invloed heeft op de gebruikerservaring.