Abuso de dispositivos y redes

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 una 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 con la interfaz JavaScript añadida y que 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 anuncios o notificaciones invasivos.

 

Uso de servicios en primer plano 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í.

 

Tareas de transferencia de datos iniciadas por el usuario 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í.

 

Requisitos de Flag Secure 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.

 

Aplicaciones que ejecutan contenedores Android en el dispositivo 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 REQUIRE_SECURE_ENV es una marca que se puede declarar en el archivo de manifiesto de una aplicación para indicar que esa aplicación no se debe ejecutar en aplicaciones contenedor Android en el dispositivo. Con fines de seguridad y privacidad, las aplicaciones que proporcionan contenedores Android en el dispositivo deben respetar todas las aplicaciones que declaren esta marca y: 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). Consulta más información sobre esta política en nuestro Centro de Ayuda.