Register now for Android Dev Summit 2019!

Solicitud de permisos en Wear OS

Android 6.0 (nivel de API 23) introdujo un nuevo modelo de permisos, que aporta algunos cambios específicos para Wear OS by Google y otros cambios que se aplican a todos los dispositivos con tecnología Android.

Un usuario puede otorgar permisos a una app para Wear incluso cuando hay una app para teléfonos complementaria. A partir de Android 6.0 (nivel de API 23), una app para Wear no puede recibir permisos otorgados en una app para teléfonos. Por ejemplo, si un usuario otorga a una app para teléfonos el permiso de usar datos de ubicación, el usuario de la app para Wear deberá otorgar el mismo permiso.

Nota: En esta página, se da por sentada la posibilidad de crear una app para teléfonos como complemento de tu app para reloj. No obstante, no es necesario que crees una app para teléfonos, ya que tu app para reloj puede ser independiente.

Tanto en el caso de las apps para Wear como el de las apps para teléfonos, el modelo de permisos de Android 6.0 (nivel de API 23) también facilita la instalación y actualización de estas ya que se elimina el requisito de que el usuario otorgue por adelantado todos los permisos que podrían imponer. En lugar de ello, las apps no solicitan permisos hasta que los necesitan.

Nota: Para que una app use el nuevo modelo de permisos, debe especificar un valor de 23 para uses-sdk-element y compileSdkVersion.

En el resto de este documento, se aborda la manera de usar el modelo de permisos de Android 6.0 (nivel de API 23) en el desarrollo de apps para Wear OS.

Situaciones de permisos

A grandes rasgos, hay cuatro situaciones que podrías atravesar al solicitar permisos peligrosos en Wear OS:

  • La app para Wear solicita permisos para una app que se ejecuta en el dispositivo wearable.
  • La app para Wear solicita permisos para una app que se ejecuta en el teléfono.
  • La app para teléfonos solicita permisos para una app que se ejecuta en el dispositivo wearable.
  • La app para wearables usa un modelo de permisos diferente del que emplea la app para teléfonos.

En el resto de esta sección, se explica cada una de esas situaciones. Para obtener información detallada sobre la solicitud de permisos, consulta Patrones de solicitud de permisos.

La app para Wear solicita un permiso para una app que se ejecuta en el dispositivo wearable

Cuando la app para Wear solicita un permiso para una app que se ejecuta en el dispositivo wearable, el sistema muestra un diálogo para informar al usuario sobre ese permiso. Una app o un servicio solo puede llamar al método requestPermissions() desde una actividad. Si el usuario interactúa con tu app mediante un servicio, como una cara de reloj, el servicio debe abrir una actividad antes de solicitar el permiso.

Tu app solicita permisos en contexto cuando resulta claro el motivo por el que se requieren los permisos para realizar una operación específica. Si es evidente que tu app necesita ciertos permisos, puede solicitarlos al iniciarse. Si no es tan evidente, puedes optar por proporcionar más información antes de solicitar un permiso.

Si una app o una cara de reloj solicita más de un permiso a la vez, las solicitudes aparecen una después de otra.

Varias pantallas de permisos, una después de otra.

Figura 1: Pantallas de permisos que aparecen en sucesión

Nota: A partir de Android 6.0 (nivel de API 23), Wear OS sincroniza automáticamente datos de Calendario, de Contactos y de ubicación con el dispositivo Wear. En consecuencia, esta situación es la que se aplica cuando Wear solicita estos datos.

Una app para Wear solicita permiso de teléfono

Cuando solicita un permiso de teléfono, la app para Wear debe solicitar al usuario que acepte el permiso en el teléfono. Allí, la app para teléfonos puede proporcionar al usuario información adicional mediante una actividad. La actividad debe incluir dos botones: uno para otorgar el permiso y uno para denegarlo.

La app para Wear solicita al usuario que otorgue el permiso en el teléfono.

Figura 2: Solicitud para que el usuario otorgue el permiso en el teléfono

La app para teléfonos solicita un permiso para wearable

Cuando el usuario usa una app para teléfonos y esta solicita un permiso para wearable, la app debe solicitar al usuario que acepte el permiso en el wearable. La app para teléfonos usa el método requestPermissions() en el wearable para activar el diálogo de permisos del sistema.

La app para teléfono solicita al usuario que otorgue el permiso en el wearable.

Figura 3: Solicitud para que el usuario otorgue el permiso en el wearable

Modelos de permisos diferentes entre la app para wearable y teléfono

Si tu app para teléfonos comienza usando el modelo de Android 6.0 (nivel de API 23) y tu app para wearable no, el sistema descarga la app para Wear, pero no la instala. La primera vez que el usuario inicia la app, el sistema le solicita otorgar todos los permisos pendientes. Una vez que el cliente lo hace, el sistema instala la app. Si tu app (por ejemplo, una cara de reloj) no tiene un selector, el sistema muestra una notificación de flujo en la que se le solicita al usuario que otorgue los permisos que la app necesita.

Patrones de solicitud de permisos

Hay diferentes patrones para solicitar permisos de los usuarios. En orden de prioridad, son los siguientes:

  • Solicitud en contexto: Cuando el permiso sea claramente necesario para una funcionalidad específica, pero no sea necesario para que la app pueda ejecutarse.
  • Informe en contexto: Cuando el motivo para solicitar el permiso no sea evidente y el permiso no sea necesario para que la app pueda ejecutarse.
  • Solicitud de antemano: Cuando la necesidad del permiso sea evidente y este sea necesario para que la app pueda ejecutarse.
  • Informe de antemano: Cuando la necesidad del permiso no sea evidente, pero el permiso sea necesario para que la app pueda ejecutarse.

Solicitud en contexto

Tu app debe solicitar permisos cuando sea claro el motivo por el que se necesitan para realizar una operación determinada. Es más probable que los usuarios otorguen un permiso cuando comprendan la conexión con la función que quieran usar.

Por ejemplo, una app puede requerir la ubicación de un usuario para poder mostrar lugares de interés cercanos. Cuando el usuario presiona la pantalla para buscar lugares cercanos, la app puede solicitar de inmediato el permiso de ubicación, ya que hay una relación clara entre la búsqueda de lugares cercanos y la necesidad del permiso de ubicación. La obviedad de esta relación evita la necesidad de que la app muestre pantallas informativas adicionales.

La app solicita permiso cuando la necesidad es obvia.

Figura 4: Solicitar en contexto

Informe en contexto

Si es necesario, puedes optar por proporcionar más información antes de solicitar un permiso. Nuevamente, tu app debe hacerlo en el contexto de una acción específica si no es claro el motivo por el que necesita acceso al permiso solicitado para poder completar la acción.

En la figura 5, se muestra un ejemplo de la información en contexto. La app no requiere permisos para poder iniciar el cronómetro, pero una indicación informativa integrada muestra que parte de la actividad (detección de ubicación) está bloqueada. Cuando el usuario presiona la indicación, aparece una pantalla de solicitud de permisos que le permite desbloquear la detección de ubicación.

Puedes usar el método shouldShowRequestPermissionRationale() para ayudar a tu app a decidir si debe proporcionar más información. Para obtener información detallada, consulta Cómo solicitar permisos durante el tiempo de ejecución.

Cuando se presenta la necesidad de un permiso, la app explica por qué este se necesita.

Figura 5: Información en contexto

Solicitud de antemano

Si tu app claramente requiere un permiso para poder funcionar, puedes solicitar ese permiso cuando el usuario la inicie. Por ejemplo, una app de mapas requiere acceso a la ubicación del dispositivo para ejecutar sus actividades previstas. No es necesario proporcionar información adicional para este permiso.

Si resulta obvio que la app necesita un permiso para ejecutarse, puede solicitarlo de inmediato durante el inicio.

Figura 6: Solicitud de antemano

Informe de antemano

En algunos casos, la app requiere un permiso para funcionalidades básicas, pero la necesidad de ese permiso no es evidente. En estos casos, cuando el usuario inicia la app o configura una cara de reloj, la app o la cara de reloj pueden informar al usuario y solicitarle el permiso.

Al solicitar el permiso durante el inicio, la app puede explicar el motivo por el que lo necesita.

Figura 7: Información de antemano

Control de los rechazos

Si un usuario rechaza un permiso solicitado que no es crítico para una actividad prevista, no evites que continúe con la actividad. Si la denegación del permiso inhabilita ciertas partes de la actividad, proporciona comentarios visuales e interactivos. En la figura 8, se muestra el uso de un ícono de bloqueo para indicar que una función está bloqueada porque el usuario no otorgó el permiso para usarla.

Cuando el usuario no otorga un permiso, aparece un ícono de cerrojo a lo largo de la característica asociada.

Figura 8: Ícono de bloqueo que muestra que una función está bloqueada porque se denegó el permiso

Cuando aparezca por segunda vez un diálogo de permiso para wearable previamente denegado, se incluirá la opción para denegar y no volver a mostrar. Si el usuario selecciona esta opción, la única manera de otorgar este permiso en el futuro será mediante la app Configuración del wearable.

El sistema ofrece detener la solicitud de permisos.

Figura 9: Ofrecimiento de no mostrar más la pantalla de solicitud de permisos

Permisos para servicios

Como se mencionó antes, solo una actividad puede llamar al método requestPermissions(), de modo que, si el usuario interactúa con tu app mediante un servicio (por ejemplo, una cara de reloj), el servicio debe abrir una actividad en segundo plano antes de solicitar el permiso. Esta actividad podría proporcionar información adicional o simplemente podría ser una actividad visible que active el diálogo del sistema.

Si tu app para wearables ejecuta un servicio que no es una cara de reloj, y el usuario no inicia una app en la que tendría sentido solicitar un permiso, puedes publicar una notificación informativa en el wearable. Esta puede proporcionar una acción para abrir una actividad que luego active el diálogo de permisos del sistema.

Nota: Este es el único uso aceptable de una notificación de flujo para solicitudes de permiso.

El usuario podría necesitar otorgar un permiso al interactuar de forma indirecta con una app, mediante un servicio.

Figura 10: Servicio solicitando permiso

Configuración

Al igual que en el teléfono, el usuario puede cambiar los permisos de una app para Wear desde Configuración en cualquier momento. Por lo tanto, cuando el usuario intenta realizar algo que requiere un permiso, la app siempre debe llamar primero al método checkSelfPermission() a fin de comprobar si tiene el permiso para realizar esta operación. La app debe realizar esta comprobación aunque detecte que el usuario otorgó el permiso con anterioridad, ya que es probable que lo haya revocado posteriormente.

El usuario puede cambiar los permisos mediante la app Configuración.

Figura 11: Cambio de la configuración con la app Configuración