Dangerous Permission Androidban: lényeg, engedélyek listája és runtime kérés

Mi a Dangerous Permission Androidban

Dangerous Permission az Android rendszerengedélyek egy kategóriája, amely hozzáférést biztosít a felhasználó bizalmas adataihoz. A normál engedélyektől eltérően a veszélyes engedélyek nem adódnak ki automatikusan telepítéskor — az alkalmazásnak explicit módon kell kérnie azokat futásidőben az Android 6.0 Marshmallow (API 23) által bevezetett runtime mechanizmuson keresztül.

Az explicit kérés szükségessége az engedélyek által védett adatok természetéből fakad: a felhasználó geolokációja, személyes névjegyei, kamera és mikrofon tartalma, hívás- és SMS előzmények. Az Android ezeket az adatokat érzékenynek tekinti, és tudatos felhasználói hozzájárulást követel. A Android Privacy Sandbox (2024) szerint a felhasználók átlagosan a runtime kérések körülbelül 30 százalékát utasítják el.

A Dangerous Permission legfontosabb jellemzője — a visszavonhatóság bármikor. A felhasználó beléphet a Beállítások — Alkalmazások — Engedélyek menübe és átkapcsolhatja a kapcsolót bármely veszélyes engedélyhez. Az alkalmazásnak fel kell készülnie arra, hogy a megadott engedély bármikor visszavonható újraindítás nélkül.

ProtectionLevel dangerous

A dangerous védelmi szint az engedélyek rendszerdefinícióiban van beállítva OS szinten. Amikor az alkalmazás uses-permission-t deklarál ilyen protectionLevel-lel, a rendszer megjelöli az engedélyt runtime kérést igénylőként. A normal-tól eltérően a dangerous engedélyek mindig megjelennek a rendszer engedélykezelő felületén és visszavonhatók.

Permission Group és Dangerous

Az összes veszélyes engedély funkcionális jellemző szerint Permission Group-okba van csoportosítva. Például a CAMERA és CAMERA2 a CAMERA csoportban, az ACCESS_FINE_LOCATION és ACCESS_COARSE_LOCATION — a LOCATION csoportban található. Ha a felhasználó megadott egy engedélyt a csoportból, a csoport többi engedélye automatikusan megadásra kerül további dialógus nélkül.

Hogyan működik a runtime kérés

A runtime kérés az a mechanizmus, amelyben az alkalmazás meghívja a rendszer API-t egy engedélykérő dialógus megjelenítéséhez. A felhasználó egy modális ablakot lát az engedély nevével és az Allow és Deny gombokkal. A válasz után a rendszer meghívja az onRequestPermissionsResult callback-et az eredménnyel.

A teljes ciklus három lépésből áll: állapot ellenőrzése a checkSelfPermission segítségével, requestPermissions meghívása az engedély hiányában és az eredmény feldolgozása az onRequestPermissionsResult-ban. Az állapot ellenőrzése kötelező, mert a felhasználó bármikor visszavonhatja az engedélyt a beállításokon keresztül, és a funkció ellenőrzés nélküli meghívása SecurityException-hez vezet.

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

Az eredmény feldolgozása az ActivityResultLauncher-ben vagy az onRequestPermissionsResult-ban történik. Az ajánlott modern megközelítés — a ActivityResultContracts.RequestPermission használata, amely tisztább API-t biztosít explicit kéréskódok nélkül. Ez a szerződés Boolean-t ad vissza — hogy az engedély meg lett-e adva vagy sem.

Legjobb gyakorlatok a kéréshez

A veszélyes engedélyeket szigorúan a funkció használatának kontextusában kérje, ne az alkalmazás indításakor. Ha a felhasználó a kamera gombra nyomott — kérjen CAMERA-t. Ha megnyitotta a térképet — kérjen LOCATION-t. A kontextuális kérés kétszer annyi jóváhagyást eredményez, mint az összes engedély kérése az első indításkor. Szintén ajánlott egyszerre legfeljebb egy engedélyt kérni, hogy a felhasználó megértse, melyik funkció igényel hozzáférést.

Veszélyes engedélyek listája Androidban

Az Android meghatározza a veszélyes engedélyek több csoportját, amelyek mindegyike egy vagy több konstanst tartalmaz. A legteljesebb lista a Manifest.permission osztályban található. Alább a főbb csoportok és a fejlesztésben használt engedélyek láthatók.

Új engedélyek Android 12+ rendszerben

Android 12-től kezdve a Google szigorította egyes engedélyekre vonatkozó követelményeket. Például a BLUETOOTH_CONNECT és a BLUETOOTH_SCAN veszélyessé váltak és runtime kérést igényelnek. Megjelent a BODY_SENSORS_BACKGROUND engedély is az érzékelők háttérbeli hozzáféréséhez. A fejlesztőknek frissíteniük kell a targetSdkVersion-t és tesztelniük kell a kéréseket az aktuális OS-verziókon.

Engedélyek Android 13+ rendszerhez

Az Android 13 (API 33) új engedélyeket vezetett be az értesítésekhez (POST_NOTIFICATIONS) és a médiafájlokhoz (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), felváltva az általános READ_EXTERNAL_STORAGE-t. Most a fényképekhez, videókhoz és hangfájlokhoz való hozzáférést külön kell kérni specializált engedélyeken keresztül, egyetlen dialógus nélkül.

Dangerous vs Normal Permission

A Dangerous és Normal Permission alapvetően különbözik a megadás módjában, a visszavonhatóságban és az UX-ben. A Normal automatikusan kiadódik telepítéskor, a Dangerous explicit runtime dialógust igényel. A Normal nem vonható vissza a beállításokon keresztül, a Dangerous bármikor kikapcsolható. Ez az aszimmetria különböző fejlesztési mintákat eredményez.

A kód szempontjából a veszélyes engedélyek több munkát igényelnek: checkSelfPermission, requestPermissions, visszautasítás kezelése. A Normal-hoz elég egy sor az AndroidManifest.xml-ben. Ugyanakkor a Dangerous Permission kontrollt ad a felhasználónak, ami növeli a bizalmat, különösen az olyan érzékeny funkciók esetében, mint a kamera vagy a geolokáció.

A kategóriák közötti választás nem a fejlesztő előtt áll — azt a rendszer határozza meg. A fejlesztő csak deklarálja a uses-permission-t, a rendszer pedig a protectionLevel alapján határozza meg a kategóriát. Azonban a veszélyes engedélyek kérésének stratégiája befolyásolja a felhasználói élményt: a gyakori vagy nem megfelelő dialógusok csökkentik az alkalmazás értékelését.

Engedélyek kérése Kotlinban

A modern módszer az engedélyek kérésére Kotlinban — az ActivityResultContracts.RequestMultiplePermissions vagy RequestPermission használata. Ezek a szerződések az androidx.activity könyvtár részét képezik, és tiszta, lambda-alapú API-t biztosítanak anélkül, hogy felül kellene írni az onRequestPermissionsResult-t.

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

Több engedély egyidejű kérése

Amikor az alkalmazásnak egyszerre több veszélyes engedélyre van szüksége, használja a RequestMultiplePermissions-t. A szerződés Map<String, Boolean> értéket ad vissza, ahol a kulcs az engedély neve, az érték pedig az eredmény. Ez kényelmes az első indításkor, amikor CAMERA és RECORD_AUDIO szükséges a videofelvételhez.

Az első visszautasítás kezelése

Ha a felhasználó elutasította a kérést, a shouldShowRequestPermissionRationale metódus true-t ad vissza. Ez egy jelzés, hogy magyarázatot jelenítsen meg arról, miért van szükség az engedélyre. A legjobb gyakorlat — egy egyéni dialógus megjelenítése magyarázattal és egy Újra gombbal. Ha a felhasználó újra elutasította a kérést a Never Ask Again jelölőnégyzettel, a shouldShowRequestPermissionRationale false-t ad vissza, és át kell irányítani a Beállításokba.

Visszautasítás és Never Ask Again kezelése

A Never Ask Again egy jelző, amelyet a felhasználó állíthat be a runtime dialógus ismételt elutasításakor. Ezt követően a szabványos dialógusablak már nem jelenik meg ehhez az engedélyhez. Az egyetlen mód a hozzáférés biztosítására — a felhasználó átirányítása a rendszer alkalmazásbeállításaihoz.

A fejlesztőnek két visszautasítási forgatókönyvet kell megkülönböztetnie: első — amikor a shouldShowRequestPermissionRationale true-t ad vissza (a felhasználó elutasította, de a dialógus még megjeleníthető) és második — amikor a metódus false-t ad vissza (a Never Ask Again aktív vagy az engedélyt szabályzat blokkolja). A második esetben egy Beállítások megnyitása gombot kell megjeleníteni.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("A hozzáférés megtagadva")
        .setMessage(
            "Az engedély letiltva. Nyissa meg a beállításokat."
        )
        .setPositiveButton("Beállítások") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Fontos, hogy ne kérje újra az engedélyt, ha a shouldShowRequestPermissionRationale false-t adott vissza. A requestPermissions ismételt meghívása ebben az esetben nem jelenít meg dialógust — az eredmény azonnal DENIED-del érkezik magyarázat nélkül. A felhasználó érthetetlen viselkedéssel szembesül, ami negatívan befolyásolja az alkalmazás használatának élményét.