Limitación de responsabilidad: los resúmenes de las políticas solo ofrecen una vista general. Consulta siempre la política completa para asegurar su cumplimiento. En caso de conflicto, la política completa tiene prioridad.
Google Play prohíbe que tu aplicación (o los SDKs de terceros en tu aplicación) acceda sin autorización o interfiera con el dispositivo del usuario, otros dispositivos, la red, la API o el servicio, otras aplicaciones del dispositivo, los servicios de Google o la red de un operador autorizado. Esto abarca diversos comportamientos perjudiciales, de alto riesgo o dañinos, como instalar actualizaciones fuera de Play Store, descargar código ejecutable no autorizado, aprovechar vulnerabilidades de seguridad, facilitar el hacking o crear engaños en el juego que afecten a otras aplicaciones. Proteger la integridad del dispositivo del usuario y el ecosistema general es fundamental. Revisa la política completa para garantizar su cumplimiento.
No admitimos aplicaciones que interfieran de forma no autorizada en el dispositivo del usuario ni con otros dispositivos u ordenadores, servidores, redes, interfaces de programación de aplicaciones (API) o servicios (como otras aplicaciones del dispositivo, cualquier servicio de Google o la red de un operador autorizado). Tampoco se admitirán aplicaciones que interrumpan o dañen los elementos anteriormente citados ni que accedan a los mismos de forma no autorizada.
Las aplicaciones de Google Play deben cumplir los requisitos predeterminados de optimización del sistema Android que se indican en las directrices de calidad básica de las aplicaciones para Google Play.
Una aplicación distribuida a través de Google Play no debe modificarse, reemplazarse ni actualizarse automáticamente con ningún método que no sea el mecanismo de actualización de Google Play. Del mismo modo, una aplicación no debe descargar código ejecutable (por ejemplo, archivos dex, JAR o .so) de ninguna fuente que no sea Google Play. Esta restricción no se aplica al código que se ejecuta en máquinas virtuales o intérpretes cuando cualquiera de ellos permite acceder indirectamente a APIs de Android (como JavaScript en WebView o en un navegador).
Las aplicaciones o el código de terceros (por ejemplo, SDKs) con lenguajes interpretados (JavaScript, Python, Lua, etc.) cargados en el momento de la ejecución (por ejemplo, no incluidos en el paquete de la aplicación) no deben permitir posibles infracciones de las políticas de Google Play.
No admitimos código que introduzca o aproveche vulnerabilidades de seguridad. Consulta el Programa de Mejora de la Seguridad de las Aplicaciones para obtener información sobre los problemas de seguridad más recientes de los que se haya informado a los desarrolladores.
Ejemplos de infracciones habituales relacionadas con el abuso de dispositivos y redes:
- Aplicaciones que bloqueen otra aplicación o interfieran en ella publicando anuncios.
- Aplicaciones para hacer trampas en juegos que afecten a las partidas de otras aplicaciones.
- Aplicaciones que faciliten o den instrucciones sobre cómo hackear servicios, software o hardware, o eludir medidas de seguridad.
- Aplicaciones que usen o accedan a un servicio o a una API de un modo que infrinja los términos del servicio de ese servicio o API.
- Aplicaciones que no cumplan los requisitos para ser incluidas en la lista de permitidas e intenten eludir la gestión de energía del sistema.
- Aplicaciones que faciliten servicios de proxy a terceros (solo pueden hacerlo cuando sea el objetivo principal de la aplicación para los usuarios).
- Aplicaciones o código de terceros (por ejemplo, SDKs) que descarguen código ejecutable, como archivos dex o código nativo, de una fuente que no sea Google Play.
- Aplicaciones que instalen otras aplicaciones en un dispositivo sin el consentimiento previo del usuario.
- Aplicaciones que contengan enlaces a software malicioso o que faciliten su distribución o su instalación.
- Aplicaciones o código de terceros (por ejemplo, archivos SDK) que contengan un elemento WebView, el cual, a su vez, tenga la interfaz JavaScript añadida y cargue contenido web que no sea de confianza (por ejemplo, una URL de http://) o URLs no verificadas obtenidas de fuentes que no sean de confianza (por ejemplo, URLs obtenidas de intents que no sean de confianza).
- Aplicaciones que usen el permiso de intent de pantalla completa para forzar la interacción del usuario con notificaciones o anuncios invasivos.
- Aplicaciones que eludan las protecciones de entorno aislado de Android para obtener la actividad del usuario o la identidad del usuario desde otras aplicaciones.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Asegurarte de que tu aplicación y cualquier SDK integrado cumplan los requisitos de optimización del sistema Android que se recogen en las directrices de calidad básica de las aplicaciones. | No puedes instalar otras aplicaciones en un dispositivo sin consentimiento explícito del usuario. |
Respetar el ajuste FLAG_SECURE; los contenedores del dispositivo deben respetar REQUIRE_SECURE_ENV. |
No puedes facilitar servicios proxy a terceros, a menos que sea el principal propósito de la aplicación y se muestre como tal a los usuarios. |
| Usar Tareas de transferencia de datos iniciadas por el usuario solo para transferencias de datos de red iniciadas por el usuario durante el tiempo que sea necesario. | No puedes usar en tu aplicación SDKs de terceros que descarguen código ejecutable (como archivos dex o .so) desde fuera de Google Play (excepto en máquinas virtuales o intérpretes). |
| Consultar el programa de mejora de la seguridad de las aplicaciones para obtener información sobre los problemas de seguridad más recientes de los que se haya informado a los desarrolladores. | No puedes eludir la gestión de energía del sistema a menos que cumplas los requisitos. |
| Cumplir la política de servicios en primer plano. | No puedes bloquear otra aplicación que muestre anuncios ni interferir con ella. |
No puedes usar el permiso FULL-SCREEN INTENT para forzar la interacción con notificaciones y anuncios invasivos. |
Uso de servicios en primer plano
La política de permisos del servicio en primer plano asegura la transparencia para los usuarios, la privacidad y el rendimiento óptimo del dispositivo. Para las aplicaciones orientadas a Android 14 o versiones posteriores, debes declarar tipos de servicios en primer plano válidos en el archivo de manifiesto y Play Console, e incluir descripciones, el impacto para el usuario y un vídeo de demostración con el que se justifique su uso basado en acciones perceptibles iniciadas por el usuario. Revisa la política completa para garantizar su cumplimiento.
El permiso de servicio en primer plano nos ayuda a asegurarnos de que los servicios en primer plano que se muestran a los usuarios se usen adecuadamente. En el caso de las aplicaciones orientadas a Android 14 o versiones posteriores, debes especificar un tipo válido de servicio en primer plano para cada servicio en primer plano que se use en tu aplicación. Además, debes declarar el permiso de servicio en primer plano que sea adecuado para ese tipo. Por ejemplo, si el caso práctico de tu aplicación requiere el uso de geolocalización en un mapa, debes declarar el permiso FOREGROUND_SERVICE_LOCATION en el archivo de manifiesto de tu aplicación.
Las aplicaciones solo pueden declarar un permiso de servicio en primer plano si el uso:
- Proporciona una función que beneficie al usuario y sea pertinente considerando la función principal de la aplicación.
- Lo inicia o puede percibirlo el usuario (por ejemplo, el audio al reproducir una canción, el envío de contenido multimedia a otro dispositivo, mostrar al usuario una notificación precisa y clara o la solicitud de un usuario de subir una foto a la nube).
- Puede ser cancelado o detenido por el usuario.
- No puede ser interrumpido ni aplazado por el sistema sin provocar una experiencia de usuario negativa o hacer que la función anunciada al usuario no actúe según lo previsto (por ejemplo, una llamada telefónica debe iniciarse inmediatamente, el sistema no puede aplazarla).
- Solo tiene lugar durante el tiempo necesario para completar la tarea.
Los siguientes casos prácticos de servicio en primer plano están exentos de los criterios anteriores:
- Los tipos de servicios en primer plano systemExempted o shortService.
- El tipo de servicio en primer plano dataSync (solo cuando usa funciones de Play Asset Delivery).
El uso del servicio en primer plano se explica con más detalle aquí.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Ejecutar el FGS solo durante el tiempo necesario para completar la tarea. | No puedes usar el FGS si el gestor del sistema de tu tarea no interfiere en la experiencia de usuario de tu aplicación. Plantéate alternativas como WorkManager. |
| Asegurarte de que el FGS proporcione una función de aplicación núcleo beneficiosa para el usuario, esté iniciado por el usuario y sea visible en notificaciones o perceptible por el usuario (por ejemplo, audio al reproducir una canción). | No puedes declarar tipos de FGS incorrectos o no válidos en el manifiesto de la aplicación. |
| Incluir un formulario de declaración en Play Console si la aplicación se orienta a Android 14+ y describir el caso práctico de cada permiso de los servicios en primer plano (FGS) que se utilice. Asegúrate de seleccionar el tipo de FGS correcto. |
Tareas de transferencia de datos iniciadas por el usuario
Para mantener el control del usuario y evitar la actividad prolongada en segundo plano, Google Play establece unas directrices estrictas que afectan a las aplicaciones que usan la API para trabajos de transferencia de datos iniciados por el usuario. Las transferencias de datos las debe iniciar el usuario directamente, asegurando que la aplicación ejecuta un comando en lugar de iniciar las transferencias de forma independiente. Estas transferencias son exclusivas para las tareas de transferencia de datos de red y solo deben ejecutarse durante el tiempo necesario para completar la acción solicitada. Revisa la política completa para garantizar su cumplimiento.
Las aplicaciones solo pueden usar la API de tareas de transferencia de datos iniciadas por el usuario si el uso:
- lo inicia el usuario
- es para tareas de transferencia de datos de red
- solo tiene lugar durante el tiempo necesario para completar la transferencia de datos
El uso de las APIs de transferencia de datos iniciadas por el usuario se explica con más detalle aquí.
Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
| Inicia las transferencias con una acción del usuario. | No inicies las transferencias automáticamente. |
| Úsala solo para las tareas de transferencia de datos de red. | No uses la API para las tareas que no sean de red. |
| Detenla cuando termine la transferencia. | No la ejecutes más tiempo del necesario. |
Requisitos de Flag Secure
FLAG_SECURE es una marca de visualización declarada en una aplicación que indica que su interfaz de usuario contiene datos sensibles que deben limitarse a superficies seguras, por lo que se evitan las capturas de pantalla y la visualización en pantallas no seguras. Los desarrolladores usan esta marca cuando el contenido no debería emitirse o visualizarse fuera de la aplicación o el dispositivo. Por motivos de seguridad y privacidad, Google Play requiere que todas las aplicaciones respeten las declaraciones FLAG_SECURE de otras aplicaciones y no las eviten. Revisa la política completa para garantizar su cumplimiento.
FLAG_SECURE es una marca de visualización declarada en el código de una aplicación que indica que su interfaz de usuario contiene datos sensibles que deben limitarse a una superficie segura mientras se usa la aplicación. Esta marca se ha diseñado para evitar que los datos aparezcan en capturas de pantalla o que se visualicen en pantallas no seguras. Los desarrolladores declaran esta marca si el contenido de la aplicación no debe difundirse, visualizarse ni transmitirse de cualquier otra forma fuera de la aplicación o del dispositivo del usuario.
Para fines de seguridad y privacidad, todas las aplicaciones distribuidas en Google Play deben respetar la declaración FLAG_SECURE de otras aplicaciones. Esto quiere decir que las aplicaciones no deben facilitar ni ofrecer alternativas para eludir la configuración de FLAG_SECURE en otras aplicaciones.
Las aplicaciones que puedan considerarse herramientas de accesibilidad están exentas de este requisito siempre y cuando no transmitan, guarden ni almacenen en caché contenido protegido mediante FLAG_SECURE frente al acceso desde fuera del dispositivo del usuario. Aspectos clave que se deben tener en cuenta
| Qué debes hacer | Qué no debes hacer |
Declara FLAG_SECURE para evitar que se puedan hacer capturas de los datos sensibles de la interfaz. |
No eludas ni ofrezcas alternativas a los ajustes de |
Por motivos de seguridad y privacidad, respeta las declaraciones de FLAG_SECURE de otras aplicaciones. |
No transmitas, guardes ni almacenes en caché contenido protegido por FLAG_SECURE fuera del dispositivo, aunque sea para una herramienta de accesibilidad. |
Aplicaciones que ejecutan contenedores Android en el dispositivo
Para evitar problemas de seguridad y privacidad, los desarrolladores pueden usar la marca `REQUIRE_SECURE_ENV` en el manifiesto de su aplicación cuando las aplicaciones de contenedor Android en el dispositivo no tengan todas las funciones de seguridad del SO Android. Esta marca indica que la aplicación no debería ejecutarse en un entorno simulado. Las aplicaciones que ofrezcan estos contenedores deben respetar esta marca y no ejecutar aplicaciones que lo declaren. Además, tienen prohibido sortear esta medida de seguridad. Revisa la política completa para garantizar su cumplimiento.
Las aplicaciones contenedor Android en el dispositivo proporcionan entornos que simulan la totalidad o partes de un SO Android subyacente. La experiencia dentro de esos entornos puede no reflejar la solución completa de funciones de seguridad de Android, por lo que los desarrolladores pueden añadir una marca de archivo de manifiesto de entorno seguro para comunicarles a los contenedores Android en el dispositivo que no deben operar en su entorno Android simulado.
Marca de entorno seguro en el archivo de manifiesto
- Revisar los archivos de manifiesto de aplicaciones que quieran cargar en su contenedor Android en el dispositivo para esta marca.
- No cargar las aplicaciones que declaren esta marca en su contenedor Android en el dispositivo.
- No funcionar como un proxy interceptando o llamando a APIs en el dispositivo para que parezca que están instaladas en el contenedor.
- No facilitar ni crear alternativas para eludir la marca (como cargar una versión antigua de una aplicación para evitar la marca REQUIRE_SECURE_ENV de la aplicación actual).
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
Las aplicaciones que proporcionan contenedores en el dispositivo deben comprobar si la marca REQUIRE_SECURE_ENV está en los manifiestos de las otras aplicaciones y no cargarlas. |
No puedes ignorar la marca. No puedes cargar una aplicación en tu contenedor si declara la marca REQUIRE_SECURE_ENV. |
| Evita las alternativas. Tienes prohibido sortear la marca, por ejemplo, cargando versiones anteriores de una aplicación. | No puedes eludir las medidas de seguridad. No crees alternativas para anular la preferencia de seguridad de una aplicación. |
| No uses proxies en las APIs. Las aplicaciones no pueden funcionar como un proxy interceptando o llamando a APIs externas al contenedor. | No puedes simular que las aplicaciones se ejecutan en un entorno seguro si esto no es así. |
| Consulta los requisitos de la política para contenedores Android en el dispositivo. |