Limitación de responsabilidad: los resúmenes de las políticas y las consideraciones clave solo ofrecen una vista general. Consulta siempre la política completa para garantizar su cumplimiento. En caso de conflicto, la política completa tiene prioridad.
Vista previa de la política
-
Para proteger mejor la privacidad del usuario, vamos a actualizar nuestra política de permisos de ubicación. Vamos a introducir el botón de ubicación como permiso mínimo recomendado para la ubicación precisa, de acuerdo con nuestros requisitos de datos de usuario y permisos sensibles.
(en vigor desde el 28 de octubre del 2026)
-
Vamos a publicar la política de permisos de contactos para regular el acceso general a los contactos de los usuarios. Las aplicaciones que no necesiten un acceso general deben usar el selector de contactos de Android, una alternativa más segura y fácil de integrar que minimiza la recogida de datos y mejora la seguridad de los usuarios.
(Es una política nueva y entrará en vigor el 28 de octubre del 2026.)
Para consultar la versión actual del artículo "Permisos y APIs que acceden a información sensible", visita esta página.
Para promover la confianza de los usuarios, Google Play exige la necesidad de solicitar permisos y APIs que acceden a datos de usuario sensibles para las funciones principales de la aplicación tal como se promociona en tu ficha de Play Store y limitado a los fines que consintió el usuario. No se debe hacer un uso inadecuado, revelar ni acceder innecesariamente a datos sensibles. Solicita permisos y APIs sensibles de manera incremental, explicando cada nivel. Usa solo los datos cuyo consentimiento tengas y obtén el consentimiento para otros fines. Revisa la política completa para garantizar su cumplimiento.
Las solicitudes de permisos y las APIs que acceden a información sensible deben resultar comprensibles para los usuarios. De los permisos y las APIs que acceden a información sensible, solo puedes solicitar aquellos que sean necesarios para implementar en tu aplicación las funciones o los servicios que promociones en tu ficha de Google Play Store. No puedes usar permisos ni APIs que accedan a información sensible y proporcionen acceso a datos de usuario o de dispositivos en relación con fines o funciones que no hayas especificado, no hayas implementado o no estén permitidos. No puedes vender en ningún caso los datos personales o sensibles a los que tengas acceso mediante permisos o APIs que accedan a información sensible, ni tampoco compartirlos con la finalidad de facilitar su venta.
Solicita permisos y APIs que accedan a información sensible para acceder a datos en contexto (mediante solicitudes incrementales) de manera que los usuarios comprendan el motivo por el que tu aplicación requiere esos permisos. Usa los datos únicamente con los fines para los cuales los usuarios hayan dado su consentimiento. Si más adelante quieres usar los datos con otros fines, debes pedirles a los usuarios que den su consentimiento para esos nuevos usos y asegurarte de que los acepten.
Permisos restringidos
Para proteger la privacidad del usuario, Google Play establece permisos restringidos, sujetos a requisitos adicionales, y exige que las aplicaciones hagan un uso responsable de dichos permisos y que no manipulen a los usuarios para que concedan acceso. Respeta las opciones de los usuarios cuando rechacen solicitudes de permiso y ofrece alternativas. Ten en cuenta que ciertos permisos restringidos podrían requerir requisitos adicionales. Revisa la política completa para garantizar su cumplimiento.
Además de lo expuesto más arriba, los permisos restringidos son permisos clasificados con los tipos Peligroso, Especial, De firma, o los que se indican a continuación. Estos permisos están sujetos a los siguientes requisitos y restricciones adicionales:
- Los datos de usuario o de dispositivo a los que se accede mediante permisos restringidos se consideran datos de usuario personales y sensibles. Se aplican los requisitos de la Política de Datos de Usuario.
- Si un usuario rechaza una solicitud de permisos restringidos, respeta su decisión. Además, no se debe manipular ni forzar a los usuarios para que den su consentimiento a cualquier permiso que no sea esencial. Debes adaptarte en la medida razonablemente posible a los usuarios que no otorguen acceso a los permisos sensibles (por ejemplo, permitiendo a un usuario que introduzca un número de teléfono de forma manual si se ha restringido el acceso a los registros de llamadas).
- Se prohíbe expresamente el uso de permisos que infrinjan las políticas de malware de Google Play (incluido el abuso de privilegios avanzados).
Es posible que algunos permisos restringidos estén sujetos a requisitos adicionales, detallados más adelante. El objetivo de estas restricciones es proteger la privacidad de los usuarios. Es posible que hagamos excepciones en casos muy limitados en los que las aplicaciones proporcionen una función esencial o de gran interés y no haya ningún método alternativo para ofrecer esa función. Evaluamos las excepciones propuestas teniendo en cuenta el impacto potencial en la privacidad o seguridad de los usuarios.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
| Si un usuario deniega un permiso restringido, tu aplicación debe respetar esa decisión sin manipular. | No utilices permisos para infringir la política de malware de Google Play, incluido el abuso de privilegios avanzados. |
| Si el usuario deniega un permiso, ofrece una forma alternativa de realizar una función, como permitir que se introduzcan datos manualmente. | No manipules ni confundas a los usuarios. No los fuerces ni los engañes para que concedan permisos. |
| Cumple la política Datos de Usuario, ya que todos los datos a los que se accede mediante estos permisos son sensibles. | Si un usuario rechaza un permiso restringido, no le niegues la opción de usar una alternativa razonable. Asegúrate de que la aplicación siga siendo funcional. |
Solicita los permisos peligrosos (por ejemplo, READ_CALENDAR) con una solicitud de tiempo de ejecución y una explicación clara. |
No solicites nada sin una justificación. Solicita permisos restringidos solo en el caso de funciones esenciales y de gran interés que no tengan una alternativa. |
Dirige a los usuarios a la página de ajustes del sistema para que aprueben los permisos especiales (por ejemplo, SYSTEM_ALERT_WINDOW). |
Los selectores del sistema y las alternativas, como Sharesheet, se han diseñado para ofrecer a los desarrolladores una opción orientada a la privacidad. Las fotos, los vídeos, los contactos y otros datos personales y sensibles protegidos por permisos restringidos se deben tratar siguiendo las prácticas recomendadas sobre privacidad. Tu aplicación solo debe solicitar y utilizar los permisos sensibles que se indican más abajo si las alternativas de permiso mínimo no permiten proporcionar la función principal. Para obtener más información, consulta nuestro Centro de Ayuda.
-
Todos los contactos de los usuarios son datos personales y sensibles sujetos a la política Datos de Usuario.
-
Las aplicaciones orientadas a Android 17 o versiones posteriores (nivel 37 de la API o superior) solo pueden solicitar el permiso
READ_CONTACTSsi el selector de contactos de Android no es suficiente para que tu aplicación proporcione la función principal. Las aplicaciones que sigan solicitando el permisoREAD_CONTACTSdeberán enviar una declaración en Play Console para demostrar que necesitan acceder a los contactos y por qué no es suficiente con el selector de contactos.
-
Las aplicaciones no pueden divulgar ni publicar datos de contactos no públicos a menos que los interesados (los propios contactos) lo autoricen.
-
Todas las fotos de los usuarios son datos personales y sensibles sujetos a la política Datos de Usuario.
-
Las aplicaciones orientadas a Android 13 o versiones posteriores (nivel 33 de la API o superior) solo pueden solicitar los permisos
READ_MEDIA_IMAGESyREAD_MEDIA_VIDEOsi los selectores del sistema (como el selector de fotos de Android) no son suficientes para que tu aplicación proporcione la función principal. Las aplicaciones que sigan solicitando los permisosREAD_MEDIA_IMAGESyREAD_MEDIA_VIDEOdeben enviar una declaración en Play Console para demostrar que necesitan acceder a las fotos y por qué no es suficiente con el selector de fotos de Android (u otras alternativas).
Permisos de SMS y registro de llamadas
Google Play impone restricciones estrictas sobre el acceso a datos muy sensibles de SMS y de registros de llamadas. Para solicitar estos permisos, tu aplicación debe ser el controlador designado predeterminado para SMS, el teléfono o el Asistente. El uso está limitado únicamente a la funcionalidad principal documentada de la aplicación que sea absolutamente esencial para el propósito principal de la aplicación. Estos datos no deben usarse nunca para fines publicitarios ni para otros fines no autorizados. Revisa la política completa para garantizar su cumplimiento.
Los permisos de SMS y registro de llamadas se consideran datos de usuario sensibles y personales sujetos a la política Información personal y sensible y a los siguientes requisitos:
| Permiso restringido | Requisito |
|---|---|
| Grupo de permisos de registro de llamadas (p. ej., READ_CALL_LOG, WRITE_CALL_LOG o PROCESS_OUTGOING_CALLS) | Tu aplicación debe estar registrada de forma activa como controlador predeterminado del teléfono o asistencia en el dispositivo. |
| Grupo de permisos de SMS (p. ej., READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS, RECEIVE_WAP_PUSH o RECEIVE_MMS) | Tu aplicación debe estar registrada de forma activa como controlador predeterminado de SMS o asistencia en el dispositivo. |
Las aplicaciones que no tengan la función de controlador predeterminado de SMS, teléfono o asistencia no podrán declarar el uso de estos permisos en su archivo de manifiesto. Esto incluye texto de marcador de posición en el manifiesto. Además, estas aplicaciones deben estar registradas como controladores predeterminados de SMS, teléfono o asistencia para solicitar a los usuarios que acepten cualquiera de estos permisos. Asimismo, deben dejar de usar los permisos inmediatamente si dejan de actuar como controladores predeterminados. Puedes consultar los usos permitidos y las excepciones en esta página del Centro de Ayuda.
Las aplicaciones solo pueden utilizar un permiso (y los datos derivados de él) para ofrecer funciones principales aprobadas. La función principal de una aplicación es su objetivo principal. Puede incluir un conjunto de funciones principales, que deben estar claramente documentadas y promocionadas en la descripción de la aplicación. Sin estas funciones, la aplicación no funcionará. Solo se deben transferir, compartir o usar con licencia estos datos para ofrecer funciones o servicios principales de la aplicación, y no se deben usar con otros fines (p. ej., mejorar otros servicios o aplicaciones, mostrar publicidad o marketing). No se pueden usar métodos alternativos (como otros permisos, APIs o fuentes de terceros) para obtener datos atribuidos a los permisos relacionados con los SMS o el registro de llamadas.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Envía un formulario de declaración en Play Console. | No puedes solicitar permisos de SMS ni registros de llamadas que no estén justificados por una necesidad esencial. |
| Indica claramente la función principal que solicita acceso a tus usuarios. | No puedes usar esos datos para publicidad ni para otros fines. |
| Usa alternativas que cumplan las políticas, como la API SMS Retriever, siempre que sea posible. | No puedes almacenar ni compartir datos de SMS o de registros de llamadas que no sean necesarios. |
| Deja de acceder a los datos en cuanto dejes de tener el estado de controlador predeterminado. | No puedes intentar obtener esos datos usando métodos alternativos. |
| Revisa los usos permitidos y las excepciones de los permisos de SMS y registros de llamadas. |
Permisos de ubicación
La ubicación del dispositivo se considera un dato de usuario personal y sensible sujeto a la política de información personal y sensible y a la política de ubicación en segundo plano, así como a los siguientes requisitos:
- Las aplicaciones no pueden acceder a datos protegidos por permisos de ubicación del dispositivo (por ejemplo,
ACCESS_FINE_LOCATION,ACCESS_COARSE_LOCATIONoACCESS_BACKGROUND_LOCATION) una vez que dejan de ser necesarios para proporcionar las funciones o servicios de tu aplicación. - Las aplicaciones no pueden solicitar permisos de ubicación de los usuarios con fines de publicidad o análisis únicamente. Las aplicaciones que extiendan el uso permitido de estos datos para publicar anuncios deben cumplir nuestra política de anuncios.
- Las aplicaciones que soliciten permisos de ubicación del dispositivo (incluido el botón de ubicación de Android) estarán sujetas a un proceso de declaración en Play Console y a una revisión para comprobar que tienen el acceso adecuado. No se permiten aplicaciones que soliciten datos de ubicación del dispositivo sin una justificación adecuada o que incumplan los siguientes requisitos mínimos de permiso.
Requisitos mínimos de permisos para las APIs de ubicación de dispositivos
- Debe solicitar el permiso mínimo necesario para la función o el servicio que requiera acceso a la ubicación del dispositivo (por ejemplo, aproximado si su caso de uso no requiere ubicación precisa y en primer plano si no requiere ubicación en segundo plano). Los usuarios deberían esperar razonablemente que una función o un servicio en concreto necesite el nivel de ubicación solicitado.
- En el caso de las aplicaciones orientadas a la versión 37 (Android 17) o una posterior del SDK para Android:
- Si su caso de uso requiere ubicación precisa (ACCESS_FINE_LOCATION) solo para acciones puntuales iniciadas por el usuario, debe implementar el uso del botón de ubicación de Android con la marca de permiso
onlyForLocationButtonen el archivo de manifiesto de su aplicación.
- Si su caso de uso requiere ubicación precisa (ACCESS_FINE_LOCATION) solo para acciones puntuales iniciadas por el usuario, debe implementar el uso del botón de ubicación de Android con la marca de permiso
- El permiso
ACCESS_FINE_LOCATIONsolo se concede a las aplicaciones en las que las funciones de ubicación declaradas no se pueden admitir adecuadamente con el botón de ubicación de Android (en el caso de las aplicaciones orientadas a Android 17 o versiones posteriores) ni con el permisoACCESS_COARSE_LOCATION(aplicable a todas las versiones de Android). - La ubicación en segundo plano solo se puede utilizar para proporcionar funciones favorables para el usuario y pertinentes para la función principal de la aplicación.
Se permite que las aplicaciones accedan a la ubicación mediante el permiso de servicio en primer plano (cuando la aplicación solo tiene acceso en primer plano; por ejemplo, "mientras esté en uso") si el uso:
- se ha iniciado como una continuación de una acción que ha iniciado el usuario en la aplicación y
- finaliza inmediatamente después de que la aplicación complete el caso de uso previsto de la acción que ha iniciado el usuario.
Las aplicaciones diseñadas específicamente para niños deben cumplir las Políticas de Familias de Google Play.
Para obtener más información sobre los requisitos de la política, consulte Información sobre los permisos de ubicación en segundo plano.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
| Cumple la política Diseñado para Familias en las aplicaciones dirigidas a menores. | No uses la ubicación del dispositivo únicamente con fines publicitarios o analíticos. |
| Revisa los requisitos de permisos importantes antes de solicitar que se publique tu aplicación. | No accedas a los datos cuando ya no sea necesario. |
| Completa la declaración de Play Console en relación con la ubicación en segundo plano. | No solicites la ubicación del dispositivo en aplicaciones dirigidas a menores. |
| No vendas los datos de ubicación del dispositivo. |
Permiso de acceso a todos los archivos
La política de Google Play trata el acceso a los archivos y directorios del usuario como sensible y de alto riesgo, por lo que restringimos el uso del permiso MANAGE_EXTERNAL_STORAGE en Android 11 y versiones posteriores. Debes tener una funcionalidad principal de la aplicación que requiera un acceso general a este permiso para un fin que vean los usuarios y nunca para terceros. Esto ayuda a evitar la recogida de datos innecesarios y protege la privacidad de los usuarios. Las aplicaciones que soliciten este permiso deben hacerlo con claridad para que los usuarios puedan tomar una decisión informada sobre su privacidad. También deben recibir la aprobación mediante la revisión de la aplicación en Google Play. Revisa la política completa para garantizar su cumplimiento.
Los archivos y los atributos de directorio del dispositivo de un usuario se consideran datos personales y sensibles sujetos a la política Información Personal y Sensible y a los siguientes requisitos:
- Las aplicaciones solo pueden solicitar acceso al almacenamiento del dispositivo si es fundamental para que funcionen. No pueden solicitar acceso al almacenamiento del dispositivo en nombre de ningún tercero por ningún motivo que no esté relacionado con las funciones esenciales de la aplicación de cara al usuario.
- Los dispositivos Android que ejecuten R o una versión posterior necesitarán el permiso
MANAGE_EXTERNAL_STORAGEpara gestionar el acceso en el almacenamiento compartido. Todas las aplicaciones orientadas a R y que soliciten un acceso amplio al almacenamiento compartido ("Acceso a todos los archivos") deben superar una revisión de acceso adecuada antes de su publicación. Las aplicaciones que puedan usar este permiso deben indicar claramente a los usuarios que habiliten la opción "Acceso a todos los archivos" de la sección "Acceso especial de aplicaciones". Para obtener más información sobre los requisitos de R, consulta este artículo de ayuda.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
| Da prioridad a alternativas que protejan la privacidad, como el framework de acceso al almacenamiento o la API MediaStore. |
No solicites el permiso |
| Declara este permiso cuando envíes un formulario de declaración en Play Console. | No proporciones información falsa sobre la función principal de tu aplicación. |
| Define e indica claramente la función principal de tu aplicación en su revisión. |
No almacenes ni compartas datos más que para las necesidades esenciales que se hayan indicado. |
| Indica claramente a los usuarios que habiliten la opción "Acceso a todos los archivos" para tu aplicación en los ajustes de "Aplicaciones con accesos especiales". | |
| Asegúrate de revisar los requisitos de Android R para obtener más información. |
Permiso de visibilidad de paquetes (aplicaciones)
QUERY_ALL_PACKAGES) y solo la permite en los casos en los que la funcionalidad principal de la aplicación requiera un amplio conocimiento de las aplicaciones instaladas para su interoperabilidad. Debes dar prioridad a las peticiones finitas y dirigidas para acceder a aplicaciones específicas cuando sea posible, ya que esta opción respeta más la privacidad. En ninguna circunstancia pueden venderse o compartirse los datos del inventario de aplicaciones instaladas con fines de monetización publicitaria o de análisis. Revisa la política completa para garantizar su cumplimiento.El inventario de aplicaciones instaladas que se consulta desde un dispositivo se considera como datos de usuario personales y sensibles sujetos a la política de Información Personal y Sensible y a los siguientes requisitos:
Las aplicaciones cuya finalidad principal sea iniciar y buscar otras aplicaciones del dispositivo, o interactuar con ellas, pueden obtener una visibilidad de otras aplicaciones instaladas en el dispositivo acorde con su alcance, como se indica a continuación:
- Visibilidad general de las aplicaciones: la visibilidad general es la capacidad de obtener una visibilidad amplia (o "general") de las aplicaciones instaladas ("paquetes") en el dispositivo.
- En el caso de las aplicaciones orientadas al nivel de API 30 o posterior, la visibilidad general de las aplicaciones instaladas mediante el permiso
QUERY_ALL_PACKAGESqueda restringida a casos prácticos específicos en los que el conocimiento de alguna o de todas las aplicaciones del dispositivo o la interoperabilidad con ellas sea necesaria para que la aplicación funcione.- No puedes usar
QUERY_ALL_PACKAGESsi tu aplicación puede funcionar con una declaración de visibilidad de paquetes más específica y acorde con su alcance (por ejemplo, mediante consultas e interacciones con paquetes específicos en lugar de solicitar visibilidad general).
- No puedes usar
- El uso de métodos alternativos para aproximarse al nivel de visibilidad general asociado al permiso
QUERY_ALL_PACKAGEStambién se restringe a la funcionalidad principal de la aplicación dirigida al usuario y a su interoperabilidad con las aplicaciones detectadas mediante este método. - Puedes consultar este artículo del Centro de Ayuda para ver casos prácticos de uso permitido del permiso
QUERY_ALL_PACKAGES.
- En el caso de las aplicaciones orientadas al nivel de API 30 o posterior, la visibilidad general de las aplicaciones instaladas mediante el permiso
- Visibilidad limitada de las aplicaciones: la visibilidad limitada consiste en que la aplicación minimiza el acceso a los datos efectuando consultas a aplicaciones específicas usando métodos más limitados (en lugar de "generales"), como hacer consultas a aplicaciones específicas que cumplan la declaración del archivo de manifiesto de la aplicación. Puedes utilizar este método para hacer consultas a aplicaciones en los casos en los que la interoperabilidad o la gestión de esas aplicaciones por parte de tu aplicación cumpla nuestras políticas.
- La visibilidad del inventario de aplicaciones instaladas en un dispositivo debe estar directamente relacionada con el propósito principal o con la función principal a los que los usuarios acceden en tu aplicación.
Los datos de inventario de aplicaciones consultados desde aplicaciones distribuidas por Google Play no se pueden vender ni compartir para analíticas ni para obtener ingresos por publicidad.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
Envía un formulario de declaración en Play Console para QUERY_ALL_PACKAGES y cualquier otro permiso de alto riesgo. |
No solicites |
| En la revisión de tu aplicación, indica claramente por qué necesita visibilidad de la aplicación, ya sea general o más específica. | No obtengas visibilidad general de la aplicación con métodos que no permita la política de manera explícita. |
| Accede solo a los datos mínimos necesarios. | No ofrezcas información falsa sobre la función principal ni las necesidades de datos de tu aplicación. |
| Revisa los usos permitidos del permiso QUERY_ALL_PACKAGES para conocer los casos prácticos permitidos. | No recojas ni utilices datos de tu aplicación instalada que no sean necesarios. |
API Accessibility
Google Play permite usar la API AccessibilityService en una amplia variedad de aplicaciones. Sin embargo, solo se puede declarar como herramientas de accesibilidad aquellos servicios diseñados para ayudar a las personas con discapacidades a acceder a sus dispositivos o a superar los desafíos derivados de dichas discapacidades estableciendo isAccessibilityTool=true en los metadatos. Estas aplicaciones están exentas de los requisitos de aviso destacado y consentimiento. Para todos los demás usos o si no declaras tu aplicación como herramienta de accesibilidad, tendrás que completar la declaración de accesibilidad en Play Console e implementar un aviso claro en la aplicación en el que se explique el uso de los datos y el acceso a ellos, así como obtener el consentimiento del usuario. Revisa la política completa para garantizar su cumplimiento.
La API de accesibilidad no se puede usar para:
- Cambiar la configuración del usuario sin su permiso o evitar que los usuarios inhabiliten o desinstalen cualquier aplicación o servicio, a menos que lo autorice el padre, la madre o un tutor desde una aplicación de controles parentales, o bien los administradores autorizados desde un software de gestión para empresas.
- Eludir las notificaciones, los controles de privacidad y los controles de seguridad de la plataforma integrados en Android.
- Modificar o aprovechar la interfaz de usuario de forma que resulte engañosa o infrinja las Políticas para Desarrolladores de Google Play de cualquier otra forma.
La API de accesibilidad no se ha diseñado y no se puede solicitar para:
- Grabar el audio de llamadas remotas
- Una aplicación que inicia, planea y ejecuta de forma autónoma acciones o decisiones
El uso de la API de accesibilidad debe documentarse en la ficha de Google Play.
Directrices para IsAccessibilityTool
Las aplicaciones cuya función principal sea ayudar directamente a personas con discapacidades pueden optar a usar IsAccessibilityTool para que se puedan clasificar públicamente como aplicaciones de accesibilidad.
Las aplicaciones que no pueden optar a usar IsAccessibilityTool tampoco pueden usar esta marca y deben cumplir los requisitos de aviso destacado y consentimiento que se describen en la política Datos de Usuario, ya que no resulta evidente para los usuarios que la aplicación tenga funciones relacionadas con la accesibilidad.
Las aplicaciones deben usar APIs y permisos más restrictivos en lugar de la API de accesibilidad cuando sea posible para lograr la funcionalidad deseada.
Consulta el artículo sobre la API AccessibilityService en el Centro de Ayuda para obtener más información sobre casos prácticos prohibidos y directrices de uso de IsAccessibilityTool.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
Declara isAccessibilityTool=true de manera precisa si el objetivo principal de tu aplicación es asistir a personas con discapacidad en el archivo de metadatos de tu servicio. |
No hagas un uso inadecuado de la marca isAccessibilityTool. No la uses si tu aplicación no es una herramienta de asistencia para personas con discapacidad. |
| Proporciona una declaración de Play Console clara y un vídeo demostrativo si usas la API AccessibilityService. | No cambies los ajustes del usuario sin su permiso, sortees los controles de privacidad ni grabes el audio de llamadas remotas. |
| Implementa un aviso claro en la aplicación y obtén el consentimiento del usuario si no es una herramienta de accesibilidad designada. | No uses la API para que la aplicación inicie, planifique y ejecute acciones o decisiones de manera autónoma. |
| Si no has declarado que tu aplicación es una herramienta de accesibilidad, pero usa la API AccessibilityService, completa una declaración de accesibilidad cuando envíes un formulario de declaración en Play Console. | No engañes ni confundas a los usuarios. La API no se puede usar para cambiar ni para usar la interfaz de manera engañosa. |
| Limita la recogida y el uso de datos exclusivamente a los casos comunicados y declarados. | No recojas datos innecesarios. Los datos recogidos deben usarse exclusivamente para los fines indicados. |
| Usa APIs y permisos más restrictivos en lugar de la API Accessibility cuando sea posible para lograr la funcionalidad deseada. | No eludas los requisitos de divulgación. Los avisos no pueden sustituir a la política de privacidad ni a otras descripciones de la aplicación. |
Permiso Solicitar instalación de paquetes
REQUEST_INSTALL_PACKAGES permite a las aplicaciones solicitar la instalación de otros paquetes de la aplicación. Este permiso se limita a la función principal de la aplicación, en concreto cuando el propósito principal implica directamente enviar, recibir o habilitar la instalación iniciada por el usuario de paquetes de la aplicación. Está prohibido usar este permiso para actualizar tu aplicación, cambiar su funcionalidad o empaquetar otros APKs para instalaciones silenciosas o no autorizadas (excepto gestión empresarial). Todas las instalaciones deben ser una elección directa y activa del usuario. Las aplicaciones orientadas a Android 8 o versiones posteriores deben tener este permiso para usar Intent.ACTION_INSTALL_PACKAGE. Revisa la política completa para garantizar su cumplimiento.El permiso REQUEST_INSTALL_PACKAGES permite que la aplicación solicite la instalación de paquetes de aplicaciones. Para usar este permiso, la función principal de tu aplicación debe permitir:
- Enviar o recibir paquetes de aplicaciones.
- Habilitar la instalación iniciada por el usuario de paquetes de aplicaciones.
Entre las funcionalidades permitidas se incluyen las siguientes:
- Navegación o búsqueda web
- Servicios de comunicación que admiten archivos adjuntos
- Uso compartido, transferencia o gestión de archivos
- Gestión de dispositivos empresariales
- Copia de seguridad y restauración
- Migración entre dispositivos o cambio de teléfono
- Aplicación complementaria para sincronizar el teléfono con un dispositivo wearable o del Internet de las cosas (por ejemplo, un smartwatch o una smart TV)
La función principal es el propósito fundamental de la aplicación, y tanto la función principal como cualquier característica principal que incluya deben documentarse y promocionarse de forma destacada en la descripción de la aplicación.
El permisoREQUEST_INSTALL_PACKAGES no debería usarse para hacer actualizaciones automáticas ni modificaciones, ni tampoco para crear paquetes de otros APKs en el archivo de recursos, salvo que sea con fines de gestión de dispositivos. Todas las actualizaciones o instalaciones de paquetes deben cumplir la política de abuso de dispositivos y redes de Google Play, y las debe iniciar y controlar el usuario. Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Indica de manera clara y destacada la función principal que necesita este permiso en la descripción de tu aplicación en Google Play y cuando envíes un formulario de declaración en Play Console. | No solicites este permiso para una función que no esté directamente relacionada con la finalidad principal de tu aplicación. Esto incluye el intercambio de punto a punto (P2P). Para que se considere una finalidad principal, el objetivo fundamental de la aplicación debe ofrecer el servicio de P2P. |
|
Cumple de manera estricta las funciones permitidas, como por ejemplo navegación/búsqueda web, uso compartido/transferencia/gestión de archivos, gestión de dispositivos de empresa, copias de seguridad/restauración, migración de dispositivos/transferencia de teléfonos o aplicación complementaria para sincronizar el teléfono con un dispositivo wearable o del Internet de las cosas. |
No solicites este permiso si la tarea necesaria se puede hacer con un método menos intrusivo. |
| Asegúrate de que tu aplicación impida las descargas en segundo plano o no deseadas. Todas las descargas de paquetes de aplicaciones las debe iniciar explícitamente el usuario. |
No cambies la manera en que tu aplicación utiliza este permiso sin modificar primero tu declaración de Play Console con información actualizada y precisa. Se prohíben los usos engañosos y no declarados de este permiso. |
Permisos de Sensores Corporales
Para proteger la privacidad de los usuarios, Google Play exige que el acceso a datos muy sensibles de los sensores corporales (como frecuencia cardiaca, SpO2 y temperatura cutánea) esté sujeto a nuestras políticas de datos de usuario y de aplicaciones de salud.
A partir de Android 16, las aplicaciones deben migrar del permiso general android.permission.BODY_SENSORS a nuevos permisos de salud más detallados. Por ejemplo, usarás android.permission.health.READ_HEART_RATE para acceder a los datos de frecuencia cardiaca. Este cambio afecta a todas las aplicaciones orientadas a Android 16 o versiones superiores en todos los formatos, incluido Wear OS. Para ver una lista completa de las modificaciones, consulta los cambios en el comportamiento de aplicaciones orientadas a Android 16 o versiones posteriores. Revisamos todas las solicitudes de permisos de sensores corporales, tanto antiguos como nuevos, para asegurar que el caso práctico de tu aplicación beneficie al usuario y cumpla estrictamente nuestras políticas.
Los datos de sensores que miden parámetros corporales (como la frecuencia cardiaca, la SpO₂ y la temperatura cutánea) se consideran datos de usuario personales y sensibles. Las aplicaciones que solicitan acceso están sujetas a los requisitos descritos en la política Datos de Usuario y en la política de aplicaciones de salud. Esto se aplica a las solicitudes de los permisos android.permission. y BODY_SENSORS android.permission. _BACKGROUNDBODY_SENSORS
A partir de Android 16, el permiso general BODY_SENSORS se cambiará por permisos android.permissions.health.* , más detallados y que protegen más la privacidad para tipos de datos específicos (por ejemplo, android.permission.health.READ_HEART_RATE , android.permission.health.READ_OXYGEN_SATURATION , android.permission.health.READ_SKIN_TEMPERATURE ).
Las aplicaciones orientadas a Android 16 o versiones posteriores deben usar esos permisos concretos para las APIs que antes requerían BODY_SENSORS . Consulta la página sobre cambios en el comportamiento de aplicaciones orientadas a Android 16 o versiones posteriores para obtener más información.
Todas las solicitudes de permisos de sensores corporales (tanto permisos antiguos como nuevos y más detallados) se revisarán para que el uso previsto de esos datos personales y sensibles coincida con los casos prácticos aprobados que beneficien directamente al usuario. Los casos prácticos aprobados abarcan principalmente funciones de monitorización de actividad física y bienestar (por ejemplo, monitorización de entrenamientos en tiempo real), monitorización médica o de afecciones, investigación sanitaria (con sus correspondientes aprobaciones) o mejora de funciones de aplicaciones complementarias de wearables.
Para obtener indicaciones exhaustivas sobre las políticas, incluidos los usos prohibidos, los casos prácticos aceptables y los requisitos detallados, consulta las preguntas frecuentes y las indicaciones sobre los permisos de salud de Android.
| Prácticas recomendadas | Prácticas prohibidas |
Usa permisos de salud específicos y detallados como android.permission.health.READ_HEART_RATE en vez del permiso amplio BODY_SENSORS. |
No puedes declarar |
| Asegúrate de que tu aplicación tenga una función principal que beneficie a los usuarios (por ejemplo, seguimiento de la actividad o monitorización de la salud) y que requiera estrictamente los datos. | No puedes acceder a los datos si no ofreces un beneficio directo y claro a los usuarios. |
| Cumple la política Datos de Usuario y la de aplicaciones de salud. | No puedes solicitar ni utilizar datos de sensores corporales con fines no aprobados, como publicidad general, análisis o elaboración de perfiles de usuarios a partir de las afecciones que se hayan deducido. |
| Solicita solo los permisos mínimos necesarios y los datos específicos requeridos para cumplir el objetivo previsto de tu aplicación. | No puedes ignorar ni intentar eludir la política Datos de Usuario ni la de aplicaciones de salud, que son fundamentales. |
| Consulta las preguntas frecuentes y directrices para los permisos de salud de Android si quieres ver una lista completa de casos prácticos y requisitos. |
Permisos de Health Connect by Android
El acceso a los datos de Salud conectada se limita a las aplicaciones con usos principales aprobados de salud, actividad física, atención médica o investigación sanitaria. Debes limitar el acceso a los datos estrictamente al ámbito de aplicación mínimo necesario para estas funciones aprobadas y obtener el consentimiento explícito del usuario antes de compartir los datos de salud con terceros. La transparencia es clave, así que proporciona avisos claros y una política de privacidad completa donde se explique la recogida, el uso, la gestión y la eliminación de los datos. Protege los datos de usuario frente a accesos no autorizados y cumplir la legislación aplicable (por ejemplo, HIPAA, RGPD). Revisa la política completa para garantizar su cumplimiento.
Salud conectada es una plataforma Android que permite que aplicaciones de salud y actividad física almacenen y compartan los mismos datos en el dispositivo en un ecosistema unificado. También ofrece a los usuarios un único lugar donde controlar qué aplicaciones pueden leer y escribir datos de salud y actividad física, incluidos los registros de salud. Los registros de salud pueden incluir el historial médico, diagnósticos, tratamientos, medicamentos, resultados de análisis y otros datos clínicos obtenidos de proveedores o instituciones de atención sanitaria, o a través de plataformas de salud de terceros compatibles.
Salud conectada admite la lectura y escritura de diferentes tipos de datos, desde los pasos hasta la temperatura corporal y los datos del registro de salud.
Los datos a los que se accede a través de los Permisos de Salud conectada se consideran datos de usuario personales y sensibles sujetos a la política Datos de Usuario. Si tu aplicación se considera una aplicación de salud o tiene funciones relacionadas con la salud y accede a datos de salud (incluidos los datos de Salud conectada), también debe cumplir la política de aplicaciones de salud.
Consulta esta guía para desarrolladores de Android para saber cómo empezar a utilizar Salud conectada. Para solicitar acceso a los tipos de datos de Salud conectada y ver otras preguntas frecuentes, consulta las preguntas frecuentes y las indicaciones sobre los permisos de salud de Android.
Las aplicaciones distribuidas a través de Google Play deben cumplir los siguientes requisitos de políticas para poder leer y/o escribir datos en Salud conectada.
Acceso y uso adecuados de Health Connect
Salud conectada solo puede usarse de acuerdo con las políticas y los términos y condiciones aplicables, y para los usos aprobados, tal como se establece en esta política. Esto quiere decir que solo podrás solicitar acceso a los permisos cuando tu aplicación o servicio cumpla uno de los usos aprobados.
Los usos aprobados incluyen actividad física y bienestar, recompensas, asesoramiento de actividad física, bienestar en la empresa, atención médica, investigación sobre salud y juegos. Las aplicaciones que tengan acceso a estos casos de uso no pueden ampliar su uso a fines no especificados o no permitidos.
Solo las aplicaciones o los servicios con una o más funciones que benefician la salud y el estado físico de los usuarios pueden solicitar acceso a los permisos de Salud conectada. Por ejemplo:
- Aplicaciones o servicios que permiten a los usuarios registrar, informar, monitorizar y/o analizar directamente su actividad física, el sueño, el bienestar mental, la nutrición, las medidas de salud, las descripciones físicas, los registros de salud y/u otras descripciones y medidas relacionadas con la salud o el estado físico.
- Aplicaciones o servicios que permiten a los usuarios almacenar su actividad física, el sueño, el bienestar mental, la nutrición, las medidas de salud, las descripciones físicas, los registros de salud y/u otras descripciones y medidas relacionadas con la salud o el estado físico en su dispositivo, así como compartir sus datos con otras aplicaciones en el dispositivo que cumplan estos usos.
- Aplicaciones o servicios que permiten a los usuarios llevar un control de enfermedades crónicas, tratamientos médicos o asistencia sanitaria.
El acceso a Salud conectada no puede infringir esta política ni otros términos y condiciones ni políticas aplicables de Salud conectada, lo que incluye los siguientes fines:
- No uses Salud conectada en el desarrollo de aplicaciones, entornos o actividades, o para su incorporación en estas, donde el uso o el error de Salud conectada pueda razonablemente suponer la muerte, lesiones personales, daños a personas o daños medioambientales o materiales (como la creación o el funcionamiento de instalaciones nucleares, el control del tráfico aéreo, los sistemas de soporte vital o las armas).
- No accedas a los datos obtenidos a través de Salud conectada usando aplicaciones sin interfaz gráfica. Las aplicaciones deben mostrar un icono claramente identificable en la bandeja de aplicaciones, en los ajustes de la aplicación en el dispositivo, en los iconos de notificación, etc.
- No uses Salud conectada con aplicaciones que sincronicen datos entre dispositivos o plataformas no compatibles.
- No uses Salud conectada para conectar con aplicaciones, servicios o funciones que estén dirigidas únicamente a menores.
- Adopta medidas razonables y adecuadas para que todas las aplicaciones o sistemas que hagan uso de Salud conectada cuenten con protección frente al acceso, uso, destrucción, pérdida, alteración o divulgación no autorizados o ilegales.
Además, es responsabilidad tuya asegurar el cumplimiento de cualquier requisito normativo o legal que pueda aplicarse según el uso previsto de Salud conectada y de cualquier dato de Salud conectada. Por ejemplo, si eres una entidad o una empresa asociada sujeta a la ley de transferencia y responsabilidad de los seguros médicos de EE. UU. (Health Insurance Portability and Accountability Act, HIPAA), debes cumplir los requisitos aplicables a tu acceso y uso de la información de Salud conectada. Si eres un desarrollador sujeto al Reglamento General de Protección de Datos (RGPD) para los usuarios de la UE, también debes cumplir con tus obligaciones en virtud del RGPD. Esta legislación puede exigirte que suscribas contratos adicionales antes de compartir datos (por ejemplo, un contrato de colaboración empresarial o un contrato de tratamiento de datos) con las entidades pertinentes implicadas en tus actividades de tratamiento. También es responsabilidad de los desarrolladores de aplicaciones determinar si sus actividades requieren dichos contratos. Los desarrolladores deben proporcionar a Google pruebas de dicho contrato o del cumplimiento si se les solicita.
Google no respalda el uso ni garantiza la precisión de los datos contenidos en Salud conectada para ningún uso o fin (en particular, para usos médicos, de investigación o de salud) salvo que se indique explícitamente en el etiquetado o en la información proporcionada por Google para productos o servicios específicos de Google. Google renuncia a todas las responsabilidades relacionadas con el uso de datos obtenidos a través de Salud conectada.
Uso Limitado
Al utilizar Salud conectada, el uso de los datos y el acceso a ellos debe cumplir las siguientes limitaciones específicas:
- El uso de los datos debe limitarse a ofrecer o mejorar el uso adecuado o las funciones que sean visibles en la interfaz de usuario de la aplicación.
- Los datos de usuario solo se pueden transferir a terceros con el consentimiento explícito del usuario por motivos de seguridad (por ejemplo, para investigar abusos), para cumplir las leyes o reglamentos aplicables o como parte de fusiones o adquisiciones.
- El acceso de personas a los datos de usuario está restringido salvo que se obtenga el consentimiento explícito del usuario, por razones de seguridad, para cumplir las leyes o si dichos datos se agregan para realizar operaciones internas de acuerdo con requisitos legales.
- Se prohíbe cualquier otra transferencia, uso o venta de los datos de Salud conectada, incluidos los siguientes:
- Transferencia o venta de datos de usuario a terceros, como plataformas publicitarias, agentes de datos o cualquier distribuidor de información.
- Transferencia, venta o uso de datos de usuario para la publicación de anuncios, incluidos los personalizados o basados en intereses.
- Transferencia, venta o uso de datos de usuario para determinar la solvencia o con fines de préstamo.
- Transferencia, venta o uso de datos de usuario con cualquier producto o servicio que pueda calificarse como dispositivo médico, salvo que la aplicación del dispositivo médico cumpla todos los reglamentos aplicables, incluyendo obtener los permisos o aprobaciones que se necesiten de los organismos reguladores pertinentes (por ejemplo, la FDA de EE. UU.) para su uso previsto de datos de Salud Conectada, y el usuario haya proporcionado consentimiento explícito para dicho uso.
- Transferencia, venta o uso de datos de usuario para cualquier fin o de cualquier manera que esté relacionada con información médica protegida (según la HIPAA) a menos que la haya iniciado el usuario y cumpla el reglamento de la HIPAA.
Acceso mínimo a los datos
Solo debes solicitar acceso a los permisos necesarios para implementar las funciones o los servicios de tu producto. Estas solicitudes de acceso deben ser específicas y limitarse a los datos que se necesitan.
Información y control transparentes y precisos
Salud conectada trata datos de salud y actividad física, lo que incluye información personal y sensible. Los desarrolladores deben comunicar de forma clara y accesible sus prácticas relacionadas con datos mediante una política de privacidad exhaustiva. Dichas comunicaciones deben incluir lo siguiente:
- Una representación precisa de la identidad de la aplicación o del servicio que solicita acceder a los datos del usuario.
- Información clara y precisa que explique los tipos de datos a los que se accede, que se solicitan y/o recogen. Los datos deben estar relacionados con una función que ven los usuarios o una recomendación ofrecida en tu aplicación.
- Una explicación de cómo se usarán y/o se compartirán los datos: si solicitas datos por un motivo, pero también se usarán para otro secundario, debes revelar a los usuarios todos los usos.
- Documentación de ayuda al usuario que explique cómo pueden los usuarios gestionar y eliminar sus datos de la aplicación, y qué pasa con ellos cuando una cuenta se desactiva y/o se elimina.
- Información sobre el tratamiento de todos los datos de usuario personales y sensibles de forma segura, y su transmisión mediante un sistema moderno de cifrado, como el protocolo HTTPS.
Si quieres obtener más información sobre los requisitos para las aplicaciones que se conecten a Salud conectada, consulta este artículo del Centro de Ayuda.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
| Tu aplicación debe cumplir la política de aplicaciones de salud si se considera una aplicación de salud o tiene funciones relacionadas con la salud y accede a datos de salud, incluidos los datos de Salud conectada. | No uses Salud conectada en aplicaciones de alto riesgo (por ejemplo, de salud aeroespacial o de control de sistemas vitales como marcapasos) ni en aplicaciones que están dirigidas solo a menores. |
| Ve a Permisos de salud de Android: directrices y preguntas frecuentes para obtener información sobre cómo solicitar acceso a los tipos de datos de Salud conectada y consultar otras preguntas frecuentes. | No vendas ni transfieras datos de usuario con fines publicitarios, para determinar solvencia crediticia ni a agentes de datos. |
| Envía un formulario de declaración en Play Console y proporciona una justificación clara y detallada en la que expliques cómo usará los datos tu aplicación en beneficio del usuario. | No lo utilices con dispositivos médicos si no cumples los reglamentos correspondientes o no tienes los permisos necesarios. |
| Solicita solo los tipos de datos mínimos necesarios. | No accedas a datos de Salud conectada con fines secundarios o no aprobados. |
| Trata los datos de usuario de forma segura (por ejemplo, usa un sistema moderno de cifrado). | No solicites más permisos de datos que los que son necesarios para la función principal de tu aplicación. |
Servicio de VPN
VpnService es una clase base que permite que las aplicaciones amplíen y desarrollen sus propias soluciones de VPN. Solo las aplicaciones que usen VpnService y cuya función principal sea proporcionar servicios de VPN pueden crear un túnel seguro a nivel del dispositivo hasta un servidor remoto. Sin embargo, hay algunas excepciones, entre las que se incluyen las aplicaciones que necesitan un servidor remoto para realizar su función principal. A continuación se indican algunos ejemplos:
- Aplicaciones de controles parentales y gestión empresarial.
- Aplicaciones de seguimiento de uso.
- Aplicaciones de seguridad de dispositivos (por ejemplo, antivirus, gestión de dispositivos móviles o cortafuegos).
- Herramientas relacionadas con redes (por ejemplo, aplicaciones de acceso remoto).
- Aplicaciones de navegación web.
- Aplicaciones del operador que requieren el uso de funciones de VPN para proporcionar servicios de telefonía o conectividad.
VpnService no se puede usar para:
- Recoger datos de usuarios personales y sensibles sin aviso destacado y consentimiento.
- Redirigir o manipular el tráfico de usuarios desde otras aplicaciones en un dispositivo para obtener ingresos (por ejemplo, redirigir el tráfico de los anuncios a través de un país diferente al del usuario).
Las aplicaciones que utilicen VpnService deben:
- Documentar el uso de VpnService en la ficha de Google Play.
- Cifrar los datos desde el dispositivo hasta el destino del túnel de VPN.
- Respetar todas las Políticas del Programa para Desarrolladores, incluidas las políticas de Fraude publicitario, Permisos y Software malicioso.
| Qué debes hacer | Qué no debes hacer |
| Documenta el uso de VpnService claramente en la ficha de Google Play. | No uses VpnService para otros fines que no sean el principal de la VPN o excepciones específicas. |
| Cifra los datos desde el dispositivo hasta el destino del túnel de VPN. | No recopiles datos de usuario personales ni sensibles sin haber incluido un aviso destacado y haber obtenido el consentimiento de los usuarios. |
| Asegúrate de que la función principal de tu aplicación se ajuste al uso de la VPN o a las excepciones específicas. | No redirijas ni manipules el tráfico de usuarios desde otras aplicaciones en un dispositivo para obtener ingresos (por ejemplo, no redirijas el tráfico de los anuncios desde un país diferente al del usuario). |
| Incluye un aviso destacado en la aplicación y obtén el consentimiento explícito de los usuarios para cualquier tipo de recogida de datos sensibles. |
Permiso de alarma exacta
USE_EXACT_ALARM en Android 13 y versiones posteriores está altamente restringido y solo se usa para aplicaciones cuya función principal mostrada a los usuarios verdaderamente requiere precisión temporal, como aplicaciones específicas de alarmas, temporizadores o calendarios con notificaciones de eventos. Si tu aplicación no precisa esta función principal, plantéate usar el permiso SCHEDULE_EXACT_ALARM. Este proporciona la misma funcionalidad, pero el usuario debe concederle el acceso. Esta política evita un uso inadecuado que afectaría a los recursos del sistema. Revisa la política completa para garantizar su cumplimiento.Se incorporará un nuevo permiso, USE_EXACT_ALARM, que dará acceso a la función de alarma exacta en las aplicaciones, a partir de Android 13 (nivel de API de destino: 33).
USE_EXACT_ALARM es un permiso restringido y las aplicaciones solo deben declarar este permiso si su función principal requiere una alarma exacta. Las aplicaciones que soliciten este permiso restringido estarán sujetas a revisión y, si no cumplen los criterios de uso aceptable, no se podrán publicar en Google Play.
Usos aceptables para el permiso de alarma exacta
Tu aplicación solo debe utilizar la función USE_EXACT_ALARM si la función o el propósito principal de tu aplicación para el usuario requiere acciones con pautas de tiempo precisas, como en los casos siguientes:
- Se trata de una aplicación de alarma o temporizador.
- Se trata de una aplicación de calendario que muestra notificaciones de eventos.
Si tu aplicación hace un uso de la función de alarma exacta que no se ajusta a los casos mencionados anteriormente, te recomendamos que evalúes la conveniencia de utilizar SCHEDULE_EXACT_ALARM como opción alternativa.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
Solicita la versión concedida automáticamente del permiso (USE_EXACT_ALARM) solo si la función principal de tu aplicación es de alarma o calendario. |
No uses este permiso para funciones no esenciales que no contribuyan directamente al propósito principal de la aplicación. |
En su lugar, usa SCHEDULE_EXACT_ALARM si no se cumplen los requisitos anteriores. |
|
| Completa la declaración de Play Console para indicar la funcionalidad de la aplicación. | |
| Revisa el nuevo permiso para usar alarmas exactas y obtén más información sobre la funcionalidad de alarmas exactas. |
Permiso de intent de pantalla completa
USE_FULL_SCREEN_INTENT se concede automáticamente solo para las aplicaciones cuya función principal es establecer alarmas o gestionar llamadas. Para cualquier otro caso práctico, debes obtener el consentimiento explícito de los usuarios y explicar claramente lo que necesitas. Esta política impide el uso inadecuado de intents de pantalla completa con fines no esenciales y requiere que su uso no interfiera en el dispositivo del usuario, otras aplicaciones o la usabilidad general, ni los interrumpa. Revisa la política completa para garantizar su cumplimiento.En el caso de las aplicaciones orientadas a Android 14 (nivel de API de destino 34) y versiones posteriores, USE_FULL_SCREEN_INTENT es un permiso de acceso especial de aplicaciones. A las aplicaciones solo se les concederá automáticamente el permiso USE_FULL_SCREEN_INTENT si la función principal de la aplicación pertenece a una de las siguientes categorías que requieren notificaciones de prioridad alta:
- Establecer una alarma
- Recibir llamadas telefónicas o videollamadas
Las aplicaciones que soliciten este permiso estarán sujetas a revisión y, si no cumplen los criterios anteriores, no se les concederá automáticamente este permiso. En ese caso, las aplicaciones deberán pedir permiso al usuario para utilizar USE_FULL_SCREEN_INTENT.
Recuerda que cualquier uso del permiso USE_FULL_SCREEN_INTENT debe cumplir todas las políticas para desarrolladores de Google Play, incluidas nuestras políticas de software no deseado para móviles, de abuso de dispositivos y redes y de anuncios. Las notificaciones de intent de pantalla completa no pueden interrumpir, dañar ni acceder al dispositivo del usuario, ni interferir en este, de forma no autorizada. Además, las aplicaciones no deben interferir en otras aplicaciones ni en la usabilidad del dispositivo.
Consulta más información sobre el permiso USE_FULL_SCREEN_INTENT en nuestro Centro de Ayuda.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
| Solicita el consentimiento del usuario para el permiso y proporciona una explicación clara de la solicitud si no se concede el permiso automáticamente. | No utilices este permiso para funciones no esenciales o de baja prioridad. |
|
Úsalo solo para las notificaciones o alertas necesarias de alta prioridad. |
No utilices este permiso para interferir en dispositivos u otras aplicaciones. |
| Envía un formulario de declaración en Play Console para establecer la elegibilidad previa a la concesión del permiso de intent de pantalla completa si tu aplicación está orientada a Android 14 o versiones posteriores. | No utilices este permiso para mostrar anuncios invasivos o notificaciones molestas. |
Consulta más información sobre el permiso USE_FULL_SCREEN_INTENT y sus requisitos. |
API Age Signals y datos de usuario
Para proteger los datos de los usuarios, solo podrás usar los datos proporcionados por la API Age Signals con el objetivo de ofrecer experiencias apropiadas para la edad de los usuarios en la aplicación que reciba dichos datos. Estas directrices permiten garantizar que uses la API estrictamente para cumplir los requisitos y no para obtener beneficios comerciales ni para hacer un seguimiento.
Esta política define las condiciones para usar la API Age Signals, que proporciona acceso a datos personales y sensibles de los usuarios sobre su edad y el consentimiento parental.
Solo puedes usar los datos a los que accedas a través de la API Age Signals con el único fin de cumplir las obligaciones legales y normativas aplicables, como ofrecer experiencias adecuadas para cada edad en tu aplicación.
Tienes terminantemente prohibido usar estos datos para los siguientes fines, entre los que se incluyen:
- Fines publicitarios, de marketing o de personalización, incluida la publicación de anuncios segmentados
- Analíticas de datos, elaboración de perfiles de usuario o inteligencia empresarial
- Vender, compartir o transferir los datos a terceros por cualquier motivo, excepto cuando lo exija la ley
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Limita el uso de datos a los casos en los que sea necesario para cumplir las normativas. | No utilices estos datos para realizar acciones de marketing ni publicidad segmentada. |
| Comprueba los requisitos de consentimiento parental. | No uses estos datos para ejecutar analíticas ni crear perfiles de usuario. |
| Asegúrate de que las experiencias de los usuarios se correspondan con su edad. | No compartas estos datos con terceros por ningún motivo, salvo que lo exija la ley. |
Help us improve this policy article by taking a 2-minute survey.