Dangerous Permission у Android-у: суштина, листа дозвола и runtime захтев

Шта је Dangerous Permission у Android-у

Dangerous Permission — је категорија системских дозвола Android-а које пружају приступ поверљивим подацима корисника. За разлику од нормалних, опасне дозволе се не издају аутоматски приликом инсталације — апликација мора изричито да их затражи током извршавања путем механизма runtime, представљеног у Android 6.0 Marshmallow (API 23).

Потреба за изричитим захтевом произилази из природе података које ове дозволе штите: геолокација корисника, лични контакти, садржај камере и микрофона, историја позива и SMS. Android сматра ове податке осетљивим и захтева свесну сагласност корисника. Према Android Privacy Sandbox (2024), корисници одбијају у просеку око 30 посто runtime захтева.

Кључна карактеристика Dangerous Permission — могућност опозива у било ком тренутку. Корисник може да оде у Подешавања — Апликације — Дозволе и пребаци прекидач за било коју опасну дозволу. Апликација мора бити спремна да дозвола која је одобрена може бити опозвана у било ком тренутку без поновног покретања.

ProtectionLevel dangerous

Ниво заштите dangerous се поставља у системским дефиницијама дозвола на нивоу OS. Када апликација декларише uses-permission са таквим protectionLevel, систем означава дозволу као ону која захтева runtime захтев. За разлику од normal, dangerous дозволе су увек приказане у системском UI-ју за управљање дозволама и могу бити опозване.

Permission Group и Dangerous

Све опасне дозволе су груписане у Permission Group по функционалном критеријуму. На пример, CAMERA и CAMERA2 су у групи CAMERA, ACCESS_FINE_LOCATION и ACCESS_COARSE_LOCATION — у групи LOCATION. Ако је корисник одобрио једну дозволу из групе, остале дозволе исте групе се одобравају аутоматски без додатног дијалога.

Како функционише runtime захтев

Runtime захтев — је механизам којим апликација позива системски API за приказ дијалога са захтевом за дозволу. Корисник види модални прозор са називом дозволе и дугмићима Allow и Deny. Након одговора, систем позива колбек onRequestPermissionsResult са резултатом.

Пун циклус укључује три корака: провера статуса путем checkSelfPermission, позивање requestPermissions у одсуству дозволе и обрада резултата у onRequestPermissionsResult. Провера статуса је обавезна, јер корисник може да опозове дозволу у било ком тренутку кроз подешавања, а позивање функције без провере довешће до 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
            )
        }
    }
}

Обрада резултата се одвија у ActivityResultLauncher или onRequestPermissionsResult. Препоручени савремени приступ — коришћење ActivityResultContracts.RequestPermission, који пружа чистији API без експлицитних кодова захтева. Овај уговор враћа Boolean — да ли је дозвола одобрена или не.

Најбоље праксе захтевања

Захтевајте опасне дозволе строго у контексту коришћења функције, а не при покретању апликације. Ако је корисник притиснуо дугме камере — захтевајте CAMERA. Ако је отворио мапу — захтевајте LOCATION. Контекстуални захтев даје дупло више одобрења него захтевање свих дозвола при првом покретању. Такође се препоручује да не захтевате више од једне дозволе одједном, како би корисник разумео која функција захтева приступ.

Листа опасних дозвола у Android-у

Android дефинише неколико група опасних дозвола, од којих свака садржи од једне до неколико константи. Најпотпунија листа је представљена у класи Manifest.permission. Испод су приказане главне групе и дозволе које се користе у развоју.

Нове дозволе у Android 12+

Почевши од Android 12, Google је пооштрио захтеве за неке дозволе. На пример, BLUETOOTH_CONNECT и BLUETOOTH_SCAN су постале опасне и захтевају runtime захтев. Такође се појавила дозвола BODY_SENSORS_BACKGROUND за позадински приступ сензорима. Програмери морају да ажурирају targetSdkVersion и тестирају захтеве на актуелним верзијама OS.

Дозволе за Android 13+

Android 13 (API 33) је увео нове дозволе за обавештења (POST_NOTIFICATIONS) и за медијске датотеке (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), заменивши општи READ_EXTERNAL_STORAGE. Сада се приступ фотографијама, видео записима и звуку захтева одвојено кроз специјализоване дозволе без јединственог дијалога.

Dangerous vs Normal Permission

Dangerous и Normal Permission се суштински разликују по начину одобравања, могућности опозива и UX-у. Normal се издаје аутоматски при инсталацији, Dangerous захтева експлицитни runtime дијалог. Normal се не може опозвати кроз подешавања, Dangerous се може искључити у било ком тренутку. Ова асиметрија поставља различите обрасце развоја.

Са становишта кода, опасне дозволе захтевају више посла: checkSelfPermission, requestPermissions, обрада одбијања. За нормалне је довољан један ред у AndroidManifest.xml. Истовремено, Dangerous Permission даје кориснику контролу, што повећава поверење, посебно за осетљиве функције попут камере или геолокације.

Избор између категорија не стоји пред програмером — одређује га систем. Програмер само декларише uses-permission, а систем на основу protectionLevel одређује категорију. Међутим, стратегија захтевања опасних дозвола утиче на корисничко искуство: чести или неприкладни дијалози смањују рејтинг апликације.

Како затражити дозволе у Kotlin-у

Савремени начин захтевања дозвола у Kotlin-у — коришћење ActivityResultContracts.RequestMultiplePermissions или RequestPermission. Ови уговори су део библиотеке androidx.activity и пружају чист API заснован на ламбда изразима, без потребе за преписивањем 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
                )
        }
    }
}

Захтевање више дозвола одједном

Када апликација треба више опасних дозвола истовремено, користите RequestMultiplePermissions. Уговор враћа Map<String, Boolean>, где је кључ име дозволе, а вредност резултат. Ово је згодно при првом покретању када треба затражити CAMERA и RECORD_AUDIO за видео снимање.

Обрада одбијања први пут

Ако је корисник одбио захтев, метод shouldShowRequestPermissionRationale враћа true. То је сигнал да прикажете објашњење зашто је дозвола потребна. Најбоља пракса — приказ прилагођеног дијалога са објашњењем и дугметом Покушај поново. Ако је корисник поново одбио захтев са ознаком Never Ask Again, shouldShowRequestPermissionRationale ће вратити false и треба преусмерити у Подешавања.

Обрада одбијања и Never Ask Again

Never Ask Again — је ознака коју корисник може поставити при поновном одбијању runtime дијалога. Након тога, стандардни дијалог се више не приказује за ову дозволу. Једини начин да се одобри приступ — преусмеравање корисника у системска подешавања апликација.

Програмер треба да разликује два сценарија одбијања: први — када shouldShowRequestPermissionRationale враћа true (корисник је одбио, али дијалог се још може приказати) и други — када метод враћа false (Never Ask Again је активан или је дозвола блокирана политиком). У другом случају треба приказати дугме Отвори подешавања.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Доступ запрещён")
        .setMessage(
            "Разрешение заблокировано. Откройте настройки."
        )
        .setPositiveButton("Настройки") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Важно је не захтевати дозволу поново ако је shouldShowRequestPermissionRationale вратио false. Поновно позивање requestPermissions у овом случају неће приказати дијалог — резултат ће доћи одмах са DENIED без објашњења. Корисник ће се суочити са неразумљивим понашањем, што ће негативно утицати на искуство коришћења апликације.