Dangerous Permission v Androidu: podstata, seznam oprávnění a runtime žádost

Co je Dangerous Permission v Androidu

Dangerous Permission je kategorie systémových oprávnění Androidu, která poskytují přístup k důvěrným údajům uživatele. Na rozdíl od normálních oprávnění se nebezpečná oprávnění nevydávají automaticky při instalaci — aplikace je musí výslovně vyžádat za běhu prostřednictvím runtime mechanismu představeného v Android 6.0 Marshmallow (API 23).

Potřeba výslovné žádosti vyplývá z povahy údajů, které tato oprávnění chrání: geolokace uživatele, osobní kontakty, obsah kamery a mikrofonu, historie hovorů a SMS. Android považuje tyto údaje za citlivé a vyžaduje informovaný souhlas uživatele. Podle Android Privacy Sandbox (2024) uživatelé v průměru odmítají přibližně 30 procent runtime žádostí.

Klíčovou vlastností Dangerous Permission je možnost odvolání kdykoli. Uživatel může přejít do Nastavení — Aplikace — Oprávnění a přepnout přepínač pro libovolné nebezpečné oprávnění. Aplikace musí být připravena na to, že udělené oprávnění může být kdykoli odvoláno bez restartu.

ProtectionLevel dangerous

Úroveň ochrany dangerous je nastavena v systémových definicích oprávnění na úrovni OS. Když aplikace deklaruje uses-permission s takovým protectionLevel, systém označí oprávnění jako vyžadující runtime žádost. Na rozdíl od normal jsou dangerous oprávnění vždy zobrazena v systémovém UI správy oprávnění a mohou být odvolána.

Permission Group a Dangerous

Všechna nebezpečná oprávnění jsou seskupena do Permission Group podle funkčního znaku. Například CAMERA a CAMERA2 jsou ve skupině CAMERA, ACCESS_FINE_LOCATION a ACCESS_COARSE_LOCATION — ve skupině LOCATION. Pokud uživatel udělil jedno oprávnění ze skupiny, ostatní oprávnění stejné skupiny jsou udělena automaticky bez dalšího dialogu.

Jak funguje runtime žádost

Runtime žádost je mechanismus, při kterém aplikace volá systémové API pro zobrazení dialogu s žádostí o oprávnění. Uživatel vidí modální okno s názvem oprávnění a tlačítky Allow a Deny. Po odpovědi systém zavolá callback onRequestPermissionsResult s výsledkem.

Celý cyklus zahrnuje tři kroky: kontrola stavu prostřednictvím checkSelfPermission, volání requestPermissions při absenci oprávnění a zpracování výsledku v onRequestPermissionsResult. Kontrola stavu je povinná, protože uživatel může oprávnění kdykoli odvolat prostřednictvím nastavení a volání funkce bez kontroly povede k 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
            )
        }
    }
}

Zpracování výsledku probíhá v ActivityResultLauncher nebo onRequestPermissionsResult. Doporučený moderní přístup — použití ActivityResultContracts.RequestPermission, který poskytuje čistší API bez explicitních kódů žádosti. Tato smlouva vrací Boolean — zda bylo oprávnění uděleno či nikoli.

Nejlepší postupy žádosti

Žádejte nebezpečná oprávnění striktně v kontextu použití funkce, nikoli při spuštění aplikace. Pokud uživatel stiskl tlačítko kamery — žádejte CAMERA. Pokud otevřel mapu — žádejte LOCATION. Kontextuální žádost poskytuje dvakrát více souhlasů než žádost o všechna oprávnění při prvním spuštění. Rovněž se doporučuje nežádat o více než jedno oprávnění najednou, aby uživatel pochopil, která funkce vyžaduje přístup.

Seznam nebezpečných oprávnění v Androidu

Android definuje několik skupin nebezpečných oprávnění, z nichž každá obsahuje jednu až několik konstant. Nejúplnější seznam je uveden ve třídě Manifest.permission. Níže jsou uvedeny hlavní skupiny a oprávnění používaná ve vývoji.

Nová oprávnění v Android 12+

Od Android 12 Google zpřísnil požadavky na některá oprávnění. Například BLUETOOTH_CONNECT a BLUETOOTH_SCAN se staly nebezpečnými a vyžadují runtime žádost. Také se objevilo oprávnění BODY_SENSORS_BACKGROUND pro přístup na pozadí k senzorům. Vývojáři musí aktualizovat targetSdkVersion a testovat žádosti na aktuálních verzích OS.

Oprávnění pro Android 13+

Android 13 (API 33) zavedl nová oprávnění pro oznámení (POST_NOTIFICATIONS) a pro mediální soubory (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), která nahradila obecné READ_EXTERNAL_STORAGE. Nyní se přístup k fotkám, videím a audiu žádá samostatně prostřednictvím specializovaných oprávnění bez jediného dialogu.

Dangerous vs Normal Permission

Dangerous a Normal Permission se zásadně liší způsobem udělení, možností odvolání a UX. Normal se uděluje automaticky při instalaci, Dangerous vyžaduje explicitní runtime dialog. Normal nelze odvolat prostřednictvím nastavení, Dangerous lze kdykoli vypnout. Tato asymetrie vytváří různé vývojové vzory.

Z hlediska kódu vyžadují nebezpečná oprávnění více práce: checkSelfPermission, requestPermissions, zpracování odmítnutí. Pro Normální stačí jeden řádek v AndroidManifest.xml. Zároveň Dangerous Permission dává uživateli kontrolu, což zvyšuje důvěru, zejména u citlivých funkcí, jako je kamera nebo geolokace.

Volba mezi kategoriemi nestojí před vývojářem — je určena systémem. Vývojář pouze deklaruje uses-permission a systém na základě protectionLevel určuje kategorii. Nicméně strategie žádosti o nebezpečná oprávnění ovlivňuje uživatelský zážitek: časté nebo nevhodné dialogy snižují hodnocení aplikace.

Jak žádat o oprávnění v Kotlinu

Moderní způsob žádosti o oprávnění v Kotlinu — použití ActivityResultContracts.RequestMultiplePermissions nebo RequestPermission. Tyto smlouvy jsou součástí knihovny androidx.activity a poskytují čisté API založené na lambdách, bez nutnosti přepisovat 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
                )
        }
    }
}

Žádost o několik oprávnění najednou

Když aplikace potřebuje několik nebezpečných oprávnění současně, použijte RequestMultiplePermissions. Smlouva vrací Map<String, Boolean>, kde klíč je název oprávnění a hodnota je výsledek. To je vhodné při prvním spuštění, když je potřeba požádat o CAMERA a RECORD_AUDIO pro nahrávání videa.

Zpracování prvního odmítnutí

Pokud uživatel žádost odmítl, metoda shouldShowRequestPermissionRationale vrací true. To je signál k zobrazení vysvětlení, proč je oprávnění potřeba. Nejlepším postupem je zobrazení vlastního dialogu s vysvětlením a tlačítkem Zkusit znovu. Pokud uživatel znovu odmítl žádost se zaškrtnutím Never Ask Again, shouldShowRequestPermissionRationale vrátí false a je třeba přesměrovat do Nastavení.

Zpracování odmítnutí a Never Ask Again

Never Ask Again je příznak, který může uživatel nastavit při opětovném odmítnutí runtime dialogu. Poté se standardní dialogové okno pro toto oprávnění již nezobrazí. Jediný způsob, jak poskytnout přístup — přesměrování uživatele do systémového nastavení aplikací.

Vývojář musí rozlišovat dva scénáře odmítnutí: první — když shouldShowRequestPermissionRationale vrací true (uživatel odmítl, ale dialog lze ještě zobrazit) a druhý — když metoda vrací false (Never Ask Again je aktivní nebo je oprávnění blokováno politikou). V druhém případě je třeba zobrazit tlačítko Otevřít nastavení.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Přístup odepřen")
        .setMessage(
            "Oprávnění je zablokováno. Otevřete nastavení."
        )
        .setPositiveButton("Nastavení") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Je důležité nežádat o oprávnění znovu, pokud shouldShowRequestPermissionRationale vrátil false. Opakované volání requestPermissions v tomto případě nezobrazí dialog — výsledek přijde okamžitě s DENIED bez vysvětlení. Uživatel narazí na nepochopitelné chování, což negativně ovlivní zážitek z používání aplikace.