Denegación y no volver a preguntar

Escribir el camino feliz de un permiso es trivial: se pide, se concede, se ejecuta. Todo el trabajo real de ingeniería está en las ramas que casi nadie escribe, y su ausencia produce una familia de defectos con una firma inconfundible: la pantalla en blanco con un botón que no hace nada, el diálogo que reaparece en bucle hasta que el usuario cierra la aplicación, el mensaje que dice que se necesita un permiso sin explicar cuál ni dónde concederlo. Ninguno de esos comportamientos es fruto de la mala fe; todos son fruto de haber modelado la concesión como un booleano cuando en realidad es una máquina de estados con memoria, con transiciones irreversibles desde dentro del proceso y con una API deliberadamente incompleta que obliga a reconstruir parte del estado por tu cuenta. Aprender a manejar la denegación no es una tarea de cortesía: es la mitad del trabajo, y es la mitad que decide si tu aplicación sigue instalada mañana.

Tres estados detrás de una API que devuelve dos

Desde el punto de vista del usuario, un permiso puede estar en tres situaciones: concedido, denegado con posibilidad de volver a preguntar, y denegado de forma que el sistema ya no mostrará ningún diálogo. Desde el punto de vista de tu código, en cambio, solo dispones de dos consultas, y ninguna de ellas devuelve directamente la tercera situación.

La primera consulta es el estado actual, que responde si el permiso está concedido o no. La segunda es shouldShowRequestPermissionRationale, cuyo nombre describe su intención pero no su semántica: devuelve verdadero cuando el usuario ya denegó al menos una vez y el sistema todavía está dispuesto a mostrar el diálogo. Devuelve falso en dos situaciones radicalmente distintas que hay que aprender a separar: cuando nunca se ha preguntado, y cuando ya no se puede preguntar más.

Esa ambigüedad no es un descuido de la API sino una consecuencia de que el sistema no quiere darte una señal explícita de agotamiento, precisamente para que no construyas experiencias que castiguen al usuario por haber dicho que no. La ambigüedad, sin embargo, es tuya y hay que resolverla, porque la interfaz correcta en cada uno de los dos casos es completamente distinta.

Android 11 endureció además la mecánica. Desapareció la casilla explícita de no volver a preguntar y la sustituyó una regla implícita: dos denegaciones consecutivas equivalen a una denegación permanente, y a partir de ahí toda solicitud se resuelve inmediatamente como negativa sin mostrar nada al usuario. La llamada no falla, no lanza excepción y no avisa: devuelve un no instantáneo. Un bucle de reintentos escrito ingenuamente se convierte así en un bucle infinito silencioso.

El detalle que hace este cambio especialmente traicionero es que las dos denegaciones no tienen que ocurrir en la misma sesión. El sistema conserva el contador entre ejecuciones y entre actualizaciones de la aplicación, de modo que un usuario que rechazó una vez hace tres meses agota su segunda oportunidad la próxima vez que dice que no, sin que nada en tu código lo distinga del primer rechazo. La ventana de negociación es, en la práctica, mucho más estrecha de lo que sugiere la lectura ingenua de la documentación.

Hay además un cuarto estado que complica el modelo en los permisos de cámara, micrófono y ubicación: la concesión de una sola vez. El permiso se otorga de verdad, la funcionalidad funciona, y cuando la aplicación abandona el primer plano durante el tiempo suficiente la concesión caduca sola. Desde el punto de vista del código no es un estado nuevo sino un recordatorio de la regla general, que aquí se vuelve obligatoria en lugar de recomendable: comprobar antes de cada uso, no una vez por sesión.

stateDiagram-v2
[*] --> Virgen
Virgen --> Concedido: acepta
Virgen --> Denegado: rechaza
Denegado --> Concedido: acepta en segunda peticion
Denegado --> Permanente: rechaza otra vez
Permanente --> Concedido: cambio manual en Ajustes
Concedido --> Denegado: revocacion manual

Inferir la denegación permanente sin equivocarse

El algoritmo correcto exige una pieza de estado que la plataforma no guarda por ti: la memoria de haber preguntado alguna vez. Con esa pieza, la desambiguación es inmediata y no admite discusión.

Si nunca has preguntado, el falso de la consulta significa que estás ante un usuario virgen y lo que corresponde es pedir directamente, quizá con una explicación previa si el permiso es delicado. Si ya preguntaste y la consulta devuelve verdadero, el usuario dijo que no una vez y merece una explicación mejor antes del segundo intento. Y si ya preguntaste y devuelve falso, la puerta del diálogo está cerrada y la única vía es Ajustes.

enum class EstadoPermiso { CONCEDIDO, PEDIBLE, EXPLICABLE, BLOQUEADO }

fun estadoDe(activity: Activity, permiso: String, yaSePregunto: Boolean) = when {
    ContextCompat.checkSelfPermission(activity, permiso) ==
        PackageManager.PERMISSION_GRANTED -> EstadoPermiso.CONCEDIDO
    ActivityCompat.shouldShowRequestPermissionRationale(activity, permiso) ->
        EstadoPermiso.EXPLICABLE
    yaSePregunto -> EstadoPermiso.BLOQUEADO
    else -> EstadoPermiso.PEDIBLE
}

La bandera yaSePregunto debe persistirse por permiso y sobrevivir a la muerte del proceso, porque la solicitud y el diagnóstico ocurren en sesiones distintas. Un mapa en almacenamiento de preferencias, escrito en el mismo instante en que se lanza la petición, resuelve el problema con exactitud suficiente.

Conviene envolver todo esto en un tipo propio en lugar de repartir las comprobaciones por la interfaz, porque el valor de la clasificación está justamente en que la pantalla no tenga que razonar sobre permisos sino elegir entre cuatro presentaciones. La diferencia entre una base de código que maneja bien la denegación y una que no suele reducirse a si existe o no existe este enumerado.

class GestorDePermisos(private val prefs: SharedPreferences) {

    fun marcarPreguntado(permiso: String) =
        prefs.edit().putBoolean(clave(permiso), true).apply()

    fun yaSePregunto(permiso: String) =
        prefs.getBoolean(clave(permiso), false)

    private fun clave(permiso: String) = "preguntado_$permiso"
}

Degradar con dignidad en lugar de cancelar

La respuesta correcta a una denegación casi nunca es un mensaje de error. Es una ruta alternativa que entrega parte del valor sin el dato que se negó. Construir ese catálogo de alternativas antes de escribir la solicitud invierte el orden habitual del trabajo y produce aplicaciones mucho mejores, porque obliga a preguntarse qué queda cuando falta el permiso, que es exactamente la pregunta que el usuario acaba de hacerse.

Conviene además medir. Registrar, por permiso y por punto de solicitud, cuántas veces se muestra el diálogo y cómo se resuelve, convierte una discusión de opiniones sobre textos en una comparación de cifras. Es una de las pocas métricas de producto que cabe en una tabla de tres columnas y que suele producir un cambio de diseño en la primera semana de datos.

La regla general que ordena todo el catálogo se puede enunciar así: el permiso es una optimización de la experiencia, no un requisito de la funcionalidad, salvo en el puñado de casos donde la aplicación entera es el permiso. Una aplicación de cámara sin cámara no tiene alternativa razonable, y en ese caso la honestidad consiste en explicarlo con claridad y ofrecer la ruta a Ajustes, no en fingir que hay un plan B.

Hay además una categoría de degradación que se olvida sistemáticamente: la degradación parcial dentro de una misma funcionalidad. Sin ubicación exacta se puede seguir mostrando el mapa centrado en la ciudad. Sin acceso a contactos se puede seguir enviando el mensaje escribiendo el número. Sin notificaciones se puede seguir mostrando el aviso dentro de la aplicación cuando el usuario la abre. Cada una de estas rutas cuesta unas pocas horas y elimina un motivo de desinstalación.

when (estado) {
    EstadoPermiso.CONCEDIDO -> mostrarClimaLocal()
    EstadoPermiso.PEDIBLE -> pedirUbicacion.launch(PERMISO_APROXIMADO)
    EstadoPermiso.EXPLICABLE -> explicar { pedirUbicacion.launch(PERMISO_APROXIMADO) }
    EstadoPermiso.BLOQUEADO -> mostrarBuscadorDeCiudad()
}

Llevar a Ajustes sin convertirlo en un peaje

Cuando el estado es bloqueado y la funcionalidad no admite alternativa, la única salida es la pantalla de detalles de la aplicación en los ajustes del sistema. Abrirla es sencillo; lo que hay que hacer bien es el regreso, porque el usuario puede volver habiendo concedido, habiendo denegado o sin haber tocado nada, y no recibirás ninguna notificación de ello.

fun abrirAjustesDeLaApp(context: Context) {
    val intent = Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", context.packageName, null),
    )
    context.startActivity(intent)
}

La detección del cambio se hace revisando el estado en cada reanudación del ciclo de vida, no al recibir un resultado. Es una de las pocas ocasiones en que consultar el estado en onResume es la solución correcta y no un síntoma de mal diseño: el sistema ha cambiado a tus espaldas y tu única oportunidad de enterarte es mirar cuando vuelves al primer plano.

Merece la pena señalar que la ruta a Ajustes no es un destino único. Varias capacidades tienen su propia pantalla —la ubicación, las notificaciones, las alarmas exactas, el acceso a todos los archivos— y llevar al usuario al ajuste específico en lugar de a la ficha general reduce drásticamente la tasa de abandono, porque elimina el paso en que la persona tiene que buscar entre una lista de opciones cuyo nombre no coincide con el de tu mensaje.

El asunto delicado no es técnico sino ético, y tiene consecuencias directas en la revisión de la tienda. Un enlace a Ajustes que aparece una vez, con un texto que explica exactamente qué interruptor buscar, es una ayuda. El mismo enlace mostrado en un diálogo que no se puede cerrar, o repetido en cada arranque, o presentado como condición para seguir usando algo que funcionaba perfectamente sin él, es coacción, y las políticas de Google Play lo tratan como tal. La diferencia entre ambas cosas no está en el código sino en si el usuario puede seguir adelante después de decir que no.