Runtime Permission: суштина, врсте и принцип рада у Android-у

Шта је Runtime Permission?

Runtime Permission (дозвола у тренутку извршавања) — је Android модел безбедности у коме апликација захтева приступ поверљивим подацима у тренутку када је та функционалност стварно потребна кориснику. Пре Android 6.0, сва дозволе су се одобравала при инсталацији апликације, и корисник није могао да их опозове без потпуног уклањања апликације.

Еволуција Android модела дозвола

Пре Android 6.0, корисник је видео листу свих дозвола при инсталацији и могао или да прихвати све, или да одустане од инсталације. Истраживање из 2015. године је показало да 87% корисника не чита листу дозвола при инсталацији. Android 6.0 је увео runtime permissions, поделивши дозволе на normal (аутоматске) и dangerous (са захтевом). Android 11 је додао one-time permissions — аутоматско повлачење након затварања апликације. Android 13 је увео Photo Picker и push обавештења као засебне runtime permissions.

iOS користи сличан модел од верзије iOS 10, где се приступ камери, микрофону и геолокацији захтева при првом кориштењу. Међутим, iOS нема концепт „normal permissions“ — свака дозвола се захтевају експлицитно, а одбијање се чува до поновног захтева од стране програмера кроз системска подешавања.

Како ради Runtime Permission у Android-у?

Runtime Permission ради кроз системски дијалог који се позива методом requestPermissions() (AndroidX — ActivityResultLauncher). Систем приказује стандардни дијалог са објашњењем, а корисник бира „Дозволи“ или „Одбији“. Након одговора, позива се callback резултата у коме апликација обрађује одлуку корисника.

Захтев дозволе кроз ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

private fun checkCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
                == PackageManager.PERMISSION_GRANTED -> {
            startCamera()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA) -> {
            showRationaleDialog { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }
        }
        else -> {
            requestPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

Метода shouldShowRequestPermissionRationale враћа true ако је корисник већ једном одбио захтев. У овом случају се препоручује приказивање дијалога са објашњењем зашто је апликацији потребно дозволење, и тек онда поново захтевати. Ово повећава вероватноћу прихватања за 30–40% (подаци Google I/O 2024).

Врсте дозвола у Android-у

Android класификује сва дозволе на неколико нивоа заштите: normal, dangerous, signature и special. Normal permissions се додељују аутоматски при инсталацији. Dangerous permissions захтевају runtime захтев. Signature permissions су доступне само апликацијама потписаним истим цертификатом.

Групе опасних дозвола

Special permissions (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) захтевају додатни прелазак на системска подешавања кроз Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Ове дозволе не могу бити захтеване стандардним системским дијалогом и захтевају експлицитан прелазак корисника на екран подешавања.

Захтев дозвола у Android 12+

Android 12 је представио значајне промјене у моделу runtime permissions. One-time permissions омогућују додјељивање приступа камери, микрофону или геолокацији само за једну сесију. Када корисник затвори апликацију, дозвола се аутоматски повлачи. Privacy indicators — зелени индикатори у траки статуса који показују када апликација користи камеру или микрофон.

Обрада једнократних дозвола

// Android 12+ — обрада једнократне дозволе за геолокацију
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Провера да ли је дозвола повучена од стране система (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 је додао дозволу POST_NOTIFICATIONS у dangerous групу, захтевајући експлицитан захтев за слање push обавештења. Android 14 је увео ограничења за позадинску геолокацију: апликација мора да добије експлицитну сагласност корисника сваки пут када захтева background location. Photo Picker (API 33+) је заменио потребу за READ_EXTERNAL_STORAGE за избор слика.

Обрада одбијања корисника

Одбијање корисника да дозволи је нормална ситуација коју треба правилно обрадити. Постоје две врсте одбијања: једнократно (корисник је кликнуо „Одбији“) и трајно (корисник је изабрао „Не питај више“). У другом случају, системски дијалог се више не ће приказивати, и апликација мора да преусмери корисника на системска подешавања.

Стратегија обраде одбијања

Након првог одбијања, апликација треба да прикаже rationale dialog — сопствено објашњење зашто је дозвола потребно. Ако корисник поново одбије, треба га преусмерити на екран подешавања апликације кроз Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 препоручује коришћење PermissionRequestBottomSheet за природнији UX.

Важно је не блокирати потпуно функционалност апликације при одбијању. На примјер, ако је корисник одбио геолокацију, апликација треба да понуди речно уношење адресе. За камеру — да омогући учитавање слике из галерије. Google препоручује увијек обезбједити fallback механизам за све runtime permissions.

Препоруке за безбедност

Runtime permissions нису само технички механизам, већ и елемент поверења корисника у апликацију. Захтев дозволе у неповољном тренутку (на примјер, при првом покретању) значајно смањује вероватноћу прихватања. Google Play Store анализира учесталост и контекст захтева дозвола: апликације са агресивним захтевима добијају ниже позиције у претраживању.

Правила захтева дозвола

Контекст — захтевајте дозволу непосредно пре извршавања радње која је захтева. Минимум — захтевајте само оне дозволе које су стварно потребне за рад функције. Транспарентност — објасните кориснику зашто је потребно дозволење пре системског дијалога. Повлачење — претплатите се на ACTION_PERMISSION_REVOCATION за правилну обраду повлачења дозволе у радном времену.

За тестирање runtime permissions користите adb команде: adb shell pm revoke <package> android.permission.CAMERA омогућава симулацију повлачења дозволе без поновне инсталације апликације. Espresso и UiAutomator подржавају тестирање дијалога дозвола кроз GrantPermissionRule. Интеграција ових алата у CI/CD пиплајн је обавезна за апликације са runtime permissions.

Аудит дозвола у Google Play Console-у

Google Play Console пружа секцију Permission auditing (аудит дозвола), где програмер види колико често се захтевају дозволе, колики проценат корисника одобрава приступ и које су дозволе повучене. Анализа ових података помаже да се идентификују неефикасни захтеви и оптимизује UX. На примјер, ако мање од 40% корисника одобрава геолокацију, вреди преиспитати тајминг захтева и додати уверљивијије образложење.

Коришћење Android Vitals за праћење permission-related ANR (апликација не реагује) је такође критично. Ако се захтев дозволе извршава на главном протоку или системски дијалог блокира UI, то може изазвати ANR на спорим уређајима. Пребаците провјеру и захтев дозвола на посебан проток или користите Kotlin корутине за асинхроно процесирање да бисте избегли блокирања корисничког интерфејса.