AndroidManifest Permissions: kernconcepten, declaratie en typen machtigingen

Wat zijn AndroidManifest Permissions?

AndroidManifest Permissions is het beveiligingsmechanisme van Android dat de toegang van apps tot beschermde gegevens en systeemfuncties regelt. Elke app moet de vereiste machtigingen in het AndroidManifest.xml-bestand declareren met behulp van het element <uses-permission>. Zonder declaratie mislukt de aanroep van de bijbehorende API met de beveiligingsfout SecurityException.

Het machtigingenmodel van Android heeft verschillende evolutiefasen doorlopen. Vóór Android 6.0 (API 23) werden alle machtigingen verleend bij installatie — de gebruiker zag de volledige lijst en accepteerde of weigerde de installatie van de app. Vanaf Android 6.0 worden dangerous machtigingen tijdens runtime (Runtime Permissions) aangevraagd, wat de gebruiker meer flexibele controle geeft.

Machtigingen zijn onderverdeeld in vier beschermingsniveaus: normal (automatisch verleend bij installatie), dangerous (vereist runtime-aanvraag), signature (alleen beschikbaar voor apps ondertekend met hetzelfde certificaat) en special (vereist aparte inschakeling in instellingen). Elk niveau heeft zijn eigen mechanisme voor verlenen en intrekken.

Volgens Google I/O 2024 worden in Android 15 meer granulaire machtigingen gepland — gebruikers kunnen alleen toegang verlenen tot specifieke bestanden in de mediatheek, niet de hele bibliotheek. Dit zet de trend van Android voort om de standaard verstrekte gegevens te minimaliseren.

Verschil met het iOS-machtigingenmodel

In tegenstelling tot iOS, waar alle machtigingen tijdens runtime worden aangevraagd, verdeelt Android machtigingen in installatie (install-time) en runtime. Het normal-niveau wordt automatisch bij installatie verleend zonder melding aan de gebruiker. Het dangerous-niveau vereist een expliciet dialoogvenster, zoals in iOS.

Een ander verschil: in Android zijn machtigingen gegroepeerd in groepen (permission groups). Als de gebruiker toegang tot de camera heeft geaccepteerd, krijgt de app automatisch toegang tot de microfoon — ze zitten in dezelfde MICROPHONE-groep. In iOS wordt elke machtiging afzonderlijk aangevraagd, onafhankelijk van de groep.

Evolutie van machtigingen per Android-versie

Welke typen machtigingen bestaan er

Android definieert vier beschermingsniveaus (protection levels) voor machtigingen, elk met eigen regels voor verlenen. Laten we elk niveau in detail bekijken.

Normal Permissions (install-time)

Normal machtigingen worden automatisch verleend bij installatie van de app zonder melding of aanvraag aan de gebruiker. Ze dekken toegang tot functies met een laag risico die de privacy van de gebruiker niet bedreigen: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. De gebruiker ziet geen toestemmingsdialoog — de machtiging wordt als verleend beschouwd door het feit van installatie.

De ontwikkelaar hoeft geen aanvraag in code af te handelen voor normal machtigingen — het is voldoende om ze in het manifest te declareren. In Android 12+ ziet de gebruiker bij installatie vanuit Google Play echter het tabblad „Machtigingen” met een lijst van alle normal machtigingen, wat de transparantie verhoogt. Volgens Statista (2024) gebruikt meer dan 90% van de apps in Google Play INTERNET als de meest voorkomende normal machtiging.

Dangerous Permissions (runtime)

Dangerous machtigingen dekken toegang tot gegevens en functies die de privacy kunnen schenden: camera, microfoon, geolocatie, contacten, SMS, telefoon, agenda, lichaamsensoren. Deze machtigingen vereisen een tweestaps mechanisme: declaratie in het manifest + aanvraag tijdens runtime via ActivityCompat.requestPermissions().

De gebruiker kan het verlenen van een dangerous machtiging weigeren en de app moet dit scenario correct afhandelen. In Android 11+ als de gebruiker twee keer heeft geweigerd, tonen volgende aanvragen geen systeemdialoog — het systeem retourneert automatisch DENIED. In dit geval moet de gebruiker naar de instellingen worden geleid.

Signature en Special Permissions

Het signature niveau — de machtiging wordt automatisch verleend als de app is ondertekend met hetzelfde certificaat als het systeem of een andere app die de machtiging heeft gedefinieerd. Gebruikt voor systeem- en bedrijfsapps. Voorbeeld: BIND_ACCESSIBILITY_SERVICE — alleen beschikbaar voor systeemapps.

Het special niveau (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — vereist een aparte actie van de gebruiker via systeeminstellingen. De app kan de instellingenpagina openen met Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). Google Play beperkt het gebruik van special machtigingen en vereist rechtvaardiging in het formulier bij publicatie.

Runtime Permission: werken met dangerous machtigingen

Vanaf Android 6.0 vereisen alle dangerous machtigingen een aanvraag tijdens runtime. Laten we de volledige werkcyclus met runtime permissions in Kotlin bekijken.

Controleren en aanvragen van machtigingen

Controleer altijd de huidige status via ContextCompat.checkSelfPermission() voordat u een API aanroept die een dangerous machtiging vereist. Als de status PERMISSION_GRANTED is — kan de API worden aangeroepen. Als PERMISSION_DENIED is — moet de machtiging worden aangevraagd via ActivityResultContract RequestPermission (AndroidX) of verouderde requestPermissions().

Het wordt aanbevolen om ActivityResultContracts.RequestMultiplePermissions te gebruiken voor het gelijktijdig aanvragen van meerdere machtigingen. Google raadt aan gerelateerde machtigingen (bijv. camera + microfoon voor video-opname) in één dialoog te groeperen, zodat de gebruiker de volledige context van de aanvraag ziet.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

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

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

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

Afhandeling van „Don’t ask again” weigering

Als de gebruiker de machtiging twee keer heeft geweigerd, zet Android de aanvraag in de status „Never ask again”. In dit geval retourneert shouldShowRequestPermissionRationale() false en wordt het systeemdialoogvenster niet getoond. De app moet de gebruiker naar de systeeminstellingen leiden via Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Belangrijk: toon niet direct na de eerste weigering een dialoog met het voorstel om de instellingen te openen — dit wordt als agressief gedrag ervaren. Gebruik shouldShowRequestPermissionRationale() om te bepalen of een uitleg moet worden getoond. Material Design Guidelines raden aan een scherm te tonen met uitleg over de waarde van toegang, niet alleen een knop „Open instellingen”.

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

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Toegang tot camera")
        .setMessage("Sta toegang tot de camera toe in Instellingen, "
            + "om profielfoto’s te maken")
        .setPositiveButton("Open instellingen") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Annuleren", null)
        .show()
}

Declaratie van machtigingen in AndroidManifest.xml

Het bestand AndroidManifest.xml bevat het element <uses-permission> voor elke machtiging die de app gebruikt. Machtigingen worden gedeclareerd op het niveau <manifest> vóór het element <application>.

Syntax van declaratie

Elke machtiging wordt gedeclareerd als een apart element <uses-permission> met het attribuut android:name dat de volledige naam van de machtiging aangeeft. Gebruik voor machtigingen die in specifieke Android-versies zijn verschenen het attribuut maxSdkVersion om de declaratie te beperken tot alleen de benodigde versies — dit verbetert de compatibiliteit.

De machtiging WRITE_EXTERNAL_STORAGE is bijvoorbeeld niet nodig op Android 10+ (Scoped Storage), dus geef maxSdkVersion=„28” (Android 9) op. Dit voorkomt onnodige vragen van gebruikers op nieuwere versies. Android Studio waarschuwt voor aanbevolen maxSdkVersion via Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

Gebruik van <uses-feature> voor filtering

Het element <uses-feature> geeft aan dat de app specifieke hardware (camera, GPS, NFC) nodig heeft. Het attribuut android:required=„false” maakt installatie van de app mogelijk op apparaten zonder deze hardware — beschikbaarheidscontrole gebeurt in code. Als required=„true” is, filtert Google Play de app en wordt deze niet beschikbaar voor ongeschikte apparaten.

Het wordt aanbevolen voor alle hardwarefuncties required=„false” in te stellen en de beschikbaarheid programmatisch te controleren via PackageManager.hasSystemFeature(). Dit vergroot het publiek van uw app. De enige uitzondering is wanneer de functie kritiek is voor de werking van de app (een taxi-app zonder GPS heeft geen zin).

Beste praktijken en fouten

Correct werken met machtigingen is een belangrijk aspect van de kwaliteit van een Android-app. Laten we de belangrijkste aanbevelingen en veelvoorkomende fouten bekijken.

Minimaliseren van aangevraagde machtigingen

Vraag alleen machtigingen aan die echt nodig zijn voor de werking van de app. Elke extra machtiging verlaagt de conversie van installaties en verhoogt het aantal weigeringen. Google Play Console toont hoeveel gebruikers zijn afgehaakt van installatie vanwege de set machtigingen. Volgens AppBrain (2024) hebben apps met 10+ dangerous machtigingen 35% minder installaties.

Herzie regelmatig de lijst met machtigingen. Verwijder ongebruikte machtigingen, vooral bij overgang naar nieuwere Android-versies waar sommige machtigingen optioneel zijn geworden. Met de komst van de fotokiezer (ActivityResultContracts.PickVisualMedia) in Android 13+ kan toegang tot de mediatheek bijvoorbeeld worden verkregen zonder de dangerous machtiging READ_MEDIA_IMAGES.

Rationale tonen vóór aanvraag

Toon de gebruiker vóór het aanvragen van een dangerous machtiging een scherm met uitleg waarom deze machtiging nodig is en welke waarde het biedt. Material Design raadt het gebruik van een bottom sheet of dialoog met pictogram, korte tekst en de knop „Doorgaan” aan. Rationale verhoogt de toestemming met 20–30% in vergelijking met directe aanvraag.

Controleer shouldShowRequestPermissionRationale() voordat u launch() aanroept. Als true — toon rationale. Als false — is de machtiging al verleend of heeft de gebruiker definitief geweigerd (never ask again). Toon in het laatste geval de knop „Open instellingen” in plaats van de aanvraag te herhalen.

Testen van alle machtigingscenario’s

Test alle mogelijke scenario’s: verlenen van machtiging, weigeren, definitief weigeren, intrekken van machtiging in instellingen, resetten van machtigingen (Android 11+ auto-reset). Elk scenario moet worden afgehandeld zonder crash en zonder gegevensverlies. Android Testing Guide raadt aan de bibliotheek TestPermission te gebruiken voor het automatiseren van tests.

Besteed speciale aandacht aan het scenario waarin de gebruiker de machtiging intrekt tijdens het gebruik van de app (geminimaliseerde app → Instellingen → intrekking). Controleer bij terugkeer naar de app alle machtigingen opnieuw via onResume(). Vertrouw niet op caching van de machtigingsstatus — de gebruiker kan deze op elk moment wijzigen.

Veelvoorkomende fouten

• Aanvragen van machtiging zonder voorafgaande checkSelfPermission-controle — veroorzaakt onnodige dialoog
• Negeren van shouldShowRequestPermissionRationale — verslechtert UX na eerste weigering
• Aanvragen van machtiging zonder context (alleen „Toegang toestaan?”) — verlaagt toestemming
• Gebruik van WRITE_EXTERNAL_STORAGE op Android 10+ zonder maxSdkVersion — onnodige aanvraag
• Ontbreken van machtigingscontrole in onResume — missen van intrekking in instellingen