Cada fin de semana volvemos a la carga con información para los desarrolladores, incluyendo artículos en los que recopilamos consejos, indicaciones, herramientas, libererías… en resumen, todo lo necesario para sacar adelante una aplicación para Android. La semana pasada os traíamos un curioso test:
En esta ocasión, y tras haber puesto a prueba algunos de vuestros conocimientos, hemos decidido que es el momento de dar a conocer un interesante tutorial para ver cómo funcionan los permisos de Android desde la llegada de MarshMallow, y no a nivel de usuario, sino desde el punto de vista del desarrollador.
Permisos de Android hasta MarshMallow: fichero Manifest
Hasta Android 6.0 MarshMallow, cuando instalábamos una aplicación, ésta nos daba una lista de todos los permisos que necesitaba para poder funcionar. Una vez los validábamos, la aplicación tenía libre acceso a los mismos sin que el usuario tuviera que volver a autorizar ningún otro acceso por parte de la aplicación.
Para ello, el desarrollador tan sólo tenía que elegir los permisos que necesitaba e incluirlos en el fichero Manifest, tal que así:
Para saber qué permisos necesitaría y los valores, bastaba con consultar las opciones:
Pero como inconveniente teníamos que una vez concedido el permiso, el acceso al mismo ya no era controlado por el usuario de ninguna de las maneras. Tan sólo podíamos desinstalar la aplicación. Dado que la seguridad en Android siempre ha sido un tema polémico, solamente era cuestión de tiempo que Google decidiera tomar alguna medida al respecto.
Permisos a partir de MarshMallow: Manifest y Runtime
Y así ocurrió con Marshmallow, una actualización de sistema operativo que vino con una gran novedad en cuanto a los permisos. La actualización, además de algunos retoques en la interfaz, llegó con la intención de solucionar este posible problema devolviendo el control sobre los permisos al usuario. Por ello, decidieron que los permisos más críticos no sólo debían ser declarados en el Manifest, sino también debían solicitar el acceso en el momento de su uso.
De este modo, y a través de los ajustes, el usuario podría en cualquier momento revocar un permiso a una aplicación.
Para programar esto, en primer lugar debemos saber qué permisos necesitan la solicitud de acceso en el momento de ejecución. Estos permisos son, obviamente, los que más peligro pueden suscitar al ser concedidos, y es posible comprobar todos y cada uno de ellos en esta lista:
Si alguno de los permisos de nuestra app aparece en esta lista, entonces (justo antes de usarlo) debemos incluir el código para poder comprobar si el permiso ha sido concedido o no, como -por ejemplo- en el caso de querer escribir en el calendario, en cuyo caso el código sería el siguiente:
Con el anterior código, lo que obtenemos es un valor después haber sido comprobado el permiso en cuestión. Pero, ¿y ahora qué? Pues tan sencillo como, en base al valor obtenido, solicitar al sistema operativo que muestre un diálogo para aceptar/denegar el permiso o hacer uso del permiso en sí si ya fue concedido anteriormente.
En el caso de una lectura de contactos, estas comprobaciones tendrían esta estructura:
Esto nos lleva a plantearnos un problema: si delegamos en el sistema operativo para mostrar el diálogo de los permisos, ¿cómo sabemos en nuestro código cuándo éste ha sido elegido y queremos volver a recuperar el control?
Android nos ofrece un método para sobreescribir, un método que será lanzado cada vez que el sistema operativo notifique que un permiso ha sido concedido o denegado: se trata de onRequestPermissionsResult. Por tanto, en este punto volveremos a recuperar el control y podremos volver a comprobar si el permiso fue concedido o no:
Además, para terminar de asimilar toda esta información, Google nos sugiere una guía de buenas prácticas a la hora de gestionar estos permisos:
Y con todo esto, tenemos información suficiente para evitar que nos ocurra como a otras apps que no han sabido gestionar bien la nueva forma de trabajar con los permisos. ¿Está la tuya ya actualizada?