Solicitar 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 complementaria para el teléfono. A partir de Android 6.0 (nivel de API 23), una app para Wear no puede recibir permisos otorgados en una app para teléfono. Por ejemplo, si un usuario otorgue a una app para teléfono 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 que crees una app para teléfono como complemento de tu app para reloj. No obstante, no es necesario que crees una app para teléfono, ya que tu app para reloj puede ser independiente.

Tanto en el caso de apps para Wear como para teléfono, el modelo de permisos de Android 6.0 (nivel de API 23) también facilita la instalación y actualización de estas al eliminar 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: Las apps que usan el nuevo modelo de permisos deben 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 móvil.
  • La app para teléfono 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 servicio solo puede llamar al método requestPermissions() desde una actividad. Si el usuario interactúa con tu app a través de 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 cuando al iniciarse. Si no es tan predecible, 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 de permisos aparecen una después de otra.

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

Figura 1: Pantallas de permisos en sucesión.

Nota: A partir de Android 6.0 (nivel de API 23), Wear OS sincroniza automáticamente datos del calendario, de los contactos y de la 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éfono puede proporcionar al usuario información adicional a través de 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 de teléfono solicita un permiso para wearable

Cuando el usuario usa una app para teléfono y esta solicita un permiso para wearable, la app debe solicitar al usuario que acepte el permiso en el wearable. La app para teléfono 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éfono 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 lanzador, el sistema muestra una notificación de flujo en la que se le solicita al usuario otorgar 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:

  • Solicitar en contexto cuando el permiso sea claramente necesario para una funcionalidad específica, pero no sea necesario para que la app pueda ejecutarse.
  • Informar en contexto, cuando el motivo para solicitar el permiso no sea evidente y el permiso no sea necesario para que la app pueda ejecutarse.
  • Realizar la solicitud de antemano, cuando la necesidad del permiso sea evidente y este sea necesario para que la app pueda ejecutarse.
  • Informar de antemano, cuando la necesidad del permiso no sea obvia, pero el permiso sea necesario para que la app pueda ejecutarse.

Solicitar 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 característica 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 aplica un toque para buscar sitios 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: Solicitud en contexto.

Información en contexto

Si fuera necesario, puedes optar por proporcionar más información antes de solicitar un permiso. Nuevamente, tu app debe hacer esto 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 toca 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 Solicitar permisos en 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 claramente 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.

Información 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 permiso.

Figura 7: Información de antemano.

Controlar rechazos

Si un usuario rechaza un permiso solicitado que no es crítico para una actividad prevista, no evites que den continuidad a la actividad. El 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 cerrojo para indicar que una característica 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 cerrojo, muestra que una característica está bloqueada debido a la denegación de un permiso.

Cuando aparezca por segunda vez un diálogo de permiso para wearable previamente denegado, se incluirá la opción Deny, don't show again (denegar, no mostrar de nuevo). Si el usuario selecciona esta opción, la única manera de otorgar este permiso en el futuro será a través de 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ó anteriormente, solo una actividad puede llamar al método requestPermissions(), de modo que si el usuario interactúa con tu app a través de 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. La notificación 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, a través de 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 a través de la app Configuración.

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