Skip to content

Most visited

Recently visited

navigation

Prácticas recomendadas para permisos de apps

Las solicitudes de permisos protegen la información confidencial de un dispositivo y solo deben usarse cuando el acceso a la información es necesario para el funcionamiento de tu app. En este documento se sugieren diferentes maneras de lograr la misma funcionalidad (o mejorarla) sin solicitar acceso a dicha información; no se aborda de forma exhaustiva el funcionamiento de los permisos en el sistema operativo Android.

Para obtener un panorama más general sobre los permisos de Android, consulta Permisos y datos de usuario. Para obtener información detallada sobre cómo trabajar con permisos en tu código, consulta Cómo trabajar con permisos del sistema. Para acceder a las prácticas recomendadas respecto del trabajo con identificadores únicos, consulta Prácticas recomendadas para identificadores únicos.

Principios básicos del trabajo con permisos de Android

Te recomendamos que sigas estos principios básicos cuando trabajes con permisos de Android:

1: Usa solo los permisos necesarios para que tu app funcione. Según la forma en que utilices los permisos, puede haber otra alternativa para hacer lo que necesitas (intents de sistema, identificadores, colocación de llamadas telefónicas en segundo plano) sin depender del acceso a información confidencial.

2: Presta atención a los permisos solicitados por las bibliotecas. Al incluir una biblioteca, también heredas sus requisitos de permisos. Debes tener noción de lo que incluirás, los permisos que se requieren y el propósito de estos permisos.

3: Sé transparente. Cuando solicitas un permiso, sé claro con respecto a la información a la que accedes y al motivo por el que lo haces, de modo que los usuarios puedan tomar decisiones fundamentadas. Haz que la información esté disponible junto con la solicitud de permiso y que incluya diálogos de instalación, tiempo de ejecución o actualización de permisos.

4: Haz que el acceso al sistema sea explícito. Si proporcionas indicaciones continuas cuando accedes a elementos confidenciales (por ejemplo, la cámara o el micrófono), los usuarios verán con claridad los momentos en que recopiles datos y se evitará la percepción de que lo haces de forma clandestina.

En las secciones restantes de esta guía se abordan estas reglas en mayor profundidad en el contexto del desarrollo de aplicaciones para Android.

Permisos en Android 6.0 y versiones posteriores

En Android 6.0 Marshmallow se presentó un nuevo modelo de permisos que permite que las apps soliciten permisos del usuario durante el tiempo de ejecución en lugar de hacerlo antes de la instalación. Las apps que admiten el nuevo modelo solicitan permisos cuando la app necesita los servicios o los datos protegidos por los servicios. Si bien esto no cambia (necesariamente) el comportamiento general de las apps, genera algunos cambios relevantes en la manera en que se manejan los datos confidenciales del usuario:

Mayor contexto de la situación: en el contexto de tu app, a los usuarios se les solicita permiso durante el tiempo de ejecución para acceder a la funcionalidad abarcada por esos grupos de permisos. Los usuarios son más sensibles al contexto en el que se solicita el permiso, y si no coincide lo que solicitas con el propósito de tu app es incluso más importante proporcionar al usuario una explicación detallada del motivo por el cual solicitas el permiso. Siempre que sea posible, debes proporcionar una explicación de una solicitud cuando la realizas y en un diálogo de seguimiento, si el usuario la rechaza.

Mayor flexibilidad en el otorgamiento de permisos: los usuarios pueden denegar el acceso a permisos individuales cuando se soliciten y en la configuración, pero quizá se sorprendan cuando la funcionalidad se vea afectada como consecuencia de esto. Te recomendamos controlar la cantidad de usuarios que deniegan permisos (p. ej., con Google Analytics), de modo que puedas refactorizar tu app para evitar depender de ese permiso o proporcionar una mejor explicación del motivo por el cual necesitas el permiso a fin de que tu app funcione correctamente. También debes asegurarte de que esta maneje excepciones creadas cuando los usuarios denieguen solicitudes de permisos o los desactiven en la configuración.

Mayor carga de transacciones: se solicitará que los usuarios otorguen acceso a grupos de permisos de forma individual y no grupal. Esto hace que tenga muchísima importancia minimizar la cantidad de permisos que solicitas, ya que aumenta la carga de otorgamiento de permisos para el usuario y la probabilidad de que se deniegue al menos una de las solicitudes.

Evita solicitar permisos innecesarios

En esta sección se ofrecen alternativas a casos de uso comunes que te ayudarán a limitar la cantidad de solicitudes de permisos que realices. Debido a que la cantidad y el tipo de permisos solicitados al usuario afecta las descargas, en comparación con otras apps similares que solicitan menos permisos, te recomendamos evitar solicitar permisos para funcionalidades innecesarias.

Acceso a la cámara o a contactos con solicitudes de usuario en tiempo real

En este caso, necesitas acceso ocasional a la cámara o a la información de contacto del dispositivo y no te importa solicitar permiso al usuario cada vez que lo necesites.

Si tu solicitud de acceso a datos del usuario es poco frecuente (en otras palabras, no genera para el usuario molestias inaceptables la presentación de un diálogo durante el tiempo de ejecución cada vez que necesites acceder a los datos), puedes usar una solicitud basada en intents. Android proporciona algunas intents del sistema que las aplicaciones pueden usar sin solicitar permisos, ya que el usuario decide lo que compartirá con la app, si hay algo, cuando se emite la solicitud basada en intent.

Por ejemplo, se puede usar un tipo de acción MediaStore.ACTION_IMAGE_CAPTURE o MediaStore.ACTION_VIDEO_CAPTURE basada en intent para capturar imágenes o videos sin usar directamente el objeto Camera (y sin solicitar el permiso). En este caso, la intent del sistema solicitará permiso al usuario en representación tuya cada vez que se capture una imagen.

Ejecución en segundo plano después de la pérdida de foco de audio

En este caso, tu aplicación debe ejecutarse en segundo plano cuando el usuario recibe una llamada telefónica, y retoma el foco de atención solo cuando esta finaliza.

El enfoque común en estos casos (por ejemplo, el silenciamiento o la pausa de un reproductor multimedia durante una llamada telefónica) consiste en detectar los cambios en el estado de la llamada mediante PhoneStateListener o recibir la transmisión de android.intent.action.PHONE_STATE. El problema de esta solución es que requiere el permiso READ_PHONE_STATE, que fuerza al usuario a otorgar acceso a una porción amplia de datos confidenciales, como los de ID del dispositivo y hardware de SIM y del número de teléfono de la llamada entrante.

Puedes evitar esto solicitando AudioFocus para tu app, ya que no requiere permisos explícitos (porque no accede a información confidencial). Simplemente, inserta el código necesario para colocar en segundo plano tu audio en el controlador de eventos onAudioFocusChange(); se ejecutará automáticamente cuando cambie el foco de audio del SO. Puedes encontrar documentación detallada sobre cómo hacer esto aquí.

Determina el dispositivo en el que se ejecuta tu instancia

En este caso, necesitas un identificador único para determinar el dispositivo en el que se ejecuta la instancia de tu app.

Las aplicaciones pueden tener preferencias o mensajería específicas del dispositivo (p. ej., guardar en la nube una playlist específica del dispositivo para un usuario, de modo que pueda tener varias playlists para el auto y el hogar). Una solución común consiste en usar identificadores de dispositivo como Device IMEI, pero para esto se requiere el grupo de permisos Device ID and call information (PHONE en M+). También usa un identificador que no se puede restablecer y se comparte entre apps.

Hay dos alternativas para usar estos tipos de identificadores:

  1. Usa la com.google.android.gms.iid InstanceID API. getInstance(Context context).getID() mostrará un identificador de dispositivo único para tu instancia de aplicación. El resultado es un identificador con ámbito en la instancia de app que se puede usar como clave al almacenar información sobre la app y se restablece si el usuario reinstala la app.
  2. Crea tu propio identificador limitado al almacenamiento de tu app usando funciones básicas del sistema, como randomUUID().

Crea un identificador único para publicitar o analizar el comportamiento de los usuarios

En este caso, necesitas un identificador único para compilar un perfil destinado a los usuarios que no tengan sesión activa en tu app (p. ej., para anuncios orientados a conversiones o que midan conversiones).

La creación de un perfil para publicidad y análisis del comportamiento de los usuarios puede requerir un identificador que se comparta con otras aplicaciones. Entre las soluciones comunes para esto se incluyen el uso de identificadores de dispositivo como Device IMEI, que requieren el grupo de permisos Device ID and call information (PHONE en el nivel de API 23 y en niveles superiores) y no pueden ser restablecidos por el usuario. En todos estos casos, además de usar un identificador que no admite restablecimiento y solicitar un permiso que podría resultar atípico para los usuarios, también violarías las Políticas del programa para desarrolladores de Google Play.

Desafortunadamente, en estos casos, el uso de la InstanceID API de com.google.android.gms.iid o de funciones del sistema para crear un ID con ámbito en la app no es una solución adecuada, ya que podría ser necesario compartir el ID con diferentes apps. Una solución alternativa es usar el Advertising Identifier disponible en la clase AdvertisingIdClient.Info a través del método getId(). Puedes crear un objeto AdvertisingIdClient.Info usando el método getAdvertisingIdInfo(Context) y llamar al método getId() para usar el identificador. Ten en cuenta que este método es de bloqueo, por lo cual no debes llamarlo desde el subproceso principal. Puedes encontrar una explicación detallada de este método aquí.

Conoce las bibliotecas con las que trabajas

Algunas veces, las bibliotecas que usas en tu app requieren permisos. Por ejemplo, las bibliotecas de anuncios y análisis pueden requerir acceso a los grupos de permisos Location o Identity para poder implementar la funcionalidad necesaria. Sin embargo, desde la perspectiva del usuario, la solicitud de permiso proviene de tu app y no de la biblioteca.

Al igual que los usuarios seleccionan apps que usan menos permisos para la misma funcionalidad, los desarrolladores deben revisar sus bibliotecas y seleccionar SDK de terceros que usen permisos innecesarios. Por ejemplo, intenta evitar bibliotecas que requieran el grupo de permisos Identity, a menos que exista un motivo claro para el usuario respecto de la necesidad de esos permisos por parte de la app. En especial, para las bibliotecas que proporcionen la funcionalidad de ubicación, asegúrate de no tener que solicitar el permiso FINE_LOCATION a menos que uses funcionalidad de perfilamiento basada en la ubicación.

Sé transparente

Debes informar a los usuarios los elementos a los accederás y el motivo por el cual lo harás. Las investigaciones muestran que las solicitudes de permisos incomodan mucho menos a los usuarios cuando conocen la razón por la cual la app los necesita. Un estudio de usuarios mostró lo siguiente:

... la disposición de un usuario para otorgar permiso a una app para dispositivos móviles determinada se ve notablemente afectada por el propósito asociado con el permiso. Por ejemplo, la disposición de un usuario de otorgar acceso a su ubicación variará según la solicitud se realice para respaldar la funcionalidad central de la app o para compartir esa información con una red de publicidad o una compañía de análisis de datos.1

Conforme a la investigación de su grupo, el Profesor Jason Hong, de la CMU, concluyó que generalmente:

... cuando las personas conocen el motivo por el cual una app usa datos confidenciales como su ubicación (por ejemplo, para publicidad direccionada), se sienten más tranquilas que cuando solo se les notifica el uso de tales datos.1

En consecuencia, si solo usas una fracción de las llamadas de API que pertenecen a ese grupo de permisos, esto te ayudará a indicar explícitamente los permisos que usas y los motivos del procedimiento. Por ejemplo:

En ciertas circunstancias, resulta favorable informar a los usuarios respecto del acceso a datos confidenciales en tiempo real. Por ejemplo, si accedes a la cámara o al micrófono, se recomienda que lo informes al usuario con un ícono de notificación en algún sector de tu app, o en la bandeja de notificaciones (si la aplicación se ejecuta en segundo plano), de modo que no parezca que recopilas datos de forma clandestina.

Por último, si necesitas solicitar un permiso para realizar alguna tarea en tu app, pero el motivo no está claro para el usuario, busca una manera de informarle el motivo por el cual necesitas los permisos más sensibles.

Referencias

[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, por J. Lin B. Liu, N. Sadeh y J. Hong. En actas de SOUPS 2014.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience.
(Sep 2017 survey)