Aviso importante: Los resúmenes de las políticas son descripciones generales únicamente. Siempre se debe consultar la política completa para su cumplimiento. En caso de conflicto, la política completa tiene prioridad.
Próximos cambios en este artículo
Este artículo se actualizará con los cambios anunciados recientemente.
- Con el objetivo de ayudar a proteger los datos de los usuarios, los desarrolladores solo podrán usar los datos que proporciona la API de Age Signals para brindar experiencias adecuadas para la edad en la aplicación que recibe estos datos.
Esta es una política nueva y entrará en vigencia a partir del 1 de enero de 2026..
- Con el objeto de garantizar la seguridad y transparencia para los usuarios, actualizaremos nuestra política sobre la API de Accessibility para aclarar y reforzar el cumplimiento de las reglas existentes que establecen que está prohibido todo uso de esta API que tenga como objetivo habilitar que una aplicación inicie, planifique y ejecute acciones de forma autónoma. Este comportamiento puede cambiar la configuración del usuario sin su permiso, eludir controles de privacidad de Android y utilizar la interfaz del usuario de manera engañosa por medio de la ejecución de acciones sin el conocimiento o consentimiento del usuario.
(en vigencia a partir del 28 de enero de 2026)
Para obtener una vista previa del artículo "Permisos y APIs que Acceden a Información Sensible" actualizado, visite esta página.
Para promover la confianza de los usuarios, Google Play exige que la solicitud de permisos y APIs que acceden a datos sensibles de los usuarios debe ser obligatoria para las funcionalidades principales de la aplicación según se promociona en su ficha de Play Store y se limiten a los fines para los que el usuario otorgó consentimiento. Los datos sensibles nunca se deben usar de manera inadecuada ni divulgar de forma deficiente, ni se debe acceder a ellos sin que sea necesario. Solicite permisos y APIs sensibles de manera incremental, y explique cada nivel. Use los datos únicamente en función del consentimiento que se otorgó para ellos y obtenga consentimiento nuevamente para otros fines. Revise la política completa para asegurarse de estar en cumplimiento.
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
Para proteger la privacidad del usuario, Google Play define permisos restringidos, que están sujetos a requisitos adicionales, y exige que las aplicaciones los usen de manera responsable y no manipulen a los usuarios para que otorguen acceso. Respete las decisiones de los usuarios cuando rechacen solicitudes de permisos y ofrezca alternativas para abordar esos casos. Tenga en cuenta que ciertos permisos restringidos pueden estar sujetos a requisitos adicionales. Revise la política completa para asegurarse de estar en cumplimiento.
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.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Si un usuario rechaza un permiso restringido, su aplicación debe respetar esa decisión sin manipulación. | No use permisos para incumplir la política de Software Malicioso de Google Play, incluido el Abuso de Privilegios Elevados. |
| Ofrezca otra forma de completar una función si un usuario rechaza un permiso, como permitir la entrada manual de datos. | No manipule ni mienta a los usuarios. Nunca presione ni engañe a los usuarios para que otorguen permisos. |
| Siga la política de Datos del Usuario, porque todos los datos a los que se accede a través de estos permisos son sensibles. | No les niegue a los usuarios una alternativa razonable si rechazan un Permiso Restringido; asegúrese de que la aplicación siga funcionando. |
Solicite permisos peligrosos (por ejemplo, READ_CALENDAR) con una solicitud de tiempo de ejecución y una explicación clara. |
No los solicite sin justificación. Solicite un permiso restringido únicamente para una función esencial imperativa que no tenga alternativa. |
Dirija a los usuarios a la página de configuración del sistema para que aprueben los permisos especiales (por ejemplo, SYSTEM_ALERT_WINDOW). |
Permisos de SMS y Registro de Llamadas
Google Play impone restricciones estrictas sobre el acceso a datos altamente sensibles de SMS y Llamadas. Su aplicación debe ser el controlador designado predeterminado de SMS, Teléfono y Asistente para solicitar estos permisos. El uso se limita únicamente a la funcionalidad principal documentada de su aplicación que es absolutamente imprescindible para su propósito principal. Estos datos nunca se deben usar con fines de publicidad ni otros no aprobados. Revise la política completa para asegurarse de estar en cumplimiento.
Los 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:
| Permiso Restringido | Requisito |
|---|---|
| Grupo de permisos de Registro de llamadas (p. ej., READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS) | Debe estar registrado activamente como el controlador predeterminado de Teléfono o Asistente en el dispositivo. |
| Grupo de permisos de SMS (p. ej., READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS) | Debe estar registrado activamente como controlador predeterminado de SMS o del Asistente en el dispositivo. |
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.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Envíe un formulario de declaración en Play Console. | No solicite permisos de SMS/llamadas sin una justificación de necesidad principal. |
| Documente con claridad la funcionalidad principal que requiere acceso para los usuarios. | No use estos datos para publicidad ni con otros fines. |
| Cuando sea posible, use alternativas que cumplan con las políticas, como la API de SMS Retriever. | No almacene ni comparta datos de SMS o llamadas innecesarios. |
| Deje de acceder a los datos de inmediato si pierde el estado de controlador predeterminado. | No intente derivar estos datos con métodos alternativos. |
| Revise los usos permitidos y excepciones de los permisos de SMS y llamadas. |
Permisos de Ubicación
Para proteger la privacidad del usuario, la política de ubicación en segundo plano exige que las aplicaciones presenten una justificación sólida y obtengan el consentimiento explícito del usuario para acceder a la información que necesitan. Los datos de ubicación que reciban del dispositivo deben limitarse a funciones esenciales que beneficien directamente al usuario y estén estrechamente relacionadas con el propósito principal de la aplicación; no se permite bajo ninguna circunstancia su uso con fines exclusivamente publicitarios o analíticos. Siempre que sea posible, reduzca al mínimo las solicitudes de acceso y opte por alternativas menos sensibles, como la ubicación aproximada y el acceso en primer plano. El usuario es quien debe otorgar acceso a la ubicación del dispositivo a través de Servicios en Primer Plano y de forma temporal. Por su parte, el acceso en segundo plano se reserva únicamente para funciones esenciales. Revise la política completa para asegurarse de estar en cumplimiento.
Se 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:
- Las aplicaciones no pueden acceder a los datos protegidos por permisos de ubicación (p. ej.,
ACCESS_FINE_LOCATION,ACCESS_COARSE_LOCATION,ACCESS_BACKGROUND_LOCATION) luego de que estos dejen de ser necesarios para implementar funciones o servicios existentes dentro de la aplicación. - Nunca debe solicitar permisos de ubicación a los usuarios únicamente con fines de publicidad o análisis. Las aplicaciones que extienden el uso permitido de este dato para publicar anuncios deben cumplir con nuestra Política de Anuncios.
- Las aplicaciones deben solicitar el alcance mínimo necesario (es decir, ubicación aproximada en lugar de precisa y uso en primer plano en vez de en segundo plano) para proporcionar el servicio o la función en curso que requiere la ubicación, y los usuarios deben tener una expectativa razonable de que el servicio o la función necesita el nivel de ubicación solicitado. Por ejemplo, es posible que rechacemos las aplicaciones que soliciten acceso o que accedan a la ubicación en segundo plano sin una justificación convincente.
- La ubicación en segundo plano solo se puede usar con el fin de proporcionar funciones beneficiosas para el usuario y relevantes para la funcionalidad principal de la aplicación.
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:
- Se inició como una continuación de una acción iniciada por el usuario dentro de la aplicación.
- Finaliza inmediatamente después de que la aplicación completa el caso de uso previsto de la acción iniciada por el usuario.
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.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| En el caso de las aplicaciones dirigidas a niños, satisfaga la política de Diseñado para Familias. | No use la ubicación del dispositivo únicamente con fines publicitarios o estadísticos. |
| Revise los requisitos importantes de los permisos antes de enviar su aplicación para que se publique. | No acceda a los datos más adelante si ya no es necesario. |
| Complete la declaración de Console para la ubicación en segundo plano. | No solicite la ubicación del dispositivo para aplicaciones dirigidas a niños. |
| No venda la ubicación del dispositivo. |
Permiso "Acceso a todos los archivos"
La política de Google Play considera que el acceso a archivos y directorios de los usuarios es una acción sensible y de alto riesgo, por lo que restringe el uso del permiso MANAGE_EXTERNAL_STORAGE en dispositivos con Android 11 o versiones posteriores. Para poder solicitar este permiso, la aplicación debe tener funciones esenciales que requieran acceso amplio a esta información, siempre con un propósito pensado para el usuario y nunca con fines de terceros. Este requisito busca prevenir la recopilación innecesaria de datos y proteger la privacidad de los usuarios. Las aplicaciones que soliciten este permiso deben presentar un mensaje claro que permita a los usuarios tomar una decisión fundamentada en materia de privacidad y, además, obtener la aprobación correspondiente a través del proceso de revisión de aplicaciones de Play. Revise la política completa para asegurarse de estar en cumplimiento.
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:
- Las aplicaciones solo deben solicitar acceso al almacenamiento del dispositivo que resulte fundamental para su funcionamiento y no pueden solicitar acceso al almacenamiento del dispositivo en nombre de ningún tercero que no esté relacionado con la funcionalidad crítica de la aplicación.
- Los dispositivos Android que ejecuten la versión R o una posterior requerirán el permiso
MANAGE_EXTERNAL_STORAGEpara administrar el acceso en el almacenamiento compartido. Todas las aplicaciones que se orienten a Android R y soliciten acceso amplio al almacenamiento compartido ("Acceso a todos los archivos") deben realizar y aprobar una revisión de acceso adecuada antes de su publicación. Las aplicaciones que pueden usar este permiso deben solicitar a los usuarios que habiliten el "Acceso a todos los archivos" en la configuración de "Acceso especial de apps". Para obtener más información sobre los requisitos de Android R, consulte este artículo de ayuda.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Priorice el uso de alternativas que respeten la privacidad, como el Framework de Acceso al Almacenamiento o la API de MediaStore. |
No solicite el permiso |
| Declare este permiso cuando envíe un formulario de declaración en Play Console. | No tergiverse la funcionalidad principal de su aplicación. |
| Defina y documente con claridad la funcionalidad principal de su aplicación en la revisión de la aplicación. |
No almacene ni comparta datos más allá de los que se requieran según las necesidades esenciales y divulgadas. |
| Indíqueles claramente a los usuarios que habiliten “Acceso a todos los archivos” para su aplicación en la página de configuración “Acceso especial de apps”. | |
| Asegúrese de revisar los requisitos de Android R para obtener más información. |
Permisos para acceder a Fotos y Videos
Para proteger la privacidad y seguridad de los usuarios, Google Play exige que las aplicaciones que solicitan los permisos READ_MEDIA_IMAGES o READ_MEDIA_VIDEO muestren casos de uso principales legítimos y sólidos en los que se demuestre la necesidad de acceso persistente o frecuente a fotos y videos. Si su aplicación no cumple con los requisitos para este acceso, debe quitar los permisos. En cambio, use un selector del sistema como el Selector de fotos de Android, que preserva la privacidad, para necesidades únicas o poco frecuentes. Revise la política completa para asegurarse de estar en cumplimiento.
Las fotos y los videos que se encuentran en el dispositivo de un usuario se consideran datos personales y sensibles del usuario sujetos a la política de Datos del Usuario de Google Play. Las aplicaciones solo podrán acceder a las fotos y videos para fines directamente relacionados con las funciones de la aplicación y no podrán solicitar acceso en nombre de ningún tercero para fines no relacionados con las funciones de la aplicación para el usuario. Para ofrecer una experiencia que preserve más la privacidad, recomendamos usar un selector de archivos del sistema, como el selector de fotos.
Las aplicaciones que requieren un acceso amplio a archivos de fotos y videos ubicados en el almacenamiento compartido de un dispositivo deben pasar satisfactoriamente una revisión de acceso apropiada y demostrar un caso de uso principal que requiera un acceso persistente o frecuente a fotos o videos de archivos ubicados en un almacenamiento compartido. Las aplicaciones que tengan una necesidad infrecuente o de una sola vez de acceder a estos archivos deben usar un selector de archivos del sistema, como el selector de fotos de Android.
El acceso amplio a las fotos y videos también está sujeto a los siguientes requisitos:
- Las aplicaciones que tengan como objetivo Android 13 (nivel de API 33) o versiones posteriores requieren los permisos
READ_MEDIA_IMAGESoREAD_MEDIA_VIDEOpara obtener acceso amplio a archivos de fotos o videos ubicados en el almacenamiento compartido del dispositivo. Todas las aplicaciones que tengan como objetivo Android 13 y versiones posteriores, y soliciten los permisosREAD_MEDIA_IMAGESoREAD_MEDIA_VIDEO, deben pasar satisfactoriamente una revisión de acceso apropiada antes de la publicación.- Las aplicaciones que soliciten acceso a los permisos
READ_MEDIA_VIDEOoREAD_MEDIA_IMAGESdeben demostrar satisfactoriamente un caso de uso principal que requiera la necesidad persistente o frecuente de un acceso a fotos o videos ubicados en un almacenamiento compartido.
- Las aplicaciones que soliciten acceso a los permisos
Si su aplicación no requiere un acceso amplio a los permisos READ_MEDIA_VIDEO o READ_MEDIA_IMAGES ni califica para ellos, debe quitar el permiso del manifiesto de su aplicación para cumplir satisfactoriamente los requisitos de la revisión de políticas.
De acuerdo con la política de Permisos Restringidos, debe realizar un esfuerzo razonable para adaptar el contenido a los usuarios que no otorguen un acceso amplio a los archivos multimedia de su dispositivo. Esto incluye facilitar con fluidez una experiencia adaptada para que los usuarios puedan disfrutar de la función o la funcionalidad principal de la aplicación.
Las aplicaciones que tengan un caso de uso de acceso legítimo a fotos o videos, pero que no califiquen para los permisos READ_MEDIA_IMAGES o READ_MEDIA_VIDEO, deben usar un selector de archivos del sistema, como el selector de fotos. Para obtener más información, consulte este artículo del Centro de Ayuda.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Envíe un formulario de declaración en Play Console. | No recopile más datos de fotos o videos que los necesarios. |
| Use un selector del sistema como el selector de fotos si no necesita acceso amplio. | No intente omitir ni manipular el consentimiento del usuario. |
| Proporcione evidencia para justificar su caso de uso durante la revisión de la aplicación. | No bloquee ni limite la funcionalidad si un usuario rechaza un permiso no esencial. En cambio, use un selector del sistema para manejar la solicitud de archivos con fluidez. |
| Explique claramente a los usuarios por qué su aplicación necesita estos permisos. | |
| Si desea obtener más información, revise Detalles sobre la política de Permisos para Acceder a Fotos y Videos de Google Play. |
Permiso de Visibilidad de Paquetes (Aplicaciones)
Acceder al inventario de una aplicación instalada del usuario se considera acceder a datos sensibles. La política de Google Play limita estrictamente la visibilidad amplia (QUERY_ALL_PACKAGES) y la permite únicamente para la funcionalidad principal de la aplicación que requiere un conocimiento exhaustivo de las aplicaciones instaladas con propósitos de interoperabilidad. Debe priorizar el uso de consultas finitas y dirigidas para acceder a aplicaciones específicas cuando sea posible, lo cual respeta más la privacidad. Bajo ninguna circunstancia los datos del inventario de la aplicación instalada se pueden vender ni compartir con fines de publicidad ni monetización por estadísticas. Revise la política completa para asegurarse de estar en cumplimiento.
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:
- Visibilidad amplia de la aplicación: La visibilidad amplia es la capacidad de una aplicación para tener una visibilidad extensa (o "amplia") de las aplicaciones instaladas ("paquetes") en un dispositivo.
- En el caso de las aplicaciones segmentadas al nivel de API 30 o niveles superiores, la visibilidad amplia de las aplicaciones instaladas mediante el permiso
QUERY_ALL_PACKAGESse restringe a casos de uso específicos en los que el conocimiento de las aplicaciones del dispositivo o la interoperabilidad con ellas son necesarios para que funcione la aplicación.- No puede usar
QUERY_ALL_PACKAGESsi su aplicación puede funcionar con una declaración de visibilidad de paquetes específicos segmentada más limitada (por ejemplo, consultar paquetes específicos e interactuar con ellos en lugar de solicitar una visibilidad amplia).
- No puede usar
- El uso de métodos alternativos para aproximar el nivel de visibilidad amplia asociado con el permiso
QUERY_ALL_PACKAGEStambién está restringido a las funciones principales para el usuario de la aplicación y la interoperabilidad con las aplicaciones que se detecten a través de este método. - Si desea conocer los casos de uso admisibles para el permiso
QUERY_ALL_PACKAGES, consulte este artículo del Centro de ayuda.
- En el caso de las aplicaciones segmentadas al nivel de API 30 o niveles superiores, la visibilidad amplia de las aplicaciones instaladas mediante el permiso
- Visibilidad limitada de la aplicación: La visibilidad limitada ocurre cuando una aplicación minimiza el acceso a los datos mediante búsquedas de aplicaciones específicas con métodos más puntuales (en lugar de métodos "amplios"), por ejemplo, búsquedas de aplicaciones específicas que satisfacen la declaración del manifiesto de la aplicación. Puede usar este método para realizar búsquedas de aplicaciones en los casos en que su aplicación tenga interoperabilidad en cumplimiento con las políticas o esté a cargo de la administración de esas aplicaciones.
- La visibilidad del inventario de las aplicaciones instaladas en un dispositivo debe estar directamente relacionada con el propósito o la funcionalidad principales a los que acceden los usuarios en su aplicació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.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
Envíe un formulario de declaración en Play Console para QUERY_ALL_PACKAGES y cualquier otro permiso de alto riesgo. |
No solicite |
| Para la revisión de su aplicación, documente con claridad por qué la aplicación necesita visibilidad, ya sea amplia o más dirigida. | No obtenga visibilidad amplia de la aplicación a través de métodos que no se permitan explícitamente por política. |
| Acceda únicamente a los datos mínimos necesarios. | No proporcione información falsa sobre la funcionalidad principal ni las necesidades de datos de su aplicación. |
| Revise Usos autorizados del permiso QUERY_ALL_PACKAGES para consultar los casos de uso admisibles. | No recopile ni use datos innecesarios de la aplicación instalada. |
Accessibility API
Google Play permite el uso de la API de AccessibilityService para una amplia variedad de aplicaciones. Sin embargo, solo los servicios diseñados para ayudar a las personas con discapacidades a acceder a sus dispositivos o superar desafíos derivados de sus discapacidades son elegibles para declararse como herramientas de accesibilidad configurando isAccessibilityTool=true en sus metadatos. Estas aplicaciones están exentas de los requisitos de divulgación destacada y consentimiento. Para todos los demás usos, o si no declara su aplicación como herramienta de accesibilidad, deberá completar una declaración de accesibilidad en Play Console y tendrá que implementar una divulgación clara en la aplicación donde se explique el uso y el acceso a los datos; asimismo, deberá obtener el consentimiento afirmativo del usuario. Revise la política completa para asegurarse de estar en cumplimiento.
No se puede usar la API de Accessibility para los siguientes fines:
- Cambiar los parámetros de configuración de los usuarios sin su permiso o impedir la posibilidad de que los usuarios inhabiliten o desinstalen cualquier aplicación o servicio, a menos que se cuente con la autorización de una madre, un padre o un tutor en una aplicación de control parental o de administradores autorizados en un software de administración empresarial
- Ignorar las notificaciones y los controles de privacidad integrados de Android
- Cambiar la interfaz de usuario o sacar provecho de ella de una manera engañosa o que de otro modo incumpla las Políticas para Desarrolladores de Google Play
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 IsAccessibilityTool
Las 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.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
Declare isAccessibilityTool=true con precisión en el archivo de metadatos de su servicio si el objetivo principal de su aplicación es la asistencia para personas con discapacidad. |
No haga un uso inadecuado del parámetro isAccessibilityTool y no lo utilice si su aplicación no es una herramienta de asistencia para personas con discapacidad. |
| Proporcione una declaración clara en Play Console y un video de demostración si usa la API de AccessibilityService. | No cambie la configuración del usuario sin permiso, no omita controles de privacidad y no registre audio de llamadas remotas. |
| Implemente una divulgación clara en la aplicación y obtenga el consentimiento del usuario si no es una herramienta de accesibilidad designada. | No use la API para iniciar, planificar ni ejecutar acciones o decisiones de forma autónoma. |
| Complete una declaración de accesibilidad cuando envíe un formulario de declaración en Play Console si no declaró que su aplicación es una herramienta de accesibilidad, pero usa la API de AccessibilityService. | No engañe ni confunda a los usuarios. No se puede usar la API para cambiar la IU ni para sacar provecho de ella de una manera engañosa. |
| Limite la recopilación y el uso de datos estrictamente a los fines divulgados y declarados. | No recopile datos innecesarios. Los datos recopilados deben limitarse estrictamente a los fines divulgados. |
| Cuando sea posible, use APIs y permisos con alcances más restringidos en lugar de la API de Accesibility para lograr la funcionalidad deseada. | No omita los requisitos de divulgación. Las divulgaciones no pueden ser un sustituto de la política de privacidad ni de otras descripciones de la aplicación. |
Permiso Solicitar Paquetes de Instalación
El permiso REQUEST_INSTALL_PACKAGES les permite a las aplicaciones solicitar la instalación de otros paquetes de aplicaciones. Este permiso se restringe a la funcionalidad principal de la aplicación, específicamente cuando el propósito primario implica de forma directa enviar o recibir paquetes de aplicaciones, o habilitar su instalación cuando la inicia el usuario. Se prohíbe el uso de este permiso para actualizar la aplicación, cambiar su funcionalidad o empaquetar otros APKs para instalaciones silenciosas o no autorizadas (excepto en el caso de la administración empresarial). Todas las instalaciones deben ser una elección directa y activa del usuario. Las aplicaciones que tienen como objetivo Android 8 o versiones posteriores deben tener este permiso para usar Intent.ACTION_INSTALL_PACKAGE. Revise la política completa para asegurarse de estar en cumplimiento.
El 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:
- Envío o recepción de paquetes de aplicación
- Habilitación de instalaciones de paquetes de app iniciadas por el usuario
Las funcionalidades permitidas incluyen las siguientes:
- Búsqueda o navegación web
- Servicios de comunicación que admitan archivos adjuntos
- Uso compartido, transferencia o administración de archivos
- Administración de dispositivos empresariales
- Copia de seguridad y restablecimiento
- Migración de Dispositivo o Transferencia Telefónica
- Aplicación Complementaria para sincronizar el teléfono con el dispositivo wearable o IoT (por ejemplo, reloj inteligente o smart TV)
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 permisoREQUEST_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. Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Documente de forma destacada y clara la funcionalidad principal por la que se solicita este permiso en la descripción de Google Play de la aplicación y cuando envíe un formulario de declaración a través de Play Console. | No solicite este permiso para una funcionalidad que no se relacione directamente con el objetivo principal de su aplicación, lo que incluye el uso compartido entre pares (P2P). Para cumplir con las condiciones de uso permitido, la técnica P2P debe ser el objetivo principal de la aplicación. |
|
Respete rigurosamente la funcionalidad permitida, como la búsqueda o navegación web; el uso compartido, transferencia o administración de archivos; la administración de dispositivos empresariales; la creación de copias de seguridad y el restablecimiento; la migración de dispositivos o transferencia telefónica, y el uso de una aplicación complementaria para sincronizar el teléfono con un dispositivo wearable o IoT. |
No solicite este permiso si la tarea requerida se puede realizar con un método menos intrusivo. |
| Asegúrese de que sus aplicaciones eviten las instalaciones en segundo plano o no intencionales. El usuario debe iniciar explícitamente todas las instalaciones de paquetes de aplicaciones. |
No cambie la forma en que su aplicación usa este permiso sin primero modificar su declaración de Play Console para que contenga información precisa y actualizada. Se prohíben los usos de este permiso que sean engañosos o que no estén declarados. |
Permisos de Sensores Corporales
Resumen de la Política
Para proteger la privacidad del usuario, Google Play exige que el acceso a datos altamente sensibles de sensores corporales (como frecuencia cardíaca, SpO2 y temperatura cutánea) esté sujeto a nuestras políticas de Datos del Usuario y Aplicaciones de Salud.
A partir de Android 16, las aplicaciones deben migrar del permiso general android.permission.BODY_SENSORS a los nuevos permisos de salud detallados. Por ejemplo, usará android.permission.health.READ_HEART_RATE para acceder a datos de frecuencia cardíaca. Este cambio afecta a todas las aplicaciones orientadas a Android 16 o versiones posteriores en todos los factores de forma, incluido Wear OS. Para obtener una lista completa de los cambios, consulte la página Cambios en el comportamiento: apps orientadas a Android 16 o versiones posteriores. Revisamos todas las solicitudes de permisos de sensores corporales, tanto heredados como nuevos, para garantizar que el caso de uso de su aplicación beneficie directamente al usuario y satisfaga estrictamente nuestras políticas.
Los datos provenientes de sensores que miden parámetros físicos del cuerpo (como la frecuencia cardíaca, la saturación de oxígeno en sangre (SpO₂) y la temperatura cutánea) se consideran información personal y sensible de los usuarios. Las aplicaciones que solicitan acceso a ellos están sujetas a los requisitos que se describen en la política de Datos del Usuario y la política sobre Aplicaciones de salud. Esto se aplica a las solicitudes de los permisos android.permission. y BODY_SENSORS android.permission. _BACKGROUNDBODY_SENSORS
En Android 16 y versiones posteriores, el permiso amplio BODY_SENSORS está en proceso de transición hacia permisos android.permissions.health.* más detallados y que preservan más la privacidad para tipos de datos específicos (por ejemplo, android.permission.health.READ_HEART_RATE , android.permission.health.READ_OXYGEN_SATURATION y android.permission.health.READ_SKIN_TEMPERATURE ).
Las aplicaciones orientadas a Android 16 o versiones posteriores deben usar estos permisos específicos para las APIs que antes requerían BODY_SENSORS . Consulte la página Cambios en el comportamiento: apps orientadas a Android 16 o versiones posteriores para obtener todos los detalles.
Todas las solicitudes de permisos para sensores corporales (tanto permisos heredados como los nuevos permisos detallados) pasarán por un proceso de revisión para garantizar que el uso previsto de estos datos personales y sensibles se ajuste a los casos de uso aprobados que aportan un beneficio directo a los usuarios. Estos casos se centran principalmente en funciones relacionadas con el seguimiento de la actividad física y el bienestar (por ejemplo, el monitoreo de entrenamientos en tiempo real), la supervisión médica o de afecciones específicas, la investigación sobre la salud (con las aprobaciones correspondientes) o la mejora de funciones de aplicaciones complementarias para wearables.
Para obtener una orientación completa sobre las políticas, incluidos los usos prohibidos, los casos de uso aceptables y los requisitos detallados, consulte Permisos de Android Health: Orientación y preguntas frecuentes.
| Qué debe hacer | Qué no debe hacer |
Use permisos de salud detallados específicos, como android.permission.health.READ_HEART_RATE, en lugar del permiso amplio BODY_SENSORS. |
No declare |
| Asegúrese de que su aplicación tenga una función principal beneficiosa para el usuario (p. ej., seguimiento de estado físico o monitoreo de salud) que requiera estrictamente los datos. | No acceda a los datos si no hay un beneficio claro y directo para el usuario. |
| Satisfaga las políticas de Datos del Usuario y Aplicaciones de salud. | No solicite ni use datos de sensores corporales para propósitos no aprobados, como publicidad general, estadísticas o perfilado de usuarios en función de estados de salud inferidos. |
| Solicite únicamente los permisos mínimos necesarios y los datos específicos que se requieren para el propósito original de su aplicación. | No ignore ni intente omitir las políticas esenciales de Datos del Usuario y Aplicaciones de salud. |
| Para obtener una lista completa de los casos de uso y los requisitos, consulte Permisos de salud de Android: orientación y preguntas frecuentes. |
Permisos para Health Connect de Android
El acceso a los datos de Health Connect se restringe a las aplicaciones con casos de uso principales de salud, estado físico, atención médica o investigación de salud. Debe limitar estrictamente el acceso a los datos al alcance mínimo necesario para estas funciones aprobadas y obtener el consentimiento explícito del usuario antes de compartir datos de salud con terceros. La transparencia es clave, así que proporcione divulgaciones claras y una política de privacidad completa donde se explique la recopilación, el uso, el manejo y la eliminación de los datos. Proteja los datos del usuario contra acceso no autorizado y satisfaga todas las leyes y reglamentaciones aplicables (p. ej., HIPAA, RGPD). Revise la política completa para asegurarse de estar en cumplimiento.
Health Connect es una plataforma de Android que permite que las aplicaciones de salud y fitness almacenen y compartan los mismos datos en el dispositivo, dentro de un ecosistema unificado. También ofrece un lugar centralizado para que los usuarios controlen qué aplicaciones pueden leer y escribir datos de salud y fitness, lo que incluye registros de salud. Los Registros de Salud pueden incluir historias clínicas, diagnósticos, tratamientos, medicamentos, resultados de laboratorio y otros datos clínicos obtenidos de instituciones o proveedores de atención médica, o a través de plataformas de salud compatibles de terceros.
Health Connect admite la lectura y escritura de una variedad de tipos de datos, desde pasos hasta temperatura corporal y datos de registros de salud.
Los 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. Si su aplicación califica como aplicación de salud o tiene funciones relacionadas con la salud, y accede a datos de salud (incluidos los datos de Health Connect), también debe satisfacer la política sobre Aplicaciones de salud.
Consulte esta guía para desarrolladores de Android sobre cómo comenzar a usar Health Connect. Para solicitar acceso a los tipos de datos de Health Connect y ver otras preguntas frecuentes, consulte el artículo de orientación y preguntas frecuentes sobre los permisos de salud de Android.
Las aplicaciones que se distribuyen en Google Play deben cumplir con los siguientes requisitos de las políticas para leer o escribir datos en Health Connect.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Su aplicación debe satisfacer 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 Health Connect. | No use Health Connect en aplicaciones de alto riesgo (por ejemplo, aviación o control de sistemas críticos para la vida, como marcapasos) ni en aplicaciones que se dirijan únicamente a niños. |
| Consulte Permisos de Salud de Android: Orientación y preguntas frecuentes para obtener información sobre cómo solicitar acceso a tipos de datos de Health Connect y consultar otras preguntas frecuentes. | No venda ni transfiera datos de los usuarios para fines relacionados con publicidad, solvencia crediticia o agentes de datos. |
| Envíe un formulario de declaración en Play Console y proporcione una justificación clara y detallada en la que se explique cómo su aplicación usará los datos para beneficiar al usuario. | No use los datos con dispositivos médicos sin la autorización y el cumplimiento reglamentario que se requieren. |
| Solicite únicamente los tipos de datos mínimos necesarios. | No acceda a datos de Health Connect con fines secundarios o no aprobados. |
| Maneje los datos de los usuarios de forma segura (por ejemplo, use criptografía moderna). | No solicite permisos de datos que vayan más allá de la funcionalidad principal de su aplicación. |
Acceso y Uso Adecuados de Health Connect
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.
Los casos de uso aprobados incluyen fitness y bienestar, recompensas, entrenamiento físico, bienestar corporativo, investigación y atención médica, y juegos. Las aplicaciones a las que se les otorgó acceso para estos casos de uso no deben extender su utilización a fines no permitidos o no divulgados.
Solo podrán solicitar acceso a los Permisos de Health Connect los servicios o las aplicaciones que tengan una o más funciones diseñadas para beneficiar la salud y el estado físico de los usuarios. Por ejemplo:
- Aplicaciones o servicios que les permitan a los usuarios registrar, informar, supervisar o analizar directamente su actividad física, sueño, bienestar mental, nutrición, mediciones de salud, descripciones físicas, registros de salud y otras descripciones y mediciones relacionadas con salud y fitness
- Aplicaciones o servicios que les permitan a los usuarios almacenar su actividad física, sueño, bienestar mental, nutrición, mediciones de salud, descripciones físicas, registros de salud y otras descripciones y mediciones relacionadas con salud y fitness en sus dispositivos, y compartir sus datos con otras aplicaciones integradas en los dispositivos que satisfagan estos casos de uso
- Aplicaciones o servicios que les permitan a los usuarios tratar afecciones crónicas, seguir tratamientos médicos o acceder a servicios de atención médica
Health Connect no deberá usarse incumpliendo esta política o cualquier otra política o términos y condiciones aplicables de Health Connect, lo que incluye los siguientes propósitos:
- No use Health Connect para desarrollar aplicaciones, entornos o actividades en los que se prevea de manera razonable que el uso o la falla de Health Connect podría provocar la muerte, lesiones personales, o bien daños a personas físicas, al medioambiente o a la propiedad (como la creación o la puesta en funcionamiento de instalaciones nucleares, controles de tráfico aéreo, sistemas de soporte vital o armamento). Tampoco deberá usar Health Connect para su incorporación en aplicaciones, entornos o actividades de las características mencionadas.
- No acceda a datos obtenidos a partir de Health Connect con aplicaciones sin interfaz gráfica. Las aplicaciones deben mostrar un ícono claramente identificable en la bandeja de aplicaciones, admitir la configuración en el dispositivo, mostrar íconos de notificaciones, etcétera.
- No use Health Connect con aplicaciones que sincronicen datos entre plataformas o dispositivos incompatibles.
- No use Health Connect para conectarse a aplicaciones, servicios o funciones que estén dirigidas exclusivamente a niños.
- 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.
También es responsabilidad suya garantizar el cumplimiento de cualquier requisito legal o reglamentario que se aplique según su uso previsto de Health Connect y los datos de Health Connect. Por ejemplo, si usted es una entidad cubierta o un socio comercial sujeto a la Ley de Responsabilidad y Portabilidad de Seguros Médicos (HIPAA), debe satisfacer los requisitos aplicables para acceder a la información de Health Connect y usarla. Si usted es un desarrollador sujeto al Reglamento General de Protección de Datos (RGPD) para usuarios de la UE, debe cumplir las obligaciones respectivas en virtud del RGPD. Estas leyes y reglamentaciones pueden exigirle celebrar otros acuerdos (por ejemplo, un Acuerdo entre Socios Comerciales o de Tratamiento de Datos) con las entidades pertinentes involucradas en sus actividades de tratamiento de datos antes de poder divulgarles información. También es responsabilidad de los desarrolladores de aplicaciones determinar si sus actividades requieren la celebración de dichos acuerdos. Los desarrolladores deben proporcionarle a Google evidencia de tales acuerdos o del cumplimiento correspondiente si así se les solicitara.
A excepción de lo que se detalla explícitamente en las etiquetas o la información que proporciona Google para sus productos o servicios específicos, Google no recomienda el uso ni garantiza la precisión de los datos incluidos en Health Connect para cualquier uso o propósito, y, en particular, para usos médicos o relacionados con la salud o la investigación. Google renuncia a toda responsabilidad asociada con el uso de datos obtenidos con Health Connect.
Uso Limitado
Cuando use Health Connect, el acceso a los datos y el uso que haga de ellos deben cumplir con limitaciones específicas:
- El uso de los datos se debe limitar a proporcionar o mejorar el caso de uso apropiado o las funciones visibles en la interfaz de usuario de la aplicación.
- Los datos de los usuarios se pueden transferir a terceros únicamente con el consentimiento explícito de los usuarios: con fines de seguridad (por ejemplo, para investigar un abuso), para satisfacer las leyes o reglamentaciones aplicables, o como parte de fusiones o adquisiciones.
- A menos que se haya obtenido el consentimiento explícito de los usuarios, el acceso de personas físicas a datos de los usuarios solo se permitirá para fines de seguridad, para satisfacer las leyes o cuando se agregan datos para operaciones internas de acuerdo con los requisitos legales.
- Está prohibido cualquier otro uso, transferencia o venta de datos de Health Connect, lo que incluye lo siguiente:
- Transferir o vender datos del usuario a terceros como plataformas publicitarias, agentes de datos o cualquier revendedor de información
- Transferir, vender o usar datos de los usuarios para publicar anuncios, lo que incluye publicidad personalizada o basada en intereses
- Transferir, vender o usar datos de los usuarios para determinar la solvencia crediticia o con fines de préstamos
- Transferir, vender o usar datos de los usuarios con cualquier producto o servicio que podría considerarse como un dispositivo médico, a menos que la aplicación de dispositivo médico satisfaga todas las reglamentaciones aplicables, lo que incluye haber obtenido las aprobaciones o los permisos necesarios de los órganos reguladores pertinentes (p. ej., la FDA de EE.UU.) para el uso previsto de los datos de Health Connect, y que el usuario haya otorgado su consentimiento explícito para tal uso
- Transferir, vender o usar datos de los usuarios para cualquier fin o de cualquier manera que involucre Información de Salud Protegida (según se define en la HIPAA), a menos que el usuario inicie tales operaciones y estas satisfagan las reglamentaciones de la HIPAA
Alcance Mínimo
Solo debe solicitar acceso a los permisos que son necesarios para implementar los servicios o las funciones de sus productos. Dichas solicitudes de acceso deben ser específicas para los datos que son necesarios y limitarse a ellos.
Control y Aviso Precisos y Transparentes
Health Connect maneja datos de salud y fitness, que incluyen información personal y sensible. Los desarrolladores deben divulgar información clara y accesible sobre sus prácticas de datos a través de una política de privacidad integral. En ella deben incluir lo siguiente:
- Una representación precisa de la identidad de la aplicación o el servicio que solicita acceso a los datos del usuario
- Información clara y precisa que explique los tipos de datos a los que se accede y que se solicitan o recopilan, los cuales deben estar relacionados con una función para el usuario o una recomendación ofrecida en la app en cuestión
- Una explicación sobre cómo se usarán o compartirán los datos: si solicita datos por un motivo, pero estos también se usarán para un propósito secundario, debe divulgar todos los casos de uso a los usuarios
- Documentación de ayuda para los usuarios que indique cómo pueden administrar sus datos y borrarlos de la aplicación, y qué ocurre con los datos cuando se desactiva o borra una cuenta
- Información sobre sus prácticas de manejo seguro de los datos sensibles y personales de los usuarios, lo que incluye transmitirlos con criptografía moderna (por ejemplo, a través de HTTPS)
Si desea obtener más información sobre los requisitos para las aplicaciones que se conectan a Health Connect, consulte este artículo del Centro de ayuda.
Servicio de VPN
La clase base VpnService les permite a los desarrolladores crear soluciones de VPN seguras. Google Play permite su uso únicamente para aplicaciones con una funcionalidad principal de VPN o que requieran un servidor remoto para funciones esenciales como controles parentales, seguimiento de uso de la aplicación, seguridad del dispositivo, herramientas de red, navegadores web o servicios de operador. Es fundamental que nunca se use VpnService para recopilar datos personales o sensibles de los usuarios sin una divulgación destacada y el consentimiento explícito. Además, se prohíbe estrictamente redireccionar o manipular el tráfico de usuarios de otras aplicaciones con fines de monetización. Todas las aplicaciones que usen VpnService deben documentar esto claramente en su ficha de Google Play y encriptar todos los datos que se transmiten del dispositivo al endpoint del túnel VPN. Revise la política completa para asegurarse de estar en cumplimiento.
VpnService 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:
- Aplicaciones de administración empresarial y control parental
- Opciones de seguimiento de uso de aplicaciones
- Aplicaciones de seguridad del dispositivo (por ejemplo, antivirus, administración de dispositivos móviles, firewall)
- Herramientas relacionadas con redes (por ejemplo, acceso remoto)
- Aplicaciones de navegación web
- Aplicaciones del operador que requieren el uso de funciones de la VPN para proporcionar servicios de conectividad o telefonía
VpnService no se puede usar para lo siguiente:
- Recopilar datos personales y sensibles de los usuarios sin su consentimiento y una divulgación destacada
- Redireccionar o manipular el tráfico de otras aplicaciones en un dispositivo con fines de monetización (por ejemplo, redireccionar el tráfico de anuncios por un país que no sea el del usuario)
Las aplicaciones que usan VpnService deben hacer lo siguiente:
- Documentar el uso de VpnService en la ficha de Google Play
- Encriptar los datos que van del dispositivo al extremo del túnel de la VPN
- Cumplir con todas las Políticas del Programa para Desarrolladores, incluidas las políticas de Fraude Publicitario, Permisos y Software Malicioso.
| Qué debe hacer | Qué no debe hacer |
| Documente el uso de VpnService claramente en la ficha de Google Play. | No use VpnService para fines que no sean los de la VPN principal o las excepciones especificadas. |
| Debe encriptar los datos que van del dispositivo al endpoint del túnel VPN. | No recopile datos personales ni sensibles de los usuarios sin una divulgación destacada y el consentimiento correspondiente. |
| Asegúrese de que la funcionalidad principal de su aplicación esté en línea con el uso de la VPN o las excepciones permitidas. | No redireccione ni manipule el tráfico de usuarios de otras aplicaciones en un dispositivo con fines de monetización (por ejemplo, redireccionar el tráfico de anuncios por un país que no sea el del usuario). |
| Proporcione una divulgación destacada en la aplicación y obtenga el consentimiento explícito correspondiente para toda recopilación de datos sensibles. |
Permiso de Alarmas Exactas
En Android 13 y versiones posteriores, USE_EXACT_ALARM es un permiso altamente restringido que se usa únicamente en aplicaciones cuya funcionalidad principal para el usuario requiere acciones con tiempos precisos, como es el caso de las aplicaciones de alarmas, temporizadores o calendarios con notificaciones de eventos. Si esta no es una necesidad fundamental para su aplicación, en su lugar, considere usar el permiso SCHEDULE_EXACT_ALARM, que ofrece la misma funcionalidad, pero el usuario es quien debe otorgar el acceso. Esta política evita que se realice un uso inadecuado que pueda afectar los recursos del sistema. Revise la política completa para asegurarse de estar en cumplimiento.
Se 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:
- Es una aplicación de alarma o temporizador.
- Es una aplicación de calendario que muestra notificaciones de eventos.
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.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
Solicite la versión del permiso otorgado automáticamente, USE_EXACT_ALARM, solo si la funcionalidad principal de su aplicación es de alarma o calendario. |
No use este permiso para funciones que no sean esenciales y que no contribuyan directamente al objetivo principal de la aplicación. |
Si no se cumplen los criterios anteriores, use SCHEDULE_EXACT_ALARM en su lugar. |
|
| Complete la declaración de Play Console para indicar la funcionalidad de la aplicación. | |
| Si desea obtener más información sobre la funcionalidad de las alarmas exactas, revise el nuevo permiso para usar alarmas exactas. |
Permiso de Intent de Pantalla Completa
En Android 14 y versiones posteriores, el permiso USE_FULL_SCREEN_INTENT se concede automáticamente solo a las aplicaciones cuya funcionalidad principal es configurar alarmas o gestionar llamadas. Para cualquier otro caso de uso, debe obtener el consentimiento explícito del usuario y explicar claramente el motivo de la necesidad. Esta política busca evitar el uso inadecuado de los intents de pantalla completa con fines no esenciales y exige que su implementación no afecte ni interrumpa el funcionamiento del dispositivo o el de otras aplicaciones, ni la usabilidad general. Revise la política completa para asegurarse de estar en cumplimiento.
En el caso de las aplicaciones que se orientan a Android 14 (nivel de API 34) y versiones superiores, USE_FULL_SCREEN_INTENT es un permiso especial de acceso para aplicaciones. Solo se permitirá automáticamente que las aplicaciones usen el permiso USE_FULL_SCREEN_INTENT si su funcionalidad principal está dentro de una de las siguientes categorías que requieren enviar notificaciones de alta prioridad:
- establecer una alarma
- recibir llamadas telefónicas o videollamadas
Las aplicaciones que soliciten este permiso están sujetas a revisión, y a las que no cumplan con los criterios indicados arriba no se les otorgará automáticamente este permiso. En esos casos, las aplicaciones deberán pedirle permiso al usuario para usar USE_FULL_SCREEN_INTENT.
No olvide que todo uso del permiso USE_FULL_SCREEN_INTENT debe satisfacer las Políticas para Desarrolladores de Google Play, incluidas las políticas de Software No Deseado para Dispositivos Móviles, Abuso de Dispositivos y Redes, y Anuncios. No se permite que las notificaciones de intents de pantalla completa interfieran con los dispositivos de los usuarios de maneras no autorizadas ni que los afecten negativamente o accedan a ellos. Las aplicaciones tampoco deben interferir con otras aplicaciones ni con la usabilidad del dispositivo.
Obtenga más información sobre el permiso USE_FULL_SCREEN_INTENT en nuestro Centro de ayuda.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Solicite el consentimiento de los usuarios para el permiso y proporcione una explicación clara para la solicitud si no se otorga automáticamente. | No use este permiso para funciones de baja prioridad o que no sean las principales. |
|
Limite el uso a notificaciones y alertas necesarias de alta prioridad. |
No use este permiso para interferir en dispositivos o en otras aplicaciones. |
| Envíe un formulario de declaración en Play Console para demostrar que su aplicación cumple con los requisitos de elegibilidad previa al otorgamiento del permiso de intent de pantalla completa si el objetivo es Android 14 o una versión posterior. | No use este permiso para anuncios invasivos o notificaciones invasivas. |
Obtenga más información acerca del permiso USE_FULL_SCREEN_INTENT y sus requisitos. |