Dangerous Permission i Android: väsen, lista över tillstånd och runtime-begäran

Vad är Dangerous Permission i Android

Dangerous Permission är en kategori av systemtillstånd i Android som ger åtkomst till användarens konfidentiella data. Till skillnad från normala tillstånd ges farliga tillstånd inte automatiskt vid installation — applikationen måste uttryckligen begära dem under körning via den runtime-mekanism som introducerades i Android 6.0 Marshmallow (API 23).

Behovet av uttrycklig begäran beror på arten av de data som dessa tillstånd skyddar: användarens geolokalisering, personliga kontakter, kamera- och mikrofoninnehåll, samtalshistorik och SMS. Android betraktar dessa data som känsliga och kräver informerat samtycke från användaren. Enligt Android Privacy Sandbox (2024) avvisar användare i genomsnitt cirka 30 procent av runtime-begäranden.

En viktig egenskap hos Dangerous Permission är möjligheten att återkalla när som helst. Användaren kan gå till Inställningar — Applikationer — Tillstånd och växla omkopplaren för vilket farligt tillstånd som helst. Applikationen måste vara beredd på att ett beviljat tillstånd när som helst kan återkallas utan omstart.

ProtectionLevel dangerous

Skyddsnivån dangerous ställs in i systemdefinitionerna av tillstånd på OS-nivå. När en applikation deklarerar uses-permission med ett sådant protectionLevel markerar systemet tillståndet som ett som kräver runtime-begäran. Till skillnad från normal visas dangerous-tillstånd alltid i systemets UI för tillståndshantering och kan återkallas.

Permission Group och Dangerous

Alla farliga tillstånd är grupperade i Permission Group efter funktionellt kriterium. Till exempel finns CAMERA och CAMERA2 i gruppen CAMERA, ACCESS_FINE_LOCATION och ACCESS_COARSE_LOCATION — i gruppen LOCATION. Om användaren har beviljat ett tillstånd från en grupp beviljas de andra tillstånden i samma grupp automatiskt utan ytterligare dialog.

Hur fungerar en runtime-begäran

En runtime-begäran är den mekanism genom vilken applikationen anropar systemets API för att visa en dialogruta med en begäran om tillstånd. Användaren ser ett modalt fönster med tillståndets namn och knapparna Allow och Deny. Efter svar anropar systemet callbacken onRequestPermissionsResult med resultatet.

Den fullständiga cykeln omfattar tre steg: statuskontroll via checkSelfPermission, anrop av requestPermissions vid avsaknad av tillstånd och bearbetning av resultatet i onRequestPermissionsResult. Statuskontroll är obligatorisk eftersom användaren när som helst kan återkalla tillståndet via inställningar, och att anropa funktionen utan kontroll leder till 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
            )
        }
    }
}

Resultatbearbetning sker i ActivityResultLauncher eller onRequestPermissionsResult. Den rekommenderade moderna metoden är att använda ActivityResultContracts.RequestPermission, som ger ett renare API utan explicita begärandekoder. Detta kontrakt returnerar Boolean — om tillståndet har beviljats eller inte.

Bästa praxis för begäran

Begär farliga tillstånd strikt i sammanhanget av funktionsanvändning, inte vid applikationsstart. Om användaren har tryckt på kameraknappen — begär CAMERA. Om han har öppnat kartan — begär LOCATION. Kontextuell begäran ger dubbelt så många godkännanden som att begära alla tillstånd vid första start. Det rekommenderas också att inte begära mer än ett tillstånd åt gången, så att användaren förstår vilken funktion som kräver åtkomst.

Lista över farliga tillstånd i Android

Android definierar flera grupper av farliga tillstånd, var och en innehållande en till flera konstanter. Den mest fullständiga listan finns i klassen Manifest.permission. Nedan visas de viktigaste grupperna och tillstånden som används i utveckling.

Nya tillstånd i Android 12+

Från och med Android 12 har Google skärpt kraven för vissa tillstånd. Till exempel har BLUETOOTH_CONNECT och BLUETOOTH_SCAN blivit farliga och kräver runtime-begäran. Även tillståndet BODY_SENSORS_BACKGROUND har dykt upp för bakgrundsåtkomst till sensorer. Utvecklare måste uppdatera targetSdkVersion och testa begäranden på aktuella OS-versioner.

Tillstånd för Android 13+

Android 13 (API 33) introducerade nya tillstånd för notifieringar (POST_NOTIFICATIONS) och för mediafiler (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), som ersatte den allmänna READ_EXTERNAL_STORAGE. Nu begärs åtkomst till foton, videor och ljud separat via specialiserade tillstånd utan en enda dialogruta.

Dangerous vs Normal Permission

Dangerous och Normal Permission skiljer sig fundamentalt åt i sättet att bevilja, möjligheten att återkalla och UX. Normal beviljas automatiskt vid installation, Dangerous kräver en explicit runtime-dialog. Normal kan inte återkallas via inställningar, Dangerous kan stängas av när som helst. Denna asymmetri skapar olika utvecklingsmönster.

Ur kodsynpunkt kräver farliga tillstånd mer arbete: checkSelfPermission, requestPermissions, hantering av avslag. För Normal räcker en rad i AndroidManifest.xml. Samtidigt ger Dangerous Permission användaren kontroll, vilket ökar förtroendet, särskilt för känsliga funktioner som kamera eller geolokalisering.

Valet mellan kategorier ligger inte hos utvecklaren — det bestäms av systemet. Utvecklaren deklarerar bara uses-permission och systemet bestämmer kategorin baserat på protectionLevel. Strategin för att begära farliga tillstånd påverkar dock användarupplevelsen: frekventa eller olämpliga dialoger sänker applikationens betyg.

Hur man begär tillstånd i Kotlin

Det moderna sättet att begära tillstånd i Kotlin är att använda ActivityResultContracts.RequestMultiplePermissions eller RequestPermission. Dessa kontrakt ingår i biblioteket androidx.activity och ger ett rent lambda-baserat API utan att behöva åsidosätta onRequestPermissionsResult.

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

Begära flera tillstånd samtidigt

När applikationen behöver flera farliga tillstånd samtidigt, använd RequestMultiplePermissions. Kontraktet returnerar Map<String, Boolean> där nyckeln är tillståndets namn och värdet är resultatet. Detta är praktiskt vid första start när CAMERA och RECORD_AUDIO behövs för videoinspelning.

Hantering av första avslag

Om användaren avvisade begäran returnerar metoden shouldShowRequestPermissionRationale true. Detta är en signal att visa en förklaring om varför tillståndet behövs. Bästa praxis är att visa en anpassad dialog med förklaring och en knapp Försök igen. Om användaren avvisade begäran igen med kryssrutan Never Ask Again kommer shouldShowRequestPermissionRationale att returnera false och man måste omdirigera till Inställningar.

Hantering av avslag och Never Ask Again

Never Ask Again är en flagga som användaren kan ställa in när runtime-dialogen avvisas igen. Därefter visas inte standarddialogrutan längre för detta tillstånd. Det enda sättet att ge åtkomst är att omdirigera användaren till systemets applikationsinställningar.

Utvecklaren måste skilja mellan två avslagsscenarier: första — när shouldShowRequestPermissionRationale returnerar true (användaren avvisade men dialogen kan fortfarande visas) och andra — när metoden returnerar false (Never Ask Again är aktivt eller tillståndet är blockerat av policy). I det andra fallet bör en knapp Öppna inställningar visas.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Åtkomst nekad")
        .setMessage(
            "Behörigheten är blockerad. Öppna inställningarna."
        )
        .setPositiveButton("Inställningar") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Det är viktigt att inte begära tillståndet igen om shouldShowRequestPermissionRationale returnerade false. Upprepad anrop av requestPermissions i detta fall kommer inte att visa dialogrutan — resultatet kommer omedelbart med DENIED utan förklaring. Användaren kommer att möta oförståeligt beteende, vilket negativt påverkar användarupplevelsen.