Runtime Permission: які бувають типи та принцип роботи в Android

Що таке Runtime Permission?

Runtime Permission — це модель безпеки Android, за якої застосунок запитує доступ до конфіденційних даних у момент, коли ця функціональність дійсно потрібна користувачеві. До Android 6.0 всі дозволи надавалися під час інсталяції застосунку, і користувач не міг відкликати їх без повного видалення застосунку.

Еволюція моделі дозволів Android

До Android 6.0 користувач бачив список усіх дозволів під час інсталяції та міг або погодитися на всі, або відмовитися від інсталяції. Дослідження 2015 року показало, що 87% користувачів не читають список дозволів під час інсталяції. Android 6.0 ввів runtime permissions, розділивши дозволи на звичайні (автоматичні) та небезпечні (із запитом). Android 11 додав одноразові дозволи — автоматичне відкликання після закриття застосунку. Android 13 ввів Photo Picker і push-сповіщення як окремі runtime permissions.

iOS використовує подібну модель з версії iOS 10, де доступ до камери, мікрофона та геолокації запитується при першому зверненні. Однак iOS не має поняття «звичайних дозволів» — кожен дозвіл запитується явно, а відмова зберігається до повторного запиту розробником через системні налаштування.

Як працює Runtime Permission в Android?

Runtime Permission працює через системний діалог, який викликається методом requestPermissions() (AndroidX — ActivityResultLauncher). Система показує стандартний діалог із поясненням, і користувач обирає «Дозволити» або «Заборонити». Після відповіді викликається колбек результату, де застосунок обробляє рішення користувача.

Запит дозволу через 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 класифікує всі дозволи на кілька рівнів захисту: звичайні, небезпечні, підпису та спеціальні. Звичайні дозволи надаються автоматично під час інсталяції. Небезпечні дозволи потребують runtime-запиту. Дозволи підпису доступні лише застосункам, підписаним тим самим сертифікатом.

Групи небезпечних дозволів

Спеціальні дозволи (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) потребують додаткового переходу в системні налаштування через Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Ці дозволи не можуть бути запитані стандартним системним діалогом і потребують явного переходу користувача в екран налаштувань.

Запит дозволів в Android 12+

Android 12 представив значні зміни в моделі runtime permissions. Одноразові дозволи дозволяють надати доступ до камери, мікрофона або геолокації лише на один сеанс. Як тільки користувач закриває застосунок, дозвіл автоматично відкликається. Індикатори приватності — зелені індикатори в рядку стану, які показують, коли застосунок використовує камеру або мікрофон.

Обробка одноразових дозволів

// 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 до групи небезпечних, вимагаючи явного запиту на надсилання push-сповіщень. Android 14 ввів обмеження на фонову геолокацію: застосунок повинен отримувати явне схвалення користувача щоразу при запиті фонового розташування. 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 підтримують тестування permission-діалогів через GrantPermissionRule. Інтеграція цих інструментів у CI/CD пайплайн обов'язкова для застосунків із runtime permissions.

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

Google Play Console надає розділ аудиту дозволів, де розробник бачить, як часто запитуються дозволи, який відсоток користувачів надає доступ і які дозволи були відкликані. Аналіз цих даних допомагає виявити неефективні запити та оптимізувати UX. Наприклад, якщо менше 40% користувачів надають геолокацію, варто переглянути таймінг запиту та додати більш переконливе обґрунтування.

Використання Android Vitals для моніторингу permission-related ANR (Application Not Responding) також критичне. Якщо запит дозволу виконується на головному потоці або системний діалог блокує інтерфейс, це може викликати ANR на повільних пристроях. Виносьте перевірку та запит дозволів в окремий потік або використовуйте корутини Kotlin для асинхронної обробки, щоб уникнути блокування інтерфейсу користувача.