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). Система показывает стандартный диалог с объяснением, и пользователь выбирает «Разрешить» или «Запретить». После ответа вызывается колбэк результата, где приложение обрабатывает решение пользователя.

Запрос разрешения через 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 поддерживают тестирование permission-диалогов через GrantPermissionRule. Интеграция этих инструментов в CI/CD пайплайн обязательна для приложений с runtime permissions.

Permission auditing в Google Play Console

Google Play Console предоставляет раздел Permission auditing (аудит разрешений), где разработчик видит, как часто запрашиваются разрешения, какой процент пользователей предоставляет доступ и какие разрешения были отозваны. Анализ этих данных помогает выявить неэффективные запросы и оптимизировать UX. Например, если менее 40% пользователей предоставляют геолокацию, стоит пересмотреть тайминг запроса и добавить более убедительный rationale.

Использование Android Vitals для мониторинга permission-related ANR (Application Not Responding) также критично. Если запрос разрешения выполняется на главном потоке или системный диалог блокирует UI, это может вызвать ANR на медленных устройствах. Выносите проверку и запрос разрешений в отдельный поток или используйте корутины Kotlin для асинхронной обработки, чтобы избежать блокировки пользовательского интерфейса.