Cuando tu aplicación accede a datos sensibles como la ubicación o usa hardware como la cámara, Android exige declarar y solicitar permisos en tiempo de ejecución. Aprenderás a configurar el AndroidManifest, crear extension functions reutilizables en Kotlin y manejar el rationale para persuadir al usuario, una habilidad clave si desarrollas apps móviles modernas.

¿Qué permisos se declaran en el AndroidManifest?

El primer paso siempre ocurre en el archivo AndroidManifest.xml, donde registras lo que tu aplicación va a usar. Sin esa declaración, Android no te deja avanzar [0:25].

En el caso de la localización, hay dos tipos que conviene diferenciar:

• ACCESS_COARSE_LOCATION: la ubicación aproximada que entrega la red celular.
• ACCESS_FINE_LOCATION: la ubicación precisa que proporciona el GPS, y es la que requiere permiso explícito en tiempo de ejecución.
• POST_NOTIFICATIONS y CAMERA: otros permisos sensibles que también se piden en runtime.

¿Qué es un permiso en tiempo de ejecución en Android? Es un permiso que el usuario debe aprobar mientras la app corre, no solo al instalarla. Aplica a datos sensibles como ubicación, cámara o notificaciones.

¿Cómo crear extension functions para validar permisos en Kotlin?

Una buena práctica es centralizar la lógica de permisos en un archivo de utilidades. Dentro de la carpeta presentation, creas un package llamado utils y allí un archivo PermissionsUtils con extension functions sobre Context [1:15].

La función base se apoya en ContextCompat.checkSelfPermission y compara el resultado con PackageManager.PERMISSION_GRANTED. A partir de ahí, construyes funciones específicas que reutilizan esa validación.

¿Cómo validar el permiso de localización?

Defines una función hasLocationPermission sobre Context que retorna un boolean. Internamente llama a hasPermission(android.Manifest.permission.ACCESS_FINE_LOCATION). Así, en cualquier parte de la app puedes preguntar de forma limpia si el GPS está autorizado.

¿Cómo manejar el permiso de notificaciones según la versión de Android?

Aquí entra un detalle importante: el permiso POST_NOTIFICATIONS solo existe a partir de Android Tiramisú (API 33). Por eso la función hasNotificationPermission evalúa primero si Build.VERSION.SDK_INT es mayor o igual a VERSION_CODES.TIRAMISU [3:30].

Si la versión es compatible, valida el permiso real. Si es anterior, simplemente retorna true. Con esto garantizas retrocompatibilidad entre sistemas operativos sin romper la app en dispositivos antiguos.

¿Y la cámara?

La función hasCameraPermission sigue el mismo patrón, cambiando el string del permiso por android.Manifest.permission.CAMERA. Aunque no la uses todavía, dejarla lista en tus extension functions ahorra trabajo futuro.

¿Qué es el rationale y cuándo debes mostrarlo?

Las buenas prácticas en Android indican que debes pedir un permiso justo cuando se va a usar, no al inicio sin contexto. Si el usuario lo niega por accidente o decisión, el sistema activa una bandera llamada rationale [5:00].

Esa bandera te permite mostrar un diálogo explicando por qué tu app necesita ese permiso. Sin ese contexto, las probabilidades de que el usuario lo conceda en un segundo intento bajan mucho.

¿Qué hace shouldShowRequestPermissionRationale? Devuelve true cuando el usuario ya rechazó un permiso pero aún puedes pedirlo de nuevo. Es la señal para mostrar un diálogo persuasivo antes de relanzar la solicitud.

¿Cómo implementar shouldShowRationale en cada caso?

Defines extension functions sobre ComponentActivity:

• shouldShowLocationPermissionRationale: invoca shouldShowRequestPermissionRationale con ACCESS_FINE_LOCATION.
• shouldShowNotificationPermissionRationale: primero valida que la versión sea Tiramisú o superior y luego pregunta por POST_NOTIFICATIONS.
• shouldShowCameraPermissionRationale: aplica directamente sobre el permiso CAMERA.

kotlin fun ComponentActivity.shouldShowLocationPermissionRationale(): Boolean { return shouldShowRequestPermissionRationale( android.Manifest.permission.ACCESS_FINE_LOCATION ) }

Con este conjunto de utilidades tienes una base sólida para pedir permisos a lo largo de toda tu aplicación de forma consistente. El siguiente paso natural es construir un diálogo que levante ese rationale y le explique al usuario, en el momento adecuado, por qué necesitas acceso. ¿Cómo lo resolverías tú en tu próxima app? Cuéntame en los comentarios.