Permission Handler i Android: hur det fungerar, hantering av förfrågningar och implementering

Vad är Permission Handler i Android

Permission Handler — är ett arkitekturmönster för centraliserad hantering av Android runtime-behörigheter. Istället för spridda anrop till ContextCompat.checkSelfPermission och ActivityCompat.requestPermissions över hela applikationskoden koncentreras all logik för förfrågningar och resultathantering i en enda klass. Detta minskar duplicering, förenklar underhåll och gör koden mer förutsägbar.

Behovet av Permission Handler uppstod med införandet av runtime-behörigheter i Android 6.0. Innan dess begärdes alla behörigheter vid installation och applikationskoden kunde använda vilket API som helst utan kontroller. Efter övergången till runtime-modellen kräver varje användning av en farlig behörighet en trestegskontroll: checkSelfPermission, requestPermissions, onRequestPermissionsResult. Spridningen av denna logik mellan Activity och Fragment leder till inline-duplicering och fel. Enligt Google I/O 2019 minskar centralisering av behörighetshantering antalet buggar relaterade till Permission Denial med i genomsnitt 60 procent.

En bra Permission Handler ger ett rent gränssnitt för anropande kod. Activity eller Fragment behöver inte känna till detaljerna i begäran — de anropar en metod som requestCamera(callback), och hanteraren sköter själv statuskontroll, visning av rationale, anrop av systemdialog och överföring av resultatet till callbacken. Detta implementerar principen om enskilt ansvar och separerar affärslogik från plattformskoden för behörigheter.

När behövs Permission Handler

Permission Handler blir nödvändig när applikationen använder 3 eller fler farliga behörigheter. För enkla applikationer med en enda behörighet (till exempel kamera för QR-kodskanner) kan man klara sig med direkta anrop. Men för en typisk mobilapplikation med kamera, geolokalisering, notifieringar och lagring — är en centraliserad hanterare obligatorisk för underhåll.

Arkitektur för Permission Handler

En typisk Permission Handler består av tre nivåer: gränssnittskontrakt, implementering med ActivityResultLauncher och ett lager för ViewModel. Gränssnittet definierar begärandemetoder för varje behörighet — requestCamera, requestLocation, requestStorage. Implementeringen kopplar dessa metoder till motsvarande ActivityResultContracts.RequestPermission-kontrakt.

Nyckelkomponenter i arkitekturen:

• PermissionHandlerContract — gränssnitt med metoder för varje behörighet
• PermissionHandlerImpl — implementering som ansluter till ActivityResultRegistry
• PermissionResult — sealed class med tillstånden GRANTED, DENIED, NEVER_ASK_AGAIN
• RationaleHandler — komponent för att visa förklaringar före begäran

Denna arkitektur gör det enkelt att byta ut implementeringen i tester: istället för en riktig ActivityResultLauncher används en mock som returnerar ett fördefinierat resultat utan interaktion med systemet. Detta är kritiskt för enhetstestning av UI-logik, där det är omöjligt att starta en Activity för en behörighetsdialog.

Livscykelhantering

Permission Handler måste ta hänsyn till Activitys och Fragments livscykel. Launchers registreras i ActivityResultRegistry, som automatiskt sparar och återställer tillstånd vid skärmrotation och återskapande av Activity. Handler bör inte lagra direkta referenser till Activity eller Fragment — använd istället WeakReference eller skicka registry via konstruktorn. Detta förhindrar minnesläckor och krascher vid konfigurationsändringar.

Implementera Permission Handler i Kotlin

Grundläggande implementering av Permission Handler bygger på ActivityResultContracts.RequestPermission. Handler får ActivityResultRegistry från ComponentActivity eller Fragment och registrerar launchers för varje behörighet. Varje launcher accepterar en lambda-callback som anropas efter användarens svar.

sealed class PermissionResult {
    object GRANTED : PermissionResult()
    data class DENIED(
        val shouldShowRationale: Boolean
    ) : PermissionResult()
}

interface PermissionHandler {
    fun requestCamera(
        callback: (PermissionResult) -> Unit
    )
    fun requestLocation(
        callback: (PermissionResult) -> Unit
    )
    fun isPermissionGranted(
        permission: String
    ): Boolean
}

class AndroidPermissionHandler(
    private val registry: ActivityResultRegistry,
    private val context: Context
) : PermissionHandler {

    private var cameraLauncher: ActivityResultLauncher<String>? = null

    fun initialize() {
        cameraLauncher = registry.register(
            "camera_permission",
            ActivityResultContracts.RequestPermission()
        ) { isGranted ->
            if (isGranted) {
                pendingCameraCallback?.invoke(
                    PermissionResult.GRANTED
                )
            } else {
                val rationale = ActivityCompat.shouldShowRequestPermissionRationale(
                    context as Activity,
                    Manifest.permission.CAMERA
                )
                pendingCameraCallback?.invoke(
                    PermissionResult.DENIED(rationale)
                )
            }
        }
    }

    private var pendingCameraCallback:
        ((PermissionResult) -> Unit)? = null

    override fun requestCamera(
        callback: (PermissionResult) -> Unit
    ) {
        if (isPermissionGranted(
                Manifest.permission.CAMERA
        )) {
            callback.invoke(PermissionResult.GRANTED)
            return
        }
        pendingCameraCallback = callback
        cameraLauncher?.launch(
            Manifest.permission.CAMERA
        )
    }

    override fun isPermissionGranted(
        permission: String
    ): Boolean {
        return ContextCompat.checkSelfPermission(
            context, permission
        ) == PackageManager.PERMISSION_GRANTED
    }
}

Initialisering i Activity

Handler initieras i Activitys onCreate via registerForActivityResult, som ger åtkomst till ActivityResultRegistry. Efter initialisering är hanteraren redo att bearbeta förfrågningar under Activitys hela livscykel. Det är viktigt att anropa initialize före den första begäran, annars kommer launchern inte att registreras.

Permission Handler med ViewModel

Integration av Permission Handler med ViewModel är den mest avancerade metoden. ViewModel hanterar tillståndet för förfrågningar och Handler utför endast plattformsanrop. ViewModel innehåller StateFlow<PermissionUiState>, där UiState beskriver vilken behörighet som begärs och vilket resultat som erhållits. Activity prenumererar på denna StateFlow och delegerar begäran till Handler.

class PermissionsViewModel : ViewModel() {

    private val _uiState =
        MutableStateFlow<PermissionUiState>(
            PermissionUiState.Idle
        )
    val uiState: StateFlow<PermissionUiState> = _uiState.asStateFlow()

    fun onCameraRequested() {
        _uiState.value = PermissionUiState.RequestingCamera
    }

    fun onPermissionResult(
        permission: String,
        result: PermissionResult
    ) {
        when (result) {
            PermissionResult.GRANTED -> {
                _uiState.value = PermissionUiState.Granted(permission)
            }
            is PermissionResult.DENIED -> {
                _uiState.value = PermissionUiState.Denied(
                    permission,
                    result.shouldShowRationale
                )
            }
        }
    }
}

sealed class PermissionUiState {
    object Idle : PermissionUiState()
    object RequestingCamera : PermissionUiState()
    data class Granted(val permission: String) : PermissionUiState()
    data class Denied(
        val permission: String,
        val shouldShowRationale: Boolean
    ) : PermissionUiState()
}

I denna modell kontrollerar Activity vid start isPermissionGranted via Handler, och ViewModel hanterar endast tillståndet. Om behörigheten inte har beviljats — prenumererar Activity på uiState, anropar requestCamera från Handler och skickar tillbaka resultatet till ViewModel via onPermissionResult. Separationen av plattformskod och affärslogik gör det möjligt att testa ViewModel utan Android-beroenden.

Testa Permission Handler

Enhetstestning av Permission Handler är möjlig tack vare gränssnittet PermissionHandler. I tester skapas en FakePermissionHandler som simulerar olika scenarier: behörighet beviljad, nekad, Never Ask Again. Varje scenario testas oberoende. Detta är särskilt viktigt för testning av UI-logik som måste reagera korrekt på alla tre utfallen.

class FakePermissionHandler : PermissionHandler {

    var cameraResult: PermissionResult =
        PermissionResult.GRANTED
    var grantedPermissions: Set<String> =
        setOf(Manifest.permission.CAMERA)

    override fun requestCamera(
        callback: (PermissionResult) -> Unit
    ) {
        callback.invoke(cameraResult)
    }

    override fun isPermissionGranted(
        permission: String
    ): Boolean {
        return permission in grantedPermissions
    }
}

Fake-implementering gör det möjligt att testa ViewModel utan emulator. Det räcker att ställa in cameraResult på önskat värde och kontrollera att ViewModel korrekt uppdaterar UiState. Integrationstester kontrollerar den riktiga PermissionHandler med ActivityScenario, men vanligtvis finns det 2-3 sådana tester för hela applikationen — resterande scenarier täcks av enhetstester med fake-implementeringar.

Vanliga mönster och misstag

Vanliga misstag vid arbete med Permission Handler inkluderar: avsaknad av checkSelfPermission-kontroll före varje API-anrop, ignorering av shouldShowRequestPermissionRationale, återupprepade anrop av requestPermissions vid Never Ask Again och lagring av launchers utan hänsyn till Activitys livscykel. Låt oss titta på varje problem och lösning.

Det vanligaste misstaget — att anropa API utan att kontrollera behörighetsstatus. Utvecklare antar att om en behörighet en gång har beviljats kommer den att finnas kvar för alltid. Men användaren kan när som helst återkalla den via inställningar. Permission Handler måste alltid anropa isPermissionGranted före en känslig operation. Det andra vanliga misstaget — att ignorera shouldShowRequestPermissionRationale och göra en upprepad begäran som leder till omedelbar avvisning utan dialog vid Never Ask Again.

Bästa praxis inkluderar: att skapa en enda Handler-instans för Activitys hela livscykel, använda SharedFlow för att överföra resultat till ViewModel, logga alla förfrågningar och avvisningar för analys, samt visa en anpassad rationale-dialog före systemdialogen vid första avvisningen. Att följa dessa regler garanterar stabil funktion med behörigheter på alla Android-versioner.