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.
Para mantener un ecosistema seguro de Android, Google Play prohíbe el código malicioso, incluidos los SDKs externos integrados en las aplicaciones, que pueda poner a los usuarios, a sus datos o a sus dispositivos en riesgo. Revisa la política completa para garantizar su cumplimiento.
El malware es un código que puede poner en riesgo la seguridad de un usuario, de sus datos o sus dispositivos. El malware incluye, entre otras amenazas, aplicaciones potencialmente dañinas, binarios y modificaciones de framework. Dichos elementos se clasifican en categorías (como troyanos, phishing y software espía) que actualizamos y ampliamos constantemente.
Aunque el malware incluye muchos tipos y funciones diferentes, suele tener uno de los siguientes objetivos:
- Comprometer la integridad del dispositivo del usuario.
- Obtener el control del dispositivo del usuario.
- Permitir operaciones controladas de forma remota de un atacante para acceder, usar o explotar de alguna otra forma el dispositivo infectado.
- Transmitir credenciales o datos personales desde el dispositivo sin informar adecuadamente al usuario y sin su consentimiento.
- Difundir spam o comandos desde el dispositivo infectado para afectar a otros dispositivos o redes.
- Defraudar al usuario.
Las aplicaciones, los binarios y las modificaciones de framework pueden ser potencialmente dañinas y, por tanto, pueden generar comportamientos maliciosos aunque sea de forma no intencionada. El motivo es que las aplicaciones, los binarios o las modificaciones de framework pueden funcionar de forma diferente dependiendo de diversas variables. Por lo tanto, lo que es dañino para un dispositivo Android podría no representar ningún riesgo para otro. Por ejemplo, los dispositivos que usan la última versión de Android no se ven afectados por aplicaciones dañinas que usan API obsoletas para realizar acciones maliciosas, pero los dispositivos que aún usen versiones anteriores de Android sí podrían ser vulnerables a estas amenazas. Las aplicaciones, códigos binarios o modificaciones de framework se marcan como malware o aplicaciones potencialmente dañinas si representan una amenaza clara para algunos o para todos los usuarios de Android y sus dispositivos.
Las categorías de malware indicadas más abajo reflejan nuestro convencimiento de que los usuarios deben conocer el uso que hacen las aplicaciones de sus dispositivos, y tienen como objetivo promover un ecosistema seguro que ofrezca tanto una base sólida para la innovación como una experiencia segura para los usuarios.
Puedes consultar más información en Google Play Protect.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Revisa a fondo todo el código de tu aplicación (incluidos los SDKs de terceros) para asegurarte de que no muestre comportamientos similares a los del malware, como software espía, troyanos o phishing, aunque sea de forma involuntaria. | Integrar código que abuse de los privilegios avanzados para poner en peligro la integridad del sistema, rootee dispositivos sin el consentimiento y el conocimiento explícitos del usuario o emplee técnicas de maskware para evitar la detección de comportamientos maliciosos. |
| Considera la posibilidad de usar herramientas para comprobar si hay vulnerabilidades de seguridad o puertas traseras que permitan realizar operaciones remotas no deseadas. | Usar SDKs de terceros que recojan y transmitan datos personales para monitorizar a los usuarios sin informarles adecuadamente y sin obtener su consentimiento (por ejemplo, stalkerware). Incorporar código que provoque prácticas de facturación engañosas relacionadas con SMS, llamadas o fraude de servicios telefónicos. |
| Asegúrate de que los SDKs de terceros no recojan ni filtren datos de usuario sin una funcionalidad que cumpla las políticas o sin el aviso o el consentimiento pertinentes (software espía). | Usar SDKs de terceros que realicen ataques de denegación de servicio o que actúen como software de descarga hostil. |
| Asegúrate de que tu aplicación no incluya SDKs de terceros que infrinjan el modelo de permisos de Android al obtener privilegios avanzados mediante el acceso a los datos del dispositivo para un fin no especificado. |
Puertas traseras
Para proteger a tus usuarios, debes eliminar cualquier código que actúe como puerta trasera, es decir, todo código que facilite operaciones no deseadas o dañinas controladas de forma remota. Revisa la política completa para garantizar su cumplimiento.
Código que permite la ejecución en un dispositivo de operaciones no deseadas, potencialmente dañinas y controladas de forma remota.
Estas operaciones pueden incluir comportamientos que harían que la aplicación, el binario o la modificación de framework se incluyeran en una de las categorías de malware si se ejecutaran automáticamente. En general, el término "puerta trasera" hace referencia a operaciones potencialmente dañinas que se pueden ejecutar en un dispositivo y, por tanto, no se corresponde completamente con categorías como el fraude de facturación o el software espía comercial. Como resultado, en algunos casos, Google Play Protect trata a un subgrupo de aplicaciones de puerta trasera como una vulnerabilidad.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Prueba a fondo el código de tu aplicación y todas las bibliotecas de terceros para detectar funciones de control remoto ocultas. | No incluyas funciones ni capacidades ocultas que se puedan aprovechar para dañar a los usuarios. |
| Protege todos los endpoints de ejecución remota contra accesos no autorizados. | No ofusques el código para ocultar la función de acceso remoto. |
| Aplica parches a las vulnerabilidades de seguridad conocidas de tu aplicación inmediatamente. | No ignores las advertencias sobre posibles vulnerabilidades en tus dependencias. |
Fraude de facturación
Para evitar los fraudes de facturación, debes eliminar cualquier código que cobre a los usuarios de forma engañosa sin su consentimiento explícito. Esto incluye el fraude de SMS, el fraude de llamadas premium y el fraude de servicios telefónicos, que engañan a los usuarios para que realicen pagos o se suscriban a servicios no deseados. Revisa la política completa para garantizar su cumplimiento.
Código que cobra automáticamente al usuario de una forma intencionadamente engañosa.
El fraude de cobro móvil se divide en tres categorías: de SMS, de llamadas premium y de servicios telefónicos.
Fraude por SMS
Código que cobra a los usuarios por enviar SMS de tarificación especial sin su consentimiento, o que intenta encubrir sus actividades de SMS al ocultar los acuerdos de confidencialidad o los mensajes SMS del operador móvil, al notificar al usuario sobre cargos o al confirmar suscripciones.
Algunos códigos, aunque técnicamente revelan el envío de los SMS, introducen un comportamiento adicional que permite realizar el fraude de SMS. Por ejemplo, ocultan al usuario partes de un acuerdo de confidencialidad, hacen que estos resulten ininteligibles o suprimen condicionalmente los mensajes SMS del operador móvil que informan al usuario sobre cargos o confirman suscripciones.
Fraude por llamada
Código que cobra a los usuarios haciendo llamadas a números de tarificación especial sin su consentimiento.
Fraude por tarificación
Código que engaña a los usuarios adquiriendo contenido o suscribiéndoles a servicios a través de la factura de sus teléfonos móviles.
Los fraudes de servicios telefónicos incluyen cualquier tipo de facturación, excepto la de los SMS premium y las llamadas premium. Algunos ejemplos de este fraude son la facturación directa del operador, el protocolo de aplicaciones inalámbricas (WAP) y las transferencias de tiempo de conexión móvil. Los fraudes de WAP son uno de los fraudes de servicios telefónicos más comunes. Este tipo de fraudes incluye engañar a los usuarios para que hagan clic en un botón en un WebView transparente cargado de forma silenciosa. Una vez realizada esta acción, se inicia una suscripción periódica, y el SMS o el correo de confirmación se suele hackear para impedir que los usuarios se den cuenta de la transacción financiera.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Obtén el consentimiento explícito e inequívoco de los usuarios antes de iniciar cualquier transacción financiera. | No ocultes ni disimules ninguna información relacionada con cargos o suscripciones. |
| Asegúrate de que toda la información sobre facturación sea clara, transparente y visible en un lugar destacado para el usuario. | No utilices vistas web ocultas, ni tampoco envíes automáticamente mensajes SMS premium ni hagas llamadas sin consentimiento. |
| Envía todas las notificaciones de facturación del operador al usuario. | No utilices métodos como la facturación directa del operador para engañar a los usuarios y conseguir que se suscriban. |
Stalkerware
Resumen de la política
Google Play prohíbe que las aplicaciones monitoricen a otra persona mediante la recogida y la transmisión de datos personales y sensibles del usuario, a menos que la aplicación se haya diseñado y promocionado exclusivamente para que los padres monitoricen a sus hijos o la dirección de una empresa monitorice a empleados concretos, siempre que cumplan todos los requisitos estrictos. Revisa la política completa para garantizar su cumplimiento.
Se trata de un código que recopila datos personales o sensibles del usuario desde un dispositivo y los transmite a un tercero (empresa o persona física) para su monitorización.
Las aplicaciones deben mostrar un aviso destacado adecuado y recabar el consentimiento de los usuarios conforme a la Política de Datos de Usuario.
Directrices de monitorización de aplicaciones
Las aplicaciones diseñadas y promocionadas exclusivamente para monitorizar a otro individuo, por ejemplo, padres que quieren monitorizar a sus hijos, o en el ámbito de la gestión de empresas, para monitorizar a empleados concretos, siempre que cumplan todos los requisitos que se detallan a continuación, son las únicas aplicaciones de monitorización aceptables. Estas aplicaciones no se pueden utilizar para consultar la ubicación de otras personas (la pareja del usuario, por ejemplo) incluso con su conocimiento y permiso, independientemente de si se muestra una notificación permanente. Estas aplicaciones deben usar la marca de metadatos IsMonitoringTool en su archivo de manifiesto para calificarse adecuadamente a sí mismas como aplicaciones de monitorización.
Las aplicaciones de monitorización deben cumplir los siguientes requisitos:
- Las aplicaciones no se deben presentar como soluciones de espionaje o vigilancia secreta.
- Las aplicaciones no deben ocultar o encubrir el seguimiento ni intentar engañar a los usuarios sobre estas funciones.
- Las aplicaciones deben exhibir una notificación permanente a los usuarios en todo momento mientras estén en funcionamiento y mostrar un icono distintivo que permita identificar claramente la aplicación.
- Las aplicaciones deben avisar de la función de monitorización o rastreo en la descripción de Google Play Store.
- Las aplicaciones y sus fichas de Google Play no deben proporcionar medios para activar o acceder a funciones que infrinjan estos términos, como enlazar a un APK que no cumpla los requisitos y que esté alojado fuera de Google Play.
- Las aplicaciones deben respetar todas las leyes aplicables. Eres el único responsable de determinar la legalidad de tu aplicación en el mercado de destino.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Promociona tu aplicación exclusivamente para que la usen padres o equipos administrativos de empresas. | No comercialices la aplicación como una solución de espionaje o vigilancia. |
Incluye la marca IsMonitoringTool en tu archivo de manifiesto. |
No monitorices a otros adultos, como por ejemplo cónyuges, ni siquiera con su permiso. |
| Muestra una notificación permanente y un icono único cuando se esté ejecutando. | No ocultes o encubras el comportamiento del seguimiento ni engañes a los usuarios sobre este comportamiento. |
| Informa de todas las funciones de monitorización en la descripción de tu aplicación en Google Play. | No enlaces a APKs que no cumplan los requisitos y que estén alojados fuera de Google Play. |
| Muestra un aviso destacado adecuado y obtén el consentimiento de los usuarios. | No proporciones medios para activar funciones que infrinjan estos términos. |
Denegación de servicio (DoS)
Para proteger tu aplicación y otros sistemas, debes eliminar cualquier código que, sin el conocimiento del usuario, ataque otros sistemas o genere una carga de red excesiva. Revisa la política completa para garantizar su cumplimiento.
Código que, sin el conocimiento del usuario, ejecuta un ataque de denegación de servicio (DoS) o forma parte de un ataque DoS distribuido contra otros sistemas y recursos.
Por ejemplo, esto puede ocurrir cuando se envía un volumen elevado de solicitudes HTTP para producir una carga excesiva en servidores remotos.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Prueba a fondo tu código y los SDKs de terceros para detectar abusos de la red. | No ocultes ni insertes código que genere un gran volumen de tráfico o solicitudes de red. |
| Asegúrate de que todas las solicitudes de red de tu aplicación sean legítimas y necesarias para sus funciones. | No incluyas funciones que se puedan activar de forma remota para atacar sistemas externos. |
Software de descarga hostil
Google Play prohíbe el "software de descarga hostil", es decir, las aplicaciones que descargan otro software no deseado para móviles (MUwS). Una aplicación se marca como software de descarga hostil si se cree que se ha diseñado para difundir MUwS o si se determina que al menos el 5 % de sus descargas son de este tipo. Esta política no se aplica a los principales navegadores o aplicaciones para compartir archivos, siempre que solo descarguen software cuando el usuario inicie la acción y dé su consentimiento explícito. Revisa la política completa para garantizar su cumplimiento.
Código que no es potencialmente dañino en sí mismo, pero que descarga otras aplicaciones potencialmente dañinas.
El código puede considerarse software de descarga hostil si:
- Hay motivos para creer que se creó para difundir aplicaciones potencialmente dañinas y que ha descargado aplicaciones de este tipo, o contiene código que podría descargar e instalar aplicaciones.
- Al menos el 5 % de las aplicaciones descargadas por este tipo de código son potencialmente dañinas, con un umbral mínimo de 500 aplicaciones descargadas (de las cuales 25 son potencialmente dañinas).
Los principales navegadores y aplicaciones que comparten archivos no se consideran software hostil siempre que:
- No inicien las descargas sin la interacción del usuario.
- Todas las descargas de aplicaciones potencialmente dañinas se inicien con el consentimiento de los usuarios.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Asegúrate de que tu aplicación no incluya código que propague MUwS. | No incluyas en tu aplicación ningún código que propague MUwS. |
| Monitoriza las descargas para mantenerte muy por debajo del umbral del 5 % de MUwS. | No superes el umbral del 5 % de MUwS (25 MUwS por cada 500 descargas). |
| Si tu aplicación tiene como objetivo descargar otros archivos (como un navegador o un sistema de archivos compartidos), asegúrate de que todas las descargas de la aplicación se inicien con el consentimiento de los usuarios. | Si tu aplicación tiene como objetivo descargar otros archivos (por ejemplo, un navegador o un sistema de archivos compartidos), no incluyas funciones que fomenten las descargas de la aplicación sin la interacción explícita del usuario. |
Amenaza no relacionada con Android
Código que contiene amenazas no relacionadas con Android.
Estas aplicaciones no pueden causar daños a los usuarios de Android ni a sus dispositivos, pero incluyen componentes que pueden ser dañinos para otras plataformas.
Suplantación de identidad (phishing)
Debes eliminar todo código que participe en actividades de phishing solicitando de forma engañosa las credenciales o la información de facturación de un usuario y enviándolas a un tercero. Revisa la política completa para garantizar su cumplimiento.
Código que finge provenir de una fuente de confianza, solicita las credenciales de autenticación o los datos de facturación del usuario y, a continuación, envía esa información a un tercero. Esta categoría también se aplica al código que intercepta las credenciales de los usuarios durante su transmisión.
Entre los objetivos del phishing, se incluyen credenciales bancarias y números de tarjetas de crédito, así como credenciales de cuentas online de redes sociales y juegos.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Usa APIs oficiales y métodos seguros para gestionar las credenciales de los usuarios y la información para pagos. | No te hagas pasar por una fuente de confianza para engañar a los usuarios y conseguir que proporcionen datos personales o financieros. |
| Asegúrate de que todos los datos de usuario se transmitan de forma segura y que no puedan ser leídos por terceros. | No interceptes ni recojas credenciales de usuario ni información sensible sin consentimiento. |
| Sé transparente con los usuarios sobre los datos que solicitas y por qué. | No envíes información sensible de los usuarios a terceros sin haber informado debidamente a los usuarios y sin haber obtenido su consentimiento explícito. |
Abuso de privilegios
Para evitar infracciones relacionadas con el abuso de privilegios avanzados, tu aplicación no debe contener código que obtenga privilegios avanzados o que vulnere el entorno aislado de seguridad de Android. Esto incluye código que robe credenciales de otras aplicaciones, eluda el modelo de permisos de Android o inhabilite funciones de seguridad básicas. Tu aplicación también debe respetar el control que tienen los usuarios sobre sus dispositivos. Revisa la política completa para garantizar su cumplimiento.
Código que pone en peligro la integridad del sistema accediendo sin autorización a la zona de pruebas de la aplicación, obteniendo privilegios avanzados, o bien cambiando o inhabilitando el acceso a funciones básicas de seguridad.
A continuación se incluyen algunos ejemplos:
- Aplicaciones que infringen el modelo de permisos de Android o roban credenciales (como los tokens de OAuth) de otras aplicaciones
- Aplicaciones que abusan de funciones para impedir que se puedan desinstalar o detener
- Aplicaciones que inhabilitan SELinux
Las aplicaciones que se apropian de privilegios y rootean dispositivos sin el permiso de los usuarios se conocen como aplicaciones de rooteado.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Desarrolla código que respete el modelo de permisos de Android. | No crees aplicaciones que pongan en riesgo el sistema vulnerando el entorno aislado de la aplicación. |
| Diseña tu aplicación para que funcione con los privilegios de usuario estándar. | No programes código que impida que un usuario desinstale una aplicación. |
Ransomware
Resumen de la política
El ransomware es un software malicioso que toma como rehén el dispositivo o los datos de un usuario y exige un pago o una acción para restablecer el control. No debes impedir el acceso a los usuarios, cifrar datos ni evitar la desinstalación. Esta política protege a los usuarios frente a la extorsión. Revisa la política completa para garantizar su cumplimiento.
Código que toma el control de forma parcial o general de un dispositivo o de sus datos, tras lo que exige al usuario que haga un pago o realice una acción para recuperar el control sobre ellos.
Algunos programas de ransomware encriptan los datos del dispositivo y exigen un pago para desencriptarlos, y utilizan las funciones administrativas del dispositivo para que los usuarios ordinarios no puedan eliminarlos. A continuación se incluyen algunos ejemplos:
- Bloquear el acceso de un usuario a su dispositivo y exigirle dinero para que recupere el control.
- Encriptar los datos de un dispositivo y exigir un pago (presumiblemente para desencriptarlos).
- Impedir que el usuario pueda eliminar el código utilizando las funciones del administrador de políticas del dispositivo.
Es posible que los códigos distribuidos con el dispositivo cuya finalidad principal sea la gestión de dispositivos subvencionados se excluyan de la categoría de ransomware, siempre que cumplan los requisitos de gestión y bloqueo de seguridad, así como los de informar al usuario y obtener su consentimiento.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Asegúrate de que el código de tu aplicación no incluya ninguna función de ransomware maliciosa. | No cifres los datos de los usuarios ni les impidas acceder a sus dispositivos. |
| Obtén el consentimiento explícito de los usuarios para usar cualquier función de gestión de dispositivos. | No utilices funciones de administrador de dispositivos para bloquear la desinstalación. |
| Proporciona a los usuarios una forma clara y sencilla de eliminar tu aplicación. | No exijas un pago o una acción para restablecer el control del dispositivo. |
Rooteo
Resumen de la política
Google Play permite el rooteo no malicioso, pero prohíbe el código de rooteo malicioso. Debes informar a los usuarios con antelación sobre el rooteo y asegurarte de que tu aplicación no realice ninguna otra acción dañina. El objetivo es asegurarse de que los usuarios den su consentimiento a un cambio tan significativo en el dispositivo y no se vean expuestos a comportamientos maliciosos adicionales. Revisa la política completa para garantizar su cumplimiento.
Código que rootea el dispositivo.
Hay una diferencia entre el código de rooteo no malicioso y el malicioso. Por ejemplo, las aplicaciones de rooteo no maliciosas avisan al usuario con antelación de que van a rootear el dispositivo y no ejecutan otras acciones propias de las aplicaciones potencialmente dañinas.
Las aplicaciones de rooteo maliciosas no informan al usuario de que van a rootear el dispositivo, o le informan del rooteo con antelación, pero también ejecutan otras acciones propias de las aplicaciones potencialmente dañinas.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Informa a los usuarios con antelación de que tu aplicación va a rootear el dispositivo. | No rootees un dispositivo sin informar al usuario. |
| Obtén el consentimiento explícito del usuario antes de rootear el dispositivo. | No realices otras acciones dañinas en una aplicación de rooteo. |
| Confirma que el código de tu aplicación no tenga ningún otro comportamiento malicioso. | No utilices código de rooteo para ocultar otras funciones maliciosas. |
Spam
Software espía
Google Play prohíbe la recogida o el intercambio maliciosos de datos de usuario o dispositivos. Independientemente del consentimiento o aviso del usuario, la recogida y el intercambio de datos deben estar relacionados con una funcionalidad que cumpla las políticas. Revisa la política completa para garantizar su cumplimiento.
Un software espía es cualquier aplicación, código o comportamiento malicioso que recoge, filtra o comparte datos del usuario o del dispositivo que no están relacionados con una función que cumple las políticas.
También se considera software espía el código o comportamiento malicioso que puede interpretarse que espía al usuario o filtra datos sin la debida notificación o consentimiento.
Por ejemplo, las infracciones de software espía incluyen, entre otras, las siguientes:
- Grabar audio o llamadas realizadas con el teléfono
- Robar datos de aplicaciones
- Una aplicación con código malicioso de terceros (por ejemplo, un SDK) que transmite datos fuera del dispositivo de una manera inesperada para el usuario o sin la debida notificación o consentimiento del usuario.
Todas las aplicaciones deben cumplir las Políticas del Programa para Desarrolladores de Google Play, incluidas las políticas de datos de usuario y de dispositivo, como las políticas de software no deseado para móviles, datos de usuario, permisos y APIs que acceden a información sensible y requisitos de SDKs.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Proporciona un aviso claro y obtén el consentimiento explícito de los usuarios antes de recoger o transmitir datos. | No permitas que los SDKs de terceros de tu aplicación graben audio o llamadas, u obtengan datos de la aplicación sin el consentimiento explícito del usuario y sin una función que cumpla las políticas. |
| Implementa una experiencia sólida de registro y auditoría para todo el acceso a datos y la transmisión de datos de SDKs de terceros con el objetivo de detectar y abordar las filtraciones externas de datos no autorizadas. | No recojas datos de forma oculta ni recojas más datos de los que la aplicación necesita para su función declarada. |
| Asegúrate de que los SDKs integrados en tu aplicación solo recojan los datos mínimos necesarios y de que su finalidad o comportamiento no provoquen que tu aplicación infrinja las políticas de Google Play. | No incluyas SDKs de terceros en tu aplicación que transmitan datos de formas inesperadas o sin el consentimiento adecuado. |
| No asumas que los SDKs de terceros incluidos en las prácticas de recogida de datos de tu aplicación cumplen las políticas sin revisarlos a fondo. |
Troyano
Resumen de la política
Un troyano es un código que contiene un componente oculto y malicioso. Esta política prohíbe las aplicaciones que realizan acciones no deseadas contra el usuario sin su conocimiento. Como desarrollador, debes asegurarte de que el código de tu aplicación sea transparente y no incluya funciones ocultas ni dañinas. Revisa la política completa para garantizar su cumplimiento.
Código que parece inofensivo, como un juego del que se asegura que es tan solo un juego, pero que ejecuta acciones no deseadas y perjudiciales para el usuario.
Esta clasificación se suele utilizar en combinación con otras categorías de aplicaciones potencialmente dañinas. Un troyano tiene un componente inofensivo y otro dañino. Por ejemplo, un juego que envía mensajes SMS premium desde el dispositivo del usuario en segundo plano y sin el conocimiento del usuario.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Asegúrate de que el código de tu aplicación sea transparente y cumpla el propósito declarado. | No ocultes funciones maliciosas en una aplicación aparentemente inofensiva. |
| Confirma que se ha informado al usuario de toda la funcionalidad de la aplicación. | No realices acciones en segundo plano sin el conocimiento y el consentimiento explícitos del usuario. |
| Asegúrate de que los SDKs de terceros que incluyas sean seguros y no contengan comportamientos ocultos. | No proporciones información engañosa sobre el propósito de tu aplicación para engañar a los usuarios. |
Una nota sobre aplicaciones poco comunes
Resumen de la política
Si Google Play Protect no tiene suficiente información para verificar la seguridad de tu nueva aplicación, puede que se clasifique como "poco común". Este estado no significa que tu aplicación sea dañina, sino que necesita una revisión más exhaustiva. Revisa la política completa para garantizar su cumplimiento.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Proporciona información completa y precisa en la ficha de tu aplicación. | No ocultes funciones ni utilices código ofuscado. |
| Asegúrate de que el código de tu aplicación sea claro y esté bien documentado para que se pueda revisar. | No utilices bibliotecas de terceros no verificadas. |
Una nota sobre la categoría de puerta trasera
Resumen de la política
Una puerta trasera es un código que permite un comportamiento malicioso. El uso de la carga dinámica de código para realizar acciones dañinas se considerará una infracción por parte de tu aplicación. Debes asegurarte de que el código de tu aplicación no habilite ninguna función oculta ni maliciosa. Si se detecta una vulnerabilidad sin intención maliciosa, se te pedirá que la corrijas. Revisa la política completa para garantizar su cumplimiento.
La clasificación de la categoría de malware de puerta trasera depende de cómo actúe el código. Una condición necesaria para que un código se clasifique como malware trasera es que permita un comportamiento que lo incluiría en una de las categorías de malware si se ejecutara automáticamente. Por ejemplo, si una aplicación permite la carga dinámica de código, y el código cargado dinámicamente extrae mensajes de texto, se clasificará como malware de puerta trasera.
Sin embargo, si una aplicación permite la ejecución de código arbitrario y no tenemos ningún motivo para creer que la ejecución de ese código se añadió con un objetivo malicioso, la aplicación no se tratará como un malware de puerta trasera, sino como una aplicación que tiene una vulnerabilidad, y se pedirá al desarrollador que le aplique un parche.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Prueba rigurosamente cualquier código que permita la ejecución dinámica. | No utilices la carga dinámica de código para realizar acciones ocultas o maliciosas. |
| Asegúrate de que el código de tu aplicación no tenga vulnerabilidades que se puedan aprovechar. | No permitas la ejecución de código arbitrario sin realizar comprobaciones de seguridad exhaustivas. |
| Aplica parches rápidamente a las vulnerabilidades de seguridad detectadas en tu aplicación. | No utilices bibliotecas de terceros no verificadas que puedan habilitar una puerta trasera. |
Riskware
Resumen de la política
El riskware es una aplicación que usa técnicas de evasión para ocultar funciones maliciosas. Se hace pasar por una aplicación legítima y usa métodos como la ofuscación o la carga dinámica de código para mostrar contenido dañino más adelante. Debes asegurarte de que tu aplicación sea transparente y no utilice estas técnicas para engañar a los revisores o a los usuarios. Revisa la política completa para garantizar su cumplimiento.
Una aplicación que utiliza varias técnicas de evasión para ofrecer al usuario funciones de la aplicación diferentes o falsas. Estas aplicaciones se enmascaran como aplicaciones o juegos legítimos para parecer inofensivos en las tiendas de aplicaciones y para los usuarios, y usan técnicas como la ofuscación, la carga dinámica de código o el encubrimiento para mostrar contenido potencialmente malicioso.
El riskware es similar a otras categorías de aplicaciones potencialmente dañinas, concretamente a los troyanos, con la diferencia principal en las técnicas que se usan para ofuscar la actividad maliciosa.
Aspectos clave que se deben tener en cuenta
| Prácticas recomendadas | Prácticas prohibidas |
| Asegúrate de que el código de tu aplicación sea claro y fácil de revisar. | No utilices ofuscación ni encubrimiento para ocultar funciones. |
| Sé transparente sobre todas las funciones de tu aplicación. | No utilices la carga dinámica de código para servir contenido malicioso. |
| Incluye todas las funciones en la descripción de la aplicación. | No hagas que tu aplicación tenga un comportamiento diferente con los revisores y con los usuarios normales. |
Help us improve this policy article by taking a 2-minute survey.