Aviso importante: Los Resúmenes de las políticas y las Consideraciones Clave 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.
Para mantener el ecosistema de Android seguro, Google Play prohíbe todo tipo de código malicioso que podría poner en riesgo a los usuarios, sus datos o sus dispositivos, incluidos los SDKs de terceros que se integren a las aplicaciones. Revise la política completa para asegurarse de estar en cumplimiento.
Software malicioso es cualquier código que pudiera poner en riesgo a un usuario, sus datos o un dispositivo. Se incluyen, entre otros, Aplicaciones Potencialmente Dañinas (APD), objetos binarios o modificaciones de framework, que a su vez se organizan en categorías como troyanos, suplantación de identidad (phishing) y aplicaciones de software espía. (Actualizamos esta lista de manera continua con nuevas categorías).
Si bien varía en cuanto al tipo y las capacidades, el software malicioso suele tener uno de los siguientes objetivos:
- Comprometer la integridad del dispositivo del usuario
- Obtener control sobre el dispositivo de un usuario
- Habilitar operaciones controladas de manera remota para que el atacante pueda acceder al dispositivo infectado, usarlo o abusar de él de otro modo
- Transmitir datos personales o credenciales fuera del dispositivo sin la notificación y el consentimiento adecuados
- Distribuir spam o comandos desde el dispositivo infectado para afectar a otros dispositivos o redes
- Estafar al usuario
Una aplicación, un objeto binario o una modificación del framework pueden ser potencialmente dañinos y, por lo tanto, generar un comportamiento malicioso, aunque no estén diseñados para causar daño. Esto sucede porque es posible que las aplicaciones, los objetos binarios o las modificaciones del framework funcionen de manera diferente según diversas variables. Por lo tanto, lo que es perjudicial para un dispositivo Android podría no plantear ningún riesgo para otro dispositivo Android. Por ejemplo, un dispositivo que ejecuta la última versión de Android no se ve afectado por apps dañinas que usan API obsoletas para provocar un comportamiento malicioso, pero sí podría estar en riesgo un dispositivo que ejecuta una versión de Android mucho más antigua. Las apps, los objetos binarios y las modificaciones de framework se marcan como software malicioso o APD si claramente plantean un riesgo para todos los dispositivos y usuarios de Android.
Las categorías de software malicioso que se incluyen a continuación reflejan nuestra firme convicción de que los usuarios deben comprender cómo se utilizan sus dispositivos y promover un ecosistema seguro que permita una sólida innovación y una experiencia confiable del usuario.
Para obtener más información, visite Google Play Protect.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Verifique minuciosamente todo el código de su aplicación, incluidos los SDKs de terceros, para asegurarse de que no muestren comportamientos similares a los del malware, como software espía, troyanos o phishing, incluso de forma involuntaria. | No integre código que abuse de privilegios elevados para comprometer la integridad del sistema, no otorgue permisos de administrador a dispositivos sin el conocimiento y el consentimiento explícito del usuario, ni emplee técnicas de maskware para evadir la detección de comportamiento malicioso. |
| Considere la opción de usar herramientas para verificar si hay vulnerabilidades de seguridad o puertas traseras que permitan operaciones remotas no deseadas. | No use SDKs de terceros que recopilen y transmitan datos personales para la supervisión sin la divulgación y el consentimiento adecuados del usuario (es decir, stalkerware). No incorpore código que cause prácticas de facturación engañosas que involucren fraude por SMS, llamadas o cargos telefónicos. |
| Asegúrese de que los SDKs de terceros no recopilen ni exfiltren datos del usuario sin una funcionalidad que satisfaga las políticas o sin el consentimiento o la notificación adecuados (software espía). | No use SDKs de terceros que realicen ataques de Denegación de Servicio o actúen como Aplicaciones de Descarga Hostil. |
| Asegúrese de que su aplicación no incluya SDKs de terceros que infrinjan el modelo de permisos de Android obteniendo privilegios elevados a través del acceso a datos del dispositivo para un propósito no divulgado. |
Puerta trasera
Para proteger a los usuarios, debe quitar cualquier código que actúe como puerta trasera, lo que se define como código que facilita operaciones no deseadas o dañinas controladas de forma remota. Revise la política completa para garantizar su cumplimiento.
Se trata de código que permite que se ejecuten operaciones no deseadas, potencialmente dañinas y controladas de forma remota en un dispositivo.
Estas operaciones incluyen un comportamiento que colocaría a la aplicación, el objeto binario o la modificación del marco de trabajo dentro de una de las otras categorías de software malicioso en caso de que se ejecuten automáticamente. En general, la puerta trasera es una descripción de cómo puede ocurrir una operación potencialmente dañina en un dispositivo y, por lo tanto, no está totalmente alineada con categorías como fraude en la facturación o software espía comercial. Como resultado, en determinadas circunstancias, Google Play Protect trata a un subconjunto de puertas traseras como una vulnerabilidad.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Pruebe a fondo el código de su aplicación y todas las bibliotecas de terceros para detectar si hay funciones ocultas de control remoto. | No incluya funciones ni capacidades ocultas que se puedan explotar para dañar a los usuarios. |
| Proteja todos los endpoints de ejecución remota contra el acceso no autorizado. | No ofusque el código para ocultar la funcionalidad de acceso remoto. |
| Aplique de inmediato parches a las vulnerabilidades de seguridad conocidas en su aplicación. | No ignore las advertencias sobre posibles vulnerabilidades en sus dependencias. |
Fraude en la facturación
Para evitar el fraude de facturación, debe quitar todo código que cobre a los usuarios de forma engañosa sin su consentimiento explícito. Esto incluye el fraude de SMS, el fraude telefónico y el fraude de cargos telefónicos, que engañan a los usuarios para que realicen pagos o se suscriban a servicios no deseados. Revise la política completa para garantizar su cumplimiento.
Se trata de código que procesa un cobro al usuario de manera intencionalmente engañosa.
El fraude en la facturación de telefonía celular se divide en fraude de SMS, fraude telefónico y fraude de cargos telefónicos.
Fraude de SMS
Se trata de código que les cobra a los usuarios por el envío de SMS premium sin su consentimiento o que intenta disimular las actividades de SMS ocultando acuerdos de divulgación o mensajes SMS del operador de telefonía móvil que le notifican al usuario sobre los cargos o confirman las suscripciones.
Parte de este código, si bien técnicamente divulga el comportamiento de envío de SMS, incorpora comportamiento adicional que da lugar al fraude de SMS. Algunos ejemplos incluyen ocultarle al usuario partes de un acuerdo de divulgación, dificultar su lectura y suprimir de forma condicional mensajes SMS del operador de telefonía móvil en los que se le informa al usuario sobre los cargos o se confirma una suscripción.
Fraude telefónico
Se trata de código que genera cobros a los usuarios mediante llamadas a números premium sin su consentimiento.
Fraude de cargos telefónicos
Se trata de código que engaña al usuario para que se suscriba a contenido o lo compre a través de la facturación del operador de telefonía celular.
El fraude de cargos telefónicos incluye cualquier tipo de facturación, excepto las llamadas y los SMS premium. Algunos ejemplos de esto incluyen facturación directa del operador, protocolo de aplicaciones inalámbricas (WAP) y transferencia de crédito de telefonía móvil. El fraude de WAP es el tipo de fraude de cargos telefónicos más predominante. Puede incluir engaño a los usuarios para que hagan clic en un botón de una versión de WebView transparente que se carga de manera silenciosa. Cuando se realiza la acción, se inicia una suscripción recurrente, y suele piratearse el correo electrónico o SMS de confirmación para impedir que los usuarios noten la transacción financiera.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Obtenga el consentimiento explícito y claro de los usuarios antes de iniciar cualquier transacción financiera. | No oculte ni camufle la información relacionada con los cargos o las suscripciones. |
| Asegúrese de que todas las divulgaciones de facturación sean claras y transparentes, y se muestren de forma destacada al usuario. | No use vistas web ocultas y no envíe automáticamente mensajes SMS premium ni realice llamadas sin consentimiento. |
| Envíe todas las notificaciones de facturación del operador al usuario. | No use métodos como la facturación directa del operador para engañar a los usuarios con el fin de que se suscriban. |
Stalkerware
Google Play prohíbe que las aplicaciones supervisen a personas físicas recopilando y transmitiendo datos personales y sensibles de los usuarios, a menos que la aplicación esté diseñada y comercializada exclusivamente para que las madres o padres supervisen a sus hijos o hijas, o para que la administración de una empresa supervise a empleados individuales, siempre que satisfaga por completo requisitos estrictos. Revise la política completa para garantizar su cumplimiento.
Código que recopila datos personales o sensibles de los usuarios de un dispositivo y los transmite a un tercero (empresa o persona física) con fines de supervisión.
Las aplicaciones deben proporcionar una divulgación destacada adecuada y obtener el consentimiento según lo exige la política de Datos del Usuario.
Lineamientos para las Aplicaciones de Supervisión
Las aplicaciones diseñadas y comercializadas exclusivamente para supervisar a otra persona, por ejemplo, para que los padres vigilen a sus hijos o los administradores empresariales supervisen a sus empleados, son las únicas aplicaciones de supervisión aceptables, siempre que satisfagan por completo los requisitos que se describen más abajo. Estas aplicaciones no se pueden usar para seguir a nadie más (por ejemplo, un cónyuge), incluso con el conocimiento y permiso de la persona, más allá de si se muestra una notificación persistente. Estas aplicaciones deben usar el parámetro de metadatos IsMonitoringTool en el archivo del manifiesto para designarse correctamente como aplicaciones de supervisión.
Las aplicaciones de supervisión deben satisfacer estos requisitos:
- No deben presentarse como una solución de espionaje ni vigilancia secreta.
- Las aplicaciones no deben ocultar ni encubrir el comportamiento relacionado con el seguimiento, ni intentar engañar a los usuarios sobre esa función.
- Las aplicaciones deben presentarse ante los usuarios con una notificación persistente en todo momento mientras estén en ejecución y deben tener un ícono único que las identifique claramente.
- Las aplicaciones deben divulgar la funcionalidad de supervisión o seguimiento en la descripción de Google Play Store.
- Las aplicaciones y fichas que se muestran en Google Play no deben proporcionar ningún medio para activar o acceder a funcionalidades que incumplan estos términos y condiciones, como vínculos a archivos APK alojados fuera de Google Play que no satisfagan dichos términos.
- Las aplicaciones deben satisfacer todas las leyes aplicables. La responsabilidad de determinar la legalidad de la aplicación en el mercado de destino recae exclusivamente sobre usted.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Comercialice su aplicación exclusivamente para uso de administración empresarial o control parental. | No comercialice la aplicación como una solución de espionaje o vigilancia. |
Incluya la marca IsMonitoringTool en su manifiesto. |
No rastree a otros adultos, incluidos los cónyuges, ni siquiera con su permiso. |
| Muestre una notificación persistente y un ícono único cuando la aplicación se esté ejecutando. | No oculte ni encubra el comportamiento relacionado con el seguimiento, y no engañe a los usuarios acerca de él. |
| Divulgue toda la funcionalidad de supervisión en la descripción de la tienda. | No incluya vínculos a APKs que no satisfagan los requisitos y que estén alojados fuera de Google Play. |
| Proporcione una divulgación destacada adecuada y obtenga el consentimiento. | No proporcione medios para activar la funcionalidad que incumple estas condiciones. |
Denegación del servicio (DoS)
Para proteger su aplicación y otros sistemas, debe quitar todo el código que, sin el conocimiento del usuario, ataque otros sistemas o genere una carga de red excesiva. Revise la política completa para garantizar su cumplimiento.
Se trata de código que, sin el conocimiento del usuario, ejecuta un ataque de denegación del servicio (DoS) o es parte de un ataque de DoS contra otros sistemas y recursos.
Por ejemplo, esto puede ocurrir cuando se envía una gran cantidad de solicitudes HTTP para producir una carga excesiva en servidores remotos.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Pruebe a fondo su código y los SDKs de terceros para detectar abusos de red. | No oculte ni incorpore código que genere un gran volumen de tráfico o solicitudes de red. |
| Asegúrese de que todas las solicitudes de red de su aplicación sean legítimas y necesarias para su funcionalidad. | No incluya funcionalidades que se puedan activar de forma remota para atacar sistemas externos. |
Aplicaciones de descarga hostil
Google Play prohíbe las "aplicaciones de descarga hostil", es decir, aquellas que descargan otro Software No Deseado para Dispositivos Móviles (MUwS). Las aplicaciones se marcan como de descarga hostil si parece que están diseñadas para propagar MUwS o si se determina que al menos el 5% de sus descargas son de MUwS. Esta política no se aplica a los navegadores ni a las aplicaciones de archivos compartidos más importantes, siempre que solo descarguen software con el consentimiento explícito y la iniciación de la acción por parte del usuario. Revise la política completa para garantizar su cumplimiento.
Se trata de código que no es potencialmente dañino en sí, pero que descarga otras APD.
El código puede ser de descarga hostil de contenido si ocurre lo siguiente:
- Hay motivos para creer que se creó con el fin de extender APD y descargó APD o contiene código que podría descargar e instalar aplicaciones.
- Al menos el 5% de las aplicaciones descargadas por este son APD con un umbral mínimo de 500 descargas de aplicaciones observadas (25 descargas de APD observadas).
No se considera que los navegadores ni las aplicaciones de archivos compartidos más significativos sean de descarga hostil siempre que ocurra lo siguiente:
- No activan descargas sin la interacción del usuario.
- Todas las descargas de APD se inician si el usuario da su consentimiento.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Asegúrese de que su aplicación no incluya código que propague MUwS. | No incluya en su aplicación código que propague MUwS. |
| Supervise las descargas para mantenerse muy por debajo del umbral del 5% de MUwS. | No supere el umbral del 5% de MUwS (25 MUwS por cada 500 descargas). |
| Si el propósito de su aplicación es descargar otros archivos (como un navegador o un servicio de uso compartido de archivos), asegúrese de que el usuario que inicie todas las descargas de la aplicación haya otorgado su consentimiento. | No incluya funciones que generen descargas sin la interacción explícita del usuario si el propósito de su aplicación es descargar otros archivos (como un navegador o un servicio de uso compartido de archivos). |
Amenaza no relacionada con Android
Se trata de código que contiene amenazas no relacionadas con Android.
Estas aplicaciones no pueden causar daño a los dispositivos ni usuarios de Android, pero contienen componentes potencialmente dañinos para otras plataformas.
Suplantación de identidad (phishing)
Debe quitar todo código que implique técnicas de phishing que soliciten de forma engañosa las credenciales o información de facturación de los usuarios, y que las envíen a un tercero. Revise la política completa para garantizar su cumplimiento.
Se trata de código que pretende provenir de una fuente confiable, solicita las credenciales de autenticación o los datos de facturación de un usuario y envía la información a un tercero. Esta categoría también se aplica al código que intercepta la transmisión de las credenciales de usuario en tránsito.
La suplantación de identidad (phishing) suele estar orientada a credenciales bancarias, números de tarjetas de crédito y credenciales de cuentas en línea para redes sociales y juegos.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Use APIs oficiales y métodos seguros para controlar las credenciales del usuario y la información de pago. | No se haga pasar por una fuente confiable para engañar a los usuarios con el fin de que proporcionen datos personales o financieros. |
| Asegúrese de que todos los datos del usuario se transmitan de forma segura y que terceros no puedan leerlos. | No intercepte ni recopile credenciales de usuario ni información sensible sin consentimiento. |
| Sea transparente con los usuarios sobre qué datos solicita y por qué. | No envíe información sensible del usuario a un tercero sin la divulgación adecuada al usuario y su consentimiento explícito. |
Abuso de privilegios altos
Para evitar incumplimientos relacionados con el abuso de privilegios elevados, su aplicación no debe contener código que obtenga privilegios elevados ni que trascienda la zona de pruebas de seguridad de Android. Esto incluye código que roba credenciales de otras aplicaciones, elude el modelo de permisos de Android o inhabilita funciones de seguridad básicas. Su aplicación también debe respetar el control del usuario sobre su dispositivo. Revise la política completa para garantizar su cumplimiento.
Se trata de código que compromete la integridad del sistema ya que rompe la zona de prueba de la aplicación, obtiene privilegios altos o cambia o inhabilita el acceso a funciones básicas relacionadas con la seguridad.
Los siguientes son algunos ejemplos:
- Aplicaciones que no cumplen con el modelo de permisos de Android o que roban credenciales (p. ej., tokens de OAuth) de otras aplicaciones
- Aplicaciones que abusan de las funciones para evitar que las desinstalen o las detengan
- Aplicaciones que inhabilitan SELinux
Las aplicaciones de elevación de privilegios que otorgan a los dispositivos derechos de administrador sin permiso del usuario se clasifican como aplicaciones con derechos de administrador.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Desarrolle código que respete el modelo de permisos de Android. | No cree aplicaciones que comprometan el sistema superando la zona de pruebas correspondiente. |
| Diseñe su aplicación para que funcione con privilegios de usuario estándar. | No escriba código que impida que se desinstale la aplicación de un usuario. |
Ransomware
El ransomware es 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 debe bloquear a los usuarios, encriptar datos ni impedir la desinstalación. Esta política protege a los usuarios de la extorsión. Revise la política completa para garantizar su cumplimiento.
Se trata de código que toma el control parcial o extensivo de un dispositivo o sus datos y exige que el usuario realice un pago o una acción para liberar el control.
Algún ransomware encripta los datos en el dispositivo y exige el pago para desencriptarlos, o bien aprovecha las funciones administrativas del dispositivo de modo que no pueda quitarlo un usuario común. Los siguientes son algunos ejemplos:
- Bloquear a un usuario para que no pueda acceder al dispositivo y exigirle dinero para restablecer su control
- Encriptar datos en el dispositivo y exigir un pago, ostensiblemente, para desencriptarlos
- Implementar las funciones del Administrador de políticas del dispositivo y bloquear la posibilidad de eliminación por parte del usuario
Se trata de código que se distribuye con el dispositivo y cuyo fin principal es que la administración del dispositivo subsidiado se pueda excluir de la categoría de ransomware siempre y cuando cumpla satisfactoriamente con los requisitos de administración y bloqueo seguros, y con los de consentimiento y divulgación adecuada para el usuario.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Asegúrese de que el código de su aplicación no contenga ninguna funcionalidad de ransomware malicioso. | No encripte los datos del usuario ni lo bloquee para que no tenga acceso a su dispositivo. |
| Obtenga el consentimiento explícito del usuario para cualquier función de administración de dispositivos. | No use las funciones de administrador del dispositivo para bloquear la desinstalación. |
| Proporcione una forma clara y sencilla para que los usuarios eliminen su aplicación. | No exija pagos ni acciones para restablecer el control del dispositivo. |
Modificación de dispositivos para obtener permisos de administrador
Google Play permite el otorgamiento de permisos de administrador no maliciosos, pero prohíbe el código con permisos de administrador maliciosos. Debe informar a los usuarios por adelantado sobre el proceso de otorgamiento de permisos de administrador y asegurarse de que su aplicación no realice ninguna otra acción dañina. El objetivo es garantizar que los usuarios den su consentimiento para este cambio potente en el dispositivo y no se expongan a comportamientos maliciosos adicionales. Revise la política completa para garantizar su cumplimiento.
Se trata de código que modifica el dispositivo para tener permisos de administrador.
Hay una diferencia en el código de este tipo cuando es malicioso y no malicioso. Por ejemplo, las aplicaciones que modifican el dispositivo para tener permisos de administrador con fines no maliciosos le notifican al usuario por adelantado que harán esto y no ejecutan otras acciones potencialmente dañinas que se apliquen a otras categorías de APD.
Las aplicaciones que modifican el dispositivo para tener permisos de administrador con fines maliciosos no le notifican al usuario que harán esto, o sí le informan por adelantado sobre el proceso pero también ejecutan otras acciones que se aplican a otras categorías de APD.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Informe a los usuarios con anticipación que su aplicación obtendrá permisos de administrador del dispositivo. | No obtenga permisos de administrador de un dispositivo sin informar al usuario. |
| Obtenga el consentimiento explícito del usuario antes de obtener permisos de administrador. | No realice otras acciones perjudiciales en una aplicación que obtiene permisos de administrador. |
| Confirme que el código de su aplicación no tenga ningún otro comportamiento malicioso. | No use código con permisos de administrador para ocultar otras funcionalidades maliciosas. |
Spam
Software espía
Google Play prohíbe la recopilación o el intercambio de datos maliciosos del dispositivo o del usuario. Más allá del consentimiento del usuario o la divulgación, la recopilación de datos y el uso compartido deben estar relacionados con la funcionalidad que satisfaga las políticas. Revise la política completa para garantizar su cumplimiento.
El software espía es una aplicación, un código o un comportamiento malicioso que recopila, exfiltra o comparte los datos de un usuario o dispositivo de una manera no relacionada con la funcionalidad permitida por las políticas.
También puede considerarse que un código o comportamiento malicioso constituye software espía si se puede interpretar que dicho código o comportamiento espía al usuario o exfiltra datos sin la notificación o consentimiento correspondientes.
Por ejemplo, los incumplimientos relacionados con el software espía pueden incluir, entre otros:
- Grabaciones de audio o de llamadas realizadas al teléfono
- Robo de datos de las aplicaciones
- Una aplicación con código malicioso de terceros (por ejemplo, un SDK) que transmita datos hacia fuera del dispositivo de una manera que el usuario no espera o sin una notificación o el consentimiento correspondientes del usuario.
Todas las aplicaciones deben satisfacer también todas las Políticas del Programa para Desarrolladores de Google Play, incluidas las políticas de datos del usuario y del dispositivo, como las de Software no Deseado para Dispositivos Móviles, Datos del Usuario, Permisos y APIs que Acceden a Información Sensible y Requisitos de SDK.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Proporcione una notificación clara y obtenga el consentimiento explícito del usuario antes de recopilar o transmitir datos. | No permita que los SDKs de terceros de su aplicación graben audio o llamadas, o bien obtengan datos de la aplicación sin el consentimiento explícito del usuario y sin una función que satisfaga las políticas. |
| Implemente registros y auditorías sólidos para el acceso y la transmisión de datos de todos los SDKs de terceros para detectar y abordar el robo de datos no autorizado. | No participe en la recopilación de datos oculta ni recopile más datos de los que la aplicación necesita para su función declarada. |
| Asegúrese de que los SDKs integrados en su aplicación solo recopilen los datos mínimos necesarios y que el propósito o comportamiento de estos no hagan que su aplicación incumpla las políticas de Google Play. | No incluya en su aplicación SDKs de terceros que transmitan datos de formas inesperadas o sin el consentimiento adecuado. |
| No suponga que los SDKs de terceros incluidos en las prácticas de recopilación de datos de su aplicación cumplen con las políticas sin una revisión exhaustiva. |
Troyano
Un troyano es un código que contiene un componente malicioso oculto. Esta política prohíbe las aplicaciones que realizan acciones no deseadas contra el usuario sin su conocimiento. Como desarrollador, debe asegurarse de que el código de su aplicación sea transparente y no contenga ninguna funcionalidad dañina oculta. Revise la política completa para garantizar su cumplimiento.
Se trata de código que parece benigno, como un juego que afirma ser solo un juego, pero que realiza acciones no deseadas contra el usuario.
Esta clasificación se suele usar en combinación con otras categorías de APD. Un troyano contiene un componente inocuo y un componente dañino oculto. Por ejemplo, un juego que envía SMS premium desde el dispositivo del usuario en segundo plano y sin que el usuario lo sepa.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Asegúrese de que el código de su aplicación sea transparente y cumpla con el propósito establecido. | No oculte funcionalidades maliciosas en una aplicación que parezca inofensiva. |
| Confirme que todas las funcionalidades de la aplicación se divulguen al usuario. | No realice acciones en segundo plano sin el conocimiento y el consentimiento explícitos del usuario. |
| Asegúrese de que los SDKs de terceros incluidos sean seguros y no contengan comportamientos ocultos. | No tergiverse la finalidad de su aplicación para engañar a los usuarios. |
Una nota sobre aplicaciones poco comunes
Si Google Play Protect no tiene suficiente información para verificar la seguridad de su aplicación nueva, es posible que se clasifique como "poco común". Este estado no significa que su aplicación sea dañina, sino que necesita una revisión adicional. Revise la política completa para garantizar su cumplimiento.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Proporcione información completa y precisa en la ficha de su aplicación. | No oculte la funcionalidad ni use código ofuscado. |
| Asegúrese de que el código de su aplicación sea claro y esté bien documentado para la revisión. | No use bibliotecas de terceros no verificadas. |
Una nota sobre la categoría de puerta trasera
Una puerta trasera es código que habilita un comportamiento malicioso. Si se usa la carga dinámica de código para realizar acciones dañinas, su aplicación incumplirá las políticas. Debe asegurarse de que el código de su aplicación no habilite ninguna funcionalidad oculta o maliciosa. Si se encuentra una vulnerabilidad sin intención maliciosa, se le pedirá que la corrija. Revise la política completa para garantizar su cumplimiento.
La clasificación por categorías de software malicioso de puerta trasera depende de cómo actúa el código. Para que cualquier código se clasifique como puerta trasera, debe permitir, como condición necesaria, un comportamiento que lo colocaría en una de las otras categorías de software malicioso si se ejecutara automáticamente. Por ejemplo, si una aplicación permite la carga de un código dinámico y este extrae mensajes de texto, se clasificará como software malicioso de puerta trasera.
No obstante, si una aplicación permite la ejecución de un código arbitrario y no existe ningún motivo para creer que la ejecución de este código se agregó para producir un comportamiento malicioso, entonces la aplicación se tratará como con una vulnerabilidad, no como software malicioso de puerta trasera, y se le solicitará al desarrollador que le coloque un parche.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Pruebe rigurosamente todo código que permita la ejecución dinámica. | No use la carga dinámica de código para realizar acciones ocultas y maliciosas. |
| Asegúrese de que el código de su aplicación no tenga vulnerabilidades que se puedan explotar. | No permita la ejecución arbitraria de código sin realizar verificaciones de seguridad exhaustivas. |
| Aplique parches de inmediato a las vulnerabilidades de seguridad que se encuentren en su aplicación. | No use bibliotecas de terceros no verificadas que puedan habilitar una puerta trasera. |
Riskware
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 revelar contenido dañino más adelante. Debe asegurarse de que su aplicación sea transparente y no utilice esas técnicas para engañar a los revisores o usuarios. Revise la política completa para garantizar su cumplimiento.
Una aplicación que usa una variedad de técnicas de evasión para presentarle al usuario funciones falsas o diferentes a las esperadas. Estas aplicaciones se hacen pasar por legítimas o por juegos con aspecto inofensivo ante las tiendas de aplicaciones y los usuarios, y usan técnicas tales como la ofuscación, la carga de código dinámico o el encubrimiento para ocultar contenido potencialmente dañino.
El riskware es similar a otras categorías de APD, en especial los troyanos, y su principal diferencia son las técnicas que se usan para ofuscar la actividad maliciosa.
Consideraciones Clave
| Qué debe hacer | Qué no debe hacer |
| Asegúrese de que el código de su aplicación sea claro y fácil de revisar. | No use ofuscación ni encubrimiento para ocultar la funcionalidad. |
| Sea transparente sobre todas las funciones de su aplicación. | No use la carga dinámica de código para publicar contenido malicioso. |
| Divulgue toda la funcionalidad en la descripción de la aplicación. | No haga que el comportamiento de su aplicación para los revisores sea diferente del que experimentan los usuarios normales. |
Help us improve this policy article by taking a 2-minute survey.