Runtime Permission: qué tipos existen y principio de funcionamiento en Android

¿Qué es Runtime Permission?

Runtime Permission es un modelo de seguridad de Android en el que la aplicación solicita acceso a datos confidenciales en el momento en que esa funcionalidad es realmente necesaria para el usuario. Antes de Android 6.0, todos los permisos se concedían al instalar la aplicación y el usuario no podía revocarlos sin desinstalarla por completo.

Evolución del modelo de permisos de Android

Antes de Android 6.0, el usuario veía una lista de todos los permisos al instalar y podía aceptarlos todos o rechazar la instalación. Un estudio de 2015 mostró que el 87% de los usuarios no lee la lista de permisos al instalar. Android 6.0 introdujo los runtime permissions, dividiendo los permisos en normales (automáticos) y peligrosos (con solicitud). Android 11 añadió los one-time permissions: revocación automática al cerrar la aplicación. Android 13 introdujo Photo Picker y las notificaciones push como runtime permissions independientes.

iOS utiliza un modelo similar desde iOS 10, donde el acceso a la cámara, el micrófono y la geolocalización se solicita en el primer uso. Sin embargo, iOS no tiene el concepto de “permisos normales”: cada permiso se solicita explícitamente y la denegación persiste hasta que el desarrollador vuelve a solicitarlo a través de la configuración del sistema.

¿Cómo funciona Runtime Permission en Android?

Runtime Permission funciona a través de un diálogo del sistema invocado por el método requestPermissions() (AndroidX — ActivityResultLauncher). El sistema muestra un diálogo estándar con una explicación y el usuario elige “Permitir” o “Denegar”. Después de la respuesta, se ejecuta un callback donde la aplicación procesa la decisión del usuario.

Solicitud de permiso mediante 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)
        }
    }
}

El método shouldShowRequestPermissionRationale devuelve true si el usuario ya ha denegado la solicitud una vez. En este caso, se recomienda mostrar un diálogo con una explicación de por qué la aplicación necesita el permiso y solo entonces volver a solicitarlo. Esto aumenta la probabilidad de consentimiento del usuario en un 30–40% (datos de Google I/O 2024).

Tipos de permisos en Android

Android clasifica todos los permisos en varios niveles de protección: normales, peligrosos, de firma y especiales. Los permisos normales se conceden automáticamente al instalar. Los permisos peligrosos requieren una solicitud en tiempo de ejecución. Los permisos de firma solo están disponibles para aplicaciones firmadas con el mismo certificado.

Grupos de permisos peligrosos

Los permisos especiales (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) requieren una navegación adicional a la configuración del sistema a través de Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Estos permisos no pueden solicitarse mediante el diálogo estándar del sistema y requieren una acción explícita del usuario en la pantalla de configuración.

Solicitud de permisos en Android 12+

Android 12 introdujo cambios significativos en el modelo de runtime permissions. Los one-time permissions permiten conceder acceso a la cámara, el micrófono o la geolocalización solo para una sesión. Cuando el usuario cierra la aplicación, el permiso se revoca automáticamente. Los indicadores de privacidad son indicadores verdes en la barra de estado que muestran cuándo una aplicación está usando la cámara o el micrófono.

Manejo de permisos de una sola vez

// Android 12+ — manejo del permiso único de geolocalización
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
        )
    )
}

// Verificar si el permiso fue revocado por el sistema (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 añadió el permiso POST_NOTIFICATIONS al grupo peligroso, requiriendo una solicitud explícita para enviar notificaciones push. Android 14 introdujo restricciones en la geolocalización en segundo plano: la aplicación debe recibir la aprobación explícita del usuario cada vez que solicita ubicación en segundo plano. Photo Picker (API 33+) reemplazó la necesidad de READ_EXTERNAL_STORAGE para la selección de imágenes.

Manejo de denegaciones del usuario

La denegación del usuario a una solicitud de permiso es una situación normal que debe manejarse correctamente. Existen dos tipos de denegación: única (el usuario pulsó “Denegar”) y permanente (el usuario seleccionó “No volver a preguntar”). En el segundo caso, el diálogo del sistema ya no aparecerá y la aplicación debe redirigir al usuario a la configuración del sistema.

Estrategia de manejo de denegaciones

Después de la primera denegación, la aplicación debe mostrar un diálogo de justificación — su propia explicación de por qué el permiso es necesario. Si el usuario se niega nuevamente, la aplicación debe redirigir a la pantalla de configuración de la aplicación a través de Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 recomienda usar PermissionRequestBottomSheet para una UX más natural.

Es importante no bloquear completamente la funcionalidad de la aplicación ante una denegación. Por ejemplo, si el usuario denegó la geolocalización, la aplicación debe ofrecer la entrada manual de dirección. Para la cámara, permitir subir una imagen desde la galería. Google recomienda proporcionar siempre un mecanismo de respaldo para todos los runtime permissions.

Recomendaciones de seguridad

Los runtime permissions no son solo un mecanismo técnico, sino también un elemento de confianza del usuario en la aplicación. Solicitar un permiso en un momento inadecuado (por ejemplo, al primer inicio) reduce significativamente la probabilidad de consentimiento. Google Play Store analiza la frecuencia y el contexto de las solicitudes de permisos: las aplicaciones con solicitudes agresivas obtienen posiciones más bajas en la búsqueda.

Reglas para solicitar permisos

Contexto — solicite el permiso inmediatamente antes de realizar la acción que lo requiere. Mínimo — solicite solo los permisos que sean realmente necesarios para el funcionamiento de la función. Transparencia — explique al usuario por qué necesita el permiso antes del diálogo del sistema. Revocación — suscríbase a ACTION_PERMISSION_REVOCATION para manejar correctamente la revocación de permisos en tiempo de ejecución.

Para probar runtime permissions, use comandos de adb: adb shell pm revoke <package> android.permission.CAMERA permite simular la revocación de permisos sin reinstalar la aplicación. Espresso y UiAutomator admiten pruebas de diálogos de permisos a través de GrantPermissionRule. La integración de estas herramientas en el pipeline de CI/CD es obligatoria para aplicaciones con runtime permissions.

Auditoría de permisos en Google Play Console

Google Play Console proporciona una sección de auditoría de permisos, donde los desarrolladores pueden ver con qué frecuencia se solicitan los permisos, qué porcentaje de usuarios los concede y qué permisos fueron revocados. El análisis de estos datos ayuda a identificar solicitudes ineficaces y optimizar la UX. Por ejemplo, si menos del 40% de los usuarios concede la geolocalización, considere revisar el momento de la solicitud y añadir una justificación más convincente.

El uso de Android Vitals para monitorear ANR (Application Not Responding) relacionados con permisos también es crítico. Si una solicitud de permiso se ejecuta en el hilo principal o el diálogo del sistema bloquea la UI, puede causar ANR en dispositivos lentos. Mueva la verificación y solicitud de permisos a un hilo separado o use corutinas de Kotlin para el manejo asíncrono y evitar bloquear la interfaz de usuario.