Próximos cambios en este artículo
Este artículo se actualizará con los cambios anunciados recientemente.
Para que los usuarios tengan una mejor experiencia, aplicaremos nuevas limitaciones al uso del permiso USE_FULL_SCREEN_INTENT. En el caso de las aplicaciones orientadas a Android U (nivel de API 34) y versiones posteriores, cambiaremos este permiso a uno de acceso especial para aplicaciones. De forma predeterminada, solo se otorgará este permiso a las aplicaciones cuya funcionalidad principal requiera una notificación de pantalla completa. Las demás aplicaciones deberán solicitarle el permiso al usuario. (en vigencia a partir del 31 de mayo de 2024)
Para brindar una experiencia que preserve más la privacidad de los usuarios, presentaremos la política de Permisos para Acceder a Fotos y Videos con el fin de reducir la cantidad de aplicaciones que estén autorizadas para solicitar permisos de acceso amplio a fotos o videos (READ_MEDIA_IMAGES y READ_MEDIA_VIDEO). Las aplicaciones solo podrán acceder a fotos y videos para fines directamente relacionados con las funciones de la aplicación. Las aplicaciones que tengan una necesidad infrecuente o de una sola vez de acceder a estos archivos deberán usar un selector de archivos del sistema, como el selector de fotos de Android. (en vigencia a partir del 31 de agosto de 2024)
Actualizaremos la política de Health Connect para optimizar el proceso de solicitud de acceso a Health Connect y alinearlo con la política sobre Aplicaciones de Salud. La solicitud, que ahora se realiza con un formulario, se reemplazará por una nueva declaración de Play Console más adelante este año. (en vigencia a partir del 31 de agosto de 2024)
Para obtener una vista previa del artículo "Permisos y APIs que Acceden a Información Sensible" actualizado, visite esta página.
Las solicitudes de permisos y el uso de APIs que accedan a información sensible deben tener un sentido claro para los usuarios. Solo puede solicitar permisos y usar APIs que accedan a información sensible siempre y cuando estos sean necesarios para implementar funciones o servicios existentes en su aplicación que se promuevan en la ficha de Google Play. Se prohíbe el uso de permisos o APIs que accedan a información sensible que otorgue acceso a los datos del usuario o del dispositivo para funciones o fines no divulgados, no implementados o no autorizados. No se permite vender los datos sensibles o personales que se obtengan mediante permisos o APIs que accedan a información sensible, ni compartirlos para facilitar una venta.
Solicite permisos y use APIs que accedan a información sensible para tener acceso a los datos en contexto (mediante solicitudes incrementales), de modo que los usuarios comprendan por qué su aplicación los solicita o usa. Use los datos solo con los fines para los que el usuario haya otorgado consentimiento. Si más adelante desea usar los datos para otros fines, debe solicitar el permiso de los usuarios y asegurarse de que acepten los propósitos adicionales.
Permisos Restringidos
Además de lo anterior, los permisos restringidos son aquellos que se designan como Riesgosos, Especiales, de Firma o según se documenta a continuación. Estos permisos están sujetos a los siguientes requisitos y restricciones adicionales:
- Los datos de usuarios o dispositivos a los que se accede mediante Permisos Restringidos se consideran datos sensibles y personales de los usuarios. En este caso, se aplican los requisitos de la política de Datos del Usuario.
- Se debe respetar la decisión de los usuarios si rechazan una solicitud de Permisos Restringidos y no se debe manipular ni forzar a los usuarios para que den su consentimiento a ningún permiso que no sea crítico. Se deben realizar todos los esfuerzos razonables para ajustar el contenido a los usuarios que no otorguen acceso a permisos sensibles (por ejemplo, permitir que un usuario ingrese un número de teléfono de forma manual si restringió el acceso a los Registros de Llamadas).
- Se prohíbe expresamente el uso de permisos que infrinjan las políticas de software malicioso de Google Play (incluidas las relacionadas con el Abuso de Privilegios Elevados).
Algunos Permisos Restringidos pueden estar sujetos a los requisitos adicionales que se detallan a continuación. El objetivo de estas restricciones es proteger la privacidad de los usuarios. Es posible que hagamos excepciones limitadas a los requisitos en casos muy infrecuentes en los que las apps proporcionen una función crítica o sumamente atractiva para la que no exista un método alternativo disponible. Evaluaremos las excepciones propuestas en función de su impacto potencial sobre la privacidad o seguridad de los usuarios.
Permisos de SMS y Registro de LlamadasLos Permisos de SMS y Registro de Llamadas se consideran datos sensibles y personales de los usuarios y están sujetos a la política de Información Personal y Sensible, así como a las siguientes restricciones:
Las apps que no posean la función de controlador predeterminado del Asistente, Teléfono o SMS no pueden declarar el uso de los permisos anteriores en el manifiesto. Esto también se aplica al texto de marcador de posición en el manifiesto. Además, las aplicaciones deben estar registradas de forma activa como controladores predeterminados del Asistente, Teléfono o SMS antes de solicitar a los usuarios que acepten cualquiera de los permisos anteriores. Asimismo, deben finalizar de inmediato el uso del permiso cuando dejen de ser controladores predeterminados. En esta página del Centro de ayuda, se pueden consultar los usos permitidos y las excepciones. Las aplicaciones solo pueden usar el permiso (y cualquier dato derivado de este) para brindar la funcionalidad principal aprobada de la aplicación. La funcionalidad principal se define como el objetivo más importante de la aplicación. Esto puede incluir una serie de funciones principales, las cuales deben estar claramente documentadas y promocionadas en la descripción de la aplicación. Sin las funciones principales, la aplicación se considera "dañada" o inútil. Solo se deben transferir, compartir o usar con licencia estos datos a fin de brindar funciones o servicios principales dentro de la aplicación, y no se puede extender su uso para ningún otro propósito (p. ej., mejorar otras aplicaciones o servicios, publicidad o marketing). No se pueden usar métodos alternativos (incluidos otros permisos, API o fuentes de terceros) para obtener datos atribuidos a los permisos de Registro de llamadas o SMS relacionados. |
Permisos de UbicaciónSe considera que la ubicación del dispositivo es un dato sensible y personal del usuario, y está sujeto a la política de Información Personal y Sensible, a la política de Ubicación en Segundo Plano y a los siguientes requisitos:
Se permite que las aplicaciones accedan a la ubicación con un servicio en primer plano (cuando la aplicación solo tiene acceso en primer plano, p. ej., "durante el uso") si el uso cumple con las siguientes condiciones:
Las aplicaciones diseñadas específicamente para niños deben cumplir con la política de Diseñado para Familias. Para obtener más información sobre los requisitos de la política, consulte este artículo de ayuda. |
Permiso "Acceso a todos los archivos"Los archivos y los atributos de directorio del dispositivo de un usuario se consideran datos personales y sensibles sujetos a la Política de Información Personal y Sensible y a los siguientes requisitos:
|
Permiso de Visibilidad de Paquetes (Aplicaciones)Cuando se consulta el inventario de aplicaciones instaladas desde un dispositivo, dicho contenido se considera información sensible y personal del usuario, y está sujeto a la política de Información Personal y Sensible, así como a los requisitos que se detallan a continuación. Las aplicaciones que tienen como propósito principal lanzar o explorar otras aplicaciones del dispositivo, o interoperar con ellas, pueden obtener visibilidad apropiada para el alcance de otras aplicaciones instaladas en el dispositivo, como se describe a continuación:
Los datos de inventario de las aplicaciones que se consultan desde las aplicaciones distribuidas en Play no se pueden vender ni compartir con fines de análisis o monetización de anuncios. |
Accessibility APINo se puede usar la API de Accessibility para los siguientes fines:
La API de Accessibility no se puede solicitar para realizar grabaciones de audio de llamadas remotas, ya que no está diseñada para tal fin. El uso de la API de Accessibility debe estar documentado en la ficha de Google Play. Lineamientos para el uso de la etiqueta IsAccessibilityToolLas aplicaciones cuya funcionalidad principal pretenda brindar asistencia directa a las personas con discapacidades son aptas para usar la etiqueta IsAccessibilityTool a fin de designarse públicamente como aplicaciones de accesibilidad de forma adecuada. Las aplicaciones que no sean aptas para usar IsAccessibilityTool no pueden usar la etiqueta y deben cumplir con los requisitos de consentimiento y divulgación destacada que se describen en la política de Datos del Usuario debido a que la función de accesibilidad no es obvia para el usuario. Para obtener más información, consulte el artículo del Centro de ayuda sobre la API de AccessibilityService. Cuando sea posible, las aplicaciones deben usar API y permisos con alcances más restringidos en lugar de la API de Accesibility a fin de lograr la funcionalidad deseada. |
Permiso Solicitar Paquetes de InstalaciónEl permiso REQUEST_INSTALL_PACKAGES autoriza a la aplicación a solicitar la instalación de paquetes de aplicación. Para usar este permiso, la funcionalidad principal de su aplicación debe incluir lo siguiente:
Las funcionalidades permitidas incluyen las siguientes:
La funcionalidad principal se define como el objetivo más importante de la aplicación. La funcionalidad principal, así como cualquier otra función importante que la constituya, deben documentarse de forma destacada y promocionarse en la descripción de la aplicación. El permiso REQUEST_INSTALL_PACKAGES no debe usarse para realizar actualizaciones automáticas, modificaciones o implementaciones de paquetes de otros APK en el archivo de activos, a menos que sea con fines de administración de dispositivos. Todas las actualizaciones o instalaciones de paquetes deben estar sujetas a la política de Abuso de Redes y Dispositivos de Google Play, y el usuario es quien debe iniciarlas. |
Permisos para Health Connect de AndroidLos datos a los que se accede con los Permisos para Health Connect se consideran datos personales y sensibles de los usuarios, y están sujetos a la política de Datos del Usuario y a los siguientes requisitos adicionales: Acceso y Uso Adecuados de Health ConnectLas solicitudes para acceder a datos desde Health Connect deben ser claras y comprensibles. Health Connect solo se puede usar de acuerdo con las políticas y los términos y condiciones aplicables, y para los casos de uso aprobados según se describe en esta política. Esto significa que solo puede solicitar acceso a los permisos cuando su aplicación o servicio cumpla con uno de los casos de uso aprobados. A continuación se indican los casos de uso aprobados con el fin de acceder a los Permisos para Health Connect:
Health Connect es una plataforma de uso general para el almacenamiento y uso compartido de datos que les permite a los usuarios recopilar información de salud y estado físico de distintas fuentes en su dispositivo Android y compartirla con terceros según lo prefieran. Los datos pueden originarse de distintas fuentes a partir de lo que determinen los usuarios. Los desarrolladores deben evaluar si Health Connect es una opción adecuada para su uso previsto y para investigar y aprobar la fuente y la calidad de los datos de Health Connect con relación a cualquier propósito y, en particular, para usos médicos o relacionados con la salud o la investigación.
Uso LimitadoSi hace un uso adecuado de Health Connect, su uso de los datos a los que se accede con Health Connect también debe satisfacer los requisitos que se indican a continuación. Estos requisitos se aplican a los datos sin procesar obtenidos de Health Connect y a los datos recopilados, desidentificados o derivados de los datos sin procesar.
Está prohibido cualquier otro uso, transferencia o venta de datos de Health Connect, lo que incluye lo siguiente:
El acceso a Health Connect no se puede usar si incumple esta política o cualquier otra política o términos y condiciones aplicables de Health Connect, incluso con los siguientes propósitos:
En su aplicación o en un sitio web que pertenezca a su aplicación o servicio web, se debe divulgar una declaración afirmativa de que su uso de los datos de Health Connect satisfacen las restricciones de Uso Limitado; por ejemplo, un vínculo en una página principal a una página dedicada o una política de privacidad que indique: "El uso de la información recibida de Health Connect cumplirá con la política de Permisos para Health Connect, incluidos los requisitos de Uso Limitado". Alcance MínimoSolo puede solicitar acceso a permisos que sean críticos para implementar las funciones de su aplicación o servicio. Esto significa lo siguiente:
Control y Aviso Precisos y TransparentesHealth Connect maneja datos de salud y estado físico, lo que incluye información personal y sensible. Todas las aplicaciones y servicios deben contener una política de privacidad, la cual debe divulgar de forma comprensible cómo su aplicación o servicio recopila, usa y comparte datos del usuario. Esto incluye los tipos de partes con las que se comparten los datos del usuario, cómo usa usted los datos, cómo los almacena y asegura, y qué ocurre con los datos cuando se desactiva o borra una cuenta. Además de las disposiciones correspondientes a la ley aplicable, también debe cumplir con los siguientes requisitos:
Manejo Seguro de los DatosDebe manejar todos los datos del usuario de forma segura. Tome medidas razonables y adecuadas para proteger todas las aplicaciones o sistemas que usen Health Connect contra el acceso, el uso, la destrucción, la pérdida, la alteración o la divulgación que no estén autorizados o no sean legales. Las prácticas de seguridad recomendadas incluyen implementar y mantener un Sistema de Administración de la Seguridad de la Información según se describe en el estándar ISO/IEC 27001 y garantizar que la aplicación o el servicio web sea robusto y no tenga problemas de seguridad comunes según se describe en el documento de OWASP Top 10. Según la API a la que se acceda y la cantidad de usuarios, exigiremos que su aplicación o servicio se someta a una evaluación periódica de seguridad y obtenga una Carta de Evaluación de un tercero designado si su producto transfiere datos del dispositivo del usuario. Si desea obtener más información sobre los requisitos para las aplicaciones que se conectan a Health Connect, consulte este artículo de ayuda. |
Servicio de VPNVpnService es una clase básica para que las aplicaciones extiendan y compilen sus propias soluciones de VPN. Únicamente las aplicaciones que usan VpnService y tienen una VPN como su funcionalidad principal pueden crear un túnel seguro a nivel del dispositivo hacia un servidor remoto. Entre las excepciones se incluyen las aplicaciones que requieren un servidor remoto para la funcionalidad principal, como las siguientes:
VpnService no se puede usar para lo siguiente:
Las aplicaciones que usan VpnService deben hacer lo siguiente:
|
Permiso de Alarmas ExactasSe implementará un nuevo permiso, USE_EXACT_ALARM, que otorgará acceso a la funcionalidad de alarmas exactas en las aplicaciones a partir de Android 13 (nivel de API objetivo 33). USE_EXACT_ALARM es un permiso restringido, y las aplicaciones solo deben declarar este permiso si su funcionalidad principal admite la necesidad de una alarma exacta. Las aplicaciones que solicitan este permiso restringido están sujetas a revisión, y no se permitirá la publicación en Google Play de las que no cumplan con los criterios de casos de uso aceptables. Casos de uso aceptables para utilizar el Permiso de Alarmas Exactas Su aplicación debe usar la funcionalidad de USE_EXACT_ALARM únicamente cuando la funcionalidad principal del lado del usuario requiera acciones con tiempos precisos, como en los siguientes ejemplos:
Si tiene un caso de uso para la funcionalidad de alarma exacta que no está abarcado más arriba, debe evaluar si el uso de SCHEDULE_EXACT_ALARM como alternativa es una opción. Para obtener más información sobre la funcionalidad de alarma exacta, consulte esta orientación para desarrolladores. |