Exclusão de responsabilidade: os resumos das políticas e as Principais considerações são apenas vistas gerais; consulte sempre a política completa para garantir a conformidade. Em caso de conflito, a política completa tem precedência.
Para manter um ecossistema Android seguro, o Google Play proíbe qualquer código malicioso, incluindo SDKs de terceiros integrados em apps, que possam colocar os utilizadores, os respetivos dados ou dispositivos em risco. Reveja a política completa para garantir a conformidade.
Política completaSoftware malicioso é qualquer código que possa colocar um utilizador, os dados de um utilizador ou um dispositivo em risco. O software malicioso inclui, entre outros, aplicações potencialmente prejudiciais (PHAs), binários ou modificações de framework e é constituído por categorias como cavalos de troia, phishing e apps de spyware. Estamos continuamente a atualizar e adicionar novas categorias.
Embora varie em tipo e capacidades, o software malicioso tem, normalmente, um dos seguintes objetivos:
- Comprometer a integridade do dispositivo do utilizador.
- Obter controlo sobre o dispositivo de um utilizador.
- Permitir operações controladas remotamente por um atacante para aceder, utilizar ou explorar de outra forma um dispositivo infetado.
- Transmitir dados pessoais ou credenciais a partir do dispositivo sem divulgação e consentimento adequados.
- Disseminar spam ou comandos a partir do dispositivo infetado para afetar outros dispositivos ou redes.
- Defraudar o utilizador.
Uma app, um binário ou uma modificação de framework pode ser potencialmente prejudicial e, assim, gerar comportamento malicioso, mesmo que não se destine a ser prejudicial. Isto acontece porque as apps, os binários ou as modificações de framework podem funcionar de forma diferente, consoante diversas variáveis. Assim, o que é prejudicial para um dispositivo Android pode não colocar de todo em risco outro. Por exemplo, um dispositivo com a versão mais recente do Android não é afetado por apps prejudiciais que utilizem APIs descontinuadas para causar comportamentos maliciosos, mas um dispositivo ainda com uma versão muito antiga do Android pode estar em risco. As apps, os binários ou as modificações de framework são sinalizados como software malicioso ou PHA se constituírem claramente um risco para alguns ou todos os utilizadores e dispositivos Android.
As categorias de software malicioso abaixo refletem a nossa crença fundamental de que os utilizadores devem compreender de que forma os seus dispositivos estão a ser utilizados e promover um ecossistema seguro que permita uma inovação avançada e uma experiência do utilizador fidedigna.
Visite o Google Play Protect para obter mais informações.
| O que deve fazer | O que não deve fazer |
| Analisar cuidadosamente todo o código na sua app, incluindo SDKs de terceiros, para garantir que não apresenta comportamentos semelhantes a software malicioso, como spyware, cavalos de troia ou phishing, mesmo que de forma não intencional. | Integrar código que abuse de privilégios elevados para comprometer a integridade do sistema, criar acesso root nos dispositivos sem o conhecimento e o consentimento explícitos do utilizador ou usar técnicas de maskware para evitar a deteção de comportamento malicioso. |
| Considerar usar ferramentas para verificar vulnerabilidades de segurança ou backdoors que permitam operações remotas indesejadas. | Usar SDKs de terceiros que recolhem e transmitem dados pessoais para monitorização sem divulgação e consentimento adequados do utilizador (ou seja, stalkerware). Incorporar código que cause práticas de faturação enganosas que envolvam SMS, chamadas ou fraude por número pago. |
| Certificar-se de que os SDKs de terceiros não recolhem e/ou exfiltram dados do utilizador sem uma funcionalidade em conformidade com a política e/ou um aviso ou um consentimento adequado (spyware). | Usar SDKs de terceiros que realizam ataques de negação de serviço ou atuam como um programa de transferência de aplicações potencialmente prejudiciais. |
| Certificar-se de que a sua app não inclui SDKs de terceiros que violem o modelo de autorizações do Android ao conseguir privilégios elevados através do acesso a dados do dispositivo para uma finalidade não divulgada. |
Backdoors
Para proteger os seus utilizadores, tem de remover qualquer código que funcione como uma backdoor, que é definida como código que facilita operações indesejadas ou prejudiciais controladas remotamente. Reveja a política completa para garantir a conformidade.
Política completaCódigo que permite a execução de operações indesejadas, potencialmente prejudiciais e controladas remotamente num dispositivo.
Estas operações podem incluir comportamentos que coloquem a app, o binário ou a modificação de framework numa das outras categorias de software malicioso se forem executados automaticamente. Em geral, backdoor é uma descrição da ocorrência de uma operação potencialmente prejudicial num dispositivo e, por conseguinte, não está completamente alinhada com categorias como fraude por faturação ou spyware comercial. Como resultado, um subconjunto de backdoors, em algumas circunstâncias, é tratado pelo Google Play Protect como uma vulnerabilidade.
| O que deve fazer | O que não deve fazer |
| Teste exaustivamente o código da sua app e todas as bibliotecas de terceiros quanto a capacidades de controlo remoto ocultas. | Não inclua funcionalidades nem capacidades ocultas que possam ser exploradas para prejudicar os utilizadores. |
| Proteja todos os pontos finais de execução remota contra o acesso não autorizado. | Não oculte o código para encobrir a funcionalidade de acesso remoto. |
| Aplique patches imediatamente a vulnerabilidades de segurança conhecidas na sua app. | Não ignore os avisos sobre potenciais vulnerabilidades nas suas dependências. |
Fraude por faturação
Para evitar fraude por faturação, tem de remover qualquer código que cobre aos utilizadores de forma enganosa sem o respetivo consentimento explícito. Isto inclui fraude por SMS, fraude por chamada e fraude por número pago, que enganam os utilizadores para que façam pagamentos ou subscrições indesejados. Reveja a política completa para garantir a conformidade.
Política completaCódigo que cobra automaticamente um valor ao utilizador de forma intencionalmente enganadora.
A Fraude por faturação em dispositivos móveis divide-se em Fraude por SMS, Fraude por chamada e Fraude por número pago.
Fraude por SMS
Código que cobra um valor aos utilizadores para enviar SMS premium sem consentimento ou tenta disfarçar as respetivas atividades de SMS ocultando contratos de divulgação ou mensagens SMS da operadora móvel que notificam o utilizador sobre cobranças ou confirmam subscrições.
Algum código, embora divulgue tecnicamente o comportamento de envio de SMS, apresenta um comportamento adicional que permite a fraude por SMS. Alguns exemplos incluem ocultar partes de um contrato de divulgação do utilizador, tornando-as ilegíveis e suprimindo de forma condicional mensagens SMS da operadora móvel que informam o utilizador sobre cobranças ou confirmam uma subscrição.
Fraude por chamada
Código que cobra um valor aos utilizadores através de chamadas para números premium sem o consentimento dos mesmos.
Fraude por número pago
Código que engana os utilizadores ao levá-los a subscrever ou a comprar conteúdo através da respetiva fatura do telemóvel.
A Fraude por número pago inclui todos os tipos de faturação, exceto SMS premium e chamadas premium. Alguns exemplos incluem a Faturação direta da operadora, o protocolo para aplicações sem fios (WAP) e a transferência dos minutos de chamadas para telemóvel. A fraude por WAP é um dos tipos mais comuns de Fraude por número pago. A fraude por WAP pode incluir enganar os utilizadores ao levá-los a clicar num botão num WebView transparente, carregado silenciosamente. Após realizar a ação, uma subscrição recorrente é iniciada, e o SMS ou o email de confirmação é, muitas vezes, acedido indevidamente para impedir que os utilizadores reparem na transação financeira.
| O que deve fazer | O que não deve fazer |
| Obtenha o consentimento explícito e inequívoco dos utilizadores antes de iniciar quaisquer transações financeiras. | Não oculte nem disfarce informações relacionadas com cobranças ou subscrições. |
| Certifique-se de que todas as divulgações de faturação são claras, transparentes e visíveis de forma proeminente para o utilizador. | Não use visualizações Web ocultas, não envie automaticamente mensagens SMS premium nem faça chamadas sem consentimento. |
| Encaminhe todas as notificações de faturação da operadora para o utilizador. | Não use métodos como a Faturação direta da operadora para enganar os utilizadores e levá-los a subscreverem serviços. |
Stalkerware
O Google Play proíbe que as apps monitorizem outro indivíduo através da recolha e transmissão de dados pessoais e confidenciais do utilizador, exceto se a app for concebida e comercializada exclusivamente para os pais monitorizarem as crianças ou a gestão empresarial monitorizar funcionários individuais, desde que estejam em plena conformidade com requisitos rigorosos. Reveja a política completa para garantir a conformidade.
Política completaCódigo que recolhe dados do utilizador pessoais ou confidenciais de um dispositivo e transmite os dados a terceiros (empresa ou outro indivíduo) para fins de monitorização.
As apps têm de fornecer uma divulgação destacada adequada e obter o consentimento, conforme exigido pela Política de Dados do Utilizador.
Diretrizes para aplicações de monitorização
As apps concebidas e comercializadas exclusivamente para monitorizar outro indivíduo, por exemplo, para a monitorização parental das crianças ou a gestão empresarial para monitorizar funcionários individuais são as únicas apps de monitorização aceitáveis, desde que cumpram totalmente os requisitos descritos abaixo. Estas apps não podem ser usadas para monitorizar outra pessoa (um cônjuge, por exemplo) mesmo com o respetivo conhecimento e autorização, independentemente de ser apresentada uma notificação persistente. Estas apps têm de usar a flag de metadados IsMonitoringTool no respetivo ficheiro de manifesto para se designarem apropriadamente como apps de monitorização.
As apps de monitorização têm de cumprir os seguintes requisitos:
- As apps não se podem apresentar como uma solução de espionagem ou vigilância secreta.
- As apps não podem ocultar nem utilizar o "cloaking" de comportamentos de monitorização nem tentar enganar os utilizadores quanto a esta funcionalidade.
- As apps têm sempre de apresentar aos utilizadores uma notificação persistente quando estão a ser executadas e um ícone exclusivo que as identifique claramente.
- As apps têm de divulgar a funcionalidade de monitorização ou acompanhamento na descrição da Google Play Store.
- As apps e as fichas das apps no Google Play não podem fornecer meios para ativar ou aceder a funcionalidades que violem estes termos, nomeadamente a ligação a um APK não conforme que esteja alojado fora do Google Play.
- As apps têm de estar em conformidade com todas as leis aplicáveis. O programador é o único responsável por determinar a legalidade da sua app no local segmentado.
| O que deve fazer | O que não deve fazer |
| Comercialize a sua app exclusivamente para utilização de gestão empresarial ou parental. | Não comercialize a app como uma solução de espionagem ou vigilância. |
Inclua a flag IsMonitoringTool no seu manifesto. |
Não monitorize outros adultos, incluindo cônjuges, mesmo com a respetiva autorização. |
| Apresente uma notificação persistente e um ícone exclusivo durante a execução. | Não oculte, use cloaking nem engane os utilizadores acerca do comportamento de monitorização. |
| Divulgue todas as funcionalidades de monitorização na descrição da loja. | Não tenha links para APKs não conformes alojados fora do Google Play. |
| Apresente uma divulgação destacada adequada e obtenha consentimento. | Não disponibilize meios para ativar funcionalidades que violem estes termos. |
Negação de serviço (DoS)
Para proteger a sua app e outros sistemas, tem de remover qualquer código que, sem o conhecimento do utilizador, ataque outros sistemas ou gere uma carga de rede excessiva sem o conhecimento do utilizador. Reveja a política completa para garantir a conformidade.
Política completaCódigo que, sem conhecimento do utilizador, executa um ataque de negação de serviço (DoS) ou faz parte de um ataque DoS distribuído contra outros sistemas e recursos.
Por exemplo, tal pode ocorrer ao enviar um elevado volume de pedidos HTTP para produzir uma carga excessiva nos servidores remotos.
| O que deve fazer | O que não deve fazer |
| Teste exaustivamente o seu código e os SDKs de terceiros quanto a abuso de rede. | Não oculte nem incorpore código que gere um volume elevado de tráfego ou pedidos de rede. |
| Certifique-se de que todos os pedidos de rede da sua app são legítimos e necessários para a respetiva funcionalidade. | Não inclua funcionalidades que possam ser ativadas remotamente para atacar sistemas externos. |
Gestores de transferências hostis
O Google Play proíbe "programas de transferência de aplicações potencialmente prejudiciais", ou seja, apps que transferem outro software indesejável para dispositivos móveis (MUwS). Uma app é denunciada como um programa de transferência de aplicações potencialmente prejudiciais caso se considere que foi concebida para distribuir MUwS ou se determine que, pelo menos, 5% das respetivas transferências são MUwS. Esta política não se aplica aos principais navegadores nem às apps de partilha de ficheiros, desde que transfiram software apenas com o consentimento explícito e a ação do utilizador. Reveja a política completa para garantir a conformidade.
Código que, por si só, não é potencialmente prejudicial, mas transfere outras PHAs.
O código pode ser um gestor de transferências hostil se:
- Existirem motivos para acreditar que foi criado para distribuir PHAs e tiver transferido PHAs ou contiver código que pode transferir e instalar apps; ou
- Pelo menos, 5% das apps transferidas pelo mesmo forem PHAs com um limite mínimo de 500 transferências de apps observadas (25 transferências de PHAs observadas).
Os principais navegadores e apps de partilha de ficheiros não são considerados gestores de transferências hostis, desde que:
- Não iniciem transferências sem a interação do utilizador; e
- Todas as transferências de PHAs forem iniciadas por utilizadores que as consentiram.
| O que deve fazer | O que não deve fazer |
| Certifique-se de que a sua app não inclui código que distribua MUwS. | Não inclua código na sua app que distribua MUwS. |
| Monitorize as transferências para se manter bem abaixo do limite de MUwS de 5%. | Não exceda o limite de 5% de MUwS (25 MUwS por 500 transferências). |
| Certifique-se de que todas as transferências de apps são iniciadas por um utilizador que as consentiu, se o objetivo da sua app for transferir outros ficheiros (como um navegador ou a partilha de ficheiros). | Não inclua funcionalidades que gerem transferências de apps sem a interação explícita do utilizador, se o objetivo da sua app for transferir outros ficheiros (como um navegador ou a partilha de ficheiros). |
Ameaça que não afeta o Android
Código que contém ameaças que não afetam o Android.
Estas apps não podem causar danos aos dispositivos nem aos utilizadores do Android, mas contêm componentes que são potencialmente prejudiciais para outras plataformas.
Phishing
Tem de remover qualquer código relacionado com phishing pedindo de forma enganosa as credenciais ou as informações de faturação de um utilizador e enviando-as a terceiros. Reveja a política completa para garantir a conformidade.
Política completaCódigo que finge ser de uma origem fidedigna, solicita as credenciais de autenticação ou as informações de faturação de um utilizador e envia os dados a terceiros. Esta categoria também se aplica ao código que interceta a transmissão de credenciais do utilizador em trânsito.
Os alvos comuns de phishing incluem credenciais bancárias, números de cartões de crédito e credenciais de contas online para redes sociais e jogos.
| O que deve fazer | O que não deve fazer |
| Use APIs oficiais e métodos seguros para processar credenciais do utilizador e informações de pagamento. | Não se faça passar por uma origem fidedigna para enganar os utilizadores e levá-los a facultar dados pessoais ou financeiros. |
| Certifique-se de que todos os dados do utilizador são transmitidos de forma segura e não são legíveis por terceiros. | Não intercete nem recolha credenciais do utilizador ou informações confidenciais sem consentimento. |
| Seja transparente com os utilizadores sobre os dados que está a pedir e porquê. | Não envie informações confidenciais do utilizador a terceiros sem a divulgação adequada ao utilizador e o consentimento explícito. |
Abuso de privilégios elevados
Para evitar violações de abuso de privilégios elevados, a sua app não pode conter código que receba privilégios elevados ou danifique o sandbox de segurança do Android. Isto inclui código que rouba credenciais de outras apps, contorna o modelo de autorizações do Android ou desativa funcionalidades de segurança essenciais. A sua app também tem de respeitar o controlo do utilizador sobre o respetivo dispositivo. Reveja a política completa para garantir a conformidade.
Política completaCódigo que compromete a integridade do sistema ao danificar o sandbox da app, obter privilégios elevados ou alterar/desativar o acesso a funções de segurança essenciais.
Os exemplos incluem:
- Uma app que viola o modelo de autorizações do Android ou rouba credenciais (tais como símbolos OAuth) de outras apps.
- Apps que abusam das funcionalidades para impedir a respetiva desinstalação ou paragem.
- Uma app que desativa o SELinux.
As apps de escalamento de privilégios que criam acesso máximo nos dispositivos sem a autorização do utilizador são classificadas como apps com acesso máximo.
| O que deve fazer | O que não deve fazer |
| Programe código que respeite o modelo de autorizações do Android. | Não crie apps que comprometam o sistema danificando o sandbox da app. |
| Conceba a sua app para funcionar com privilégios de utilizador padrão. | Não escreva código que impeça a desinstalação da app de um utilizador. |
Ransomware
O ransomware é um software malicioso que sequestra o dispositivo ou os dados de um utilizador, exigindo um pagamento ou uma ação para restaurar o controlo. Não pode bloquear o acesso dos utilizadores, encriptar dados nem impedir a desinstalação. Esta política protege os utilizadores contra extorsão. Reveja a política completa para garantir a conformidade.
Política completaCódigo que assume o controlo parcial ou extensivo de um dispositivo ou de dados num dispositivo e exige que o utilizador efetue um pagamento ou realize uma ação para libertar o controlo.
Alguns tipos de ransomware encriptam os dados no dispositivo e exigem um pagamento para os desencriptar e/ou tiram partido das funcionalidades de administração do dispositivo para que um utilizador típico não os possa remover. Os exemplos incluem:
- Bloquear o acesso de um utilizador ao respetivo dispositivo e exigir dinheiro para restaurar o controlo do utilizador.
- Encriptar os dados no dispositivo e exigir um pagamento aparentemente para desencriptar os dados.
- Tirar partido das funcionalidades de gestão de políticas do dispositivo e bloquear a remoção por parte do utilizador.
O código distribuído com o dispositivo cujo objetivo principal seja a gestão de dispositivos subsidiados pode ser excluído da categoria de ransomware desde que cumpra os requisitos de gestão e bloqueio seguros, bem como os requisitos adequados de divulgação e consentimento do utilizador.
| O que deve fazer | O que não deve fazer |
| Certifique-se de que o código da sua app não tem funcionalidades de ransomware maliciosas. | Não encripte os dados do utilizador nem bloqueie o acesso ao respetivo dispositivo. |
| Obtenha o consentimento explícito do utilizador para quaisquer funcionalidades de gestão de dispositivos. | Não use funcionalidades de administração de dispositivos para bloquear a desinstalação. |
| Ofereça aos utilizadores uma forma clara e fácil de remover a sua app. | Não exija um pagamento nem uma ação para restaurar o controlo do dispositivo. |
Acesso máximo
O Google Play permite o acesso root não malicioso, mas proíbe o código com acesso root malicioso. Tem de informar os utilizadores antecipadamente acerca do acesso root e garantir que a sua app não executa outras ações prejudiciais. O objetivo é garantir que os utilizadores consentem esta alteração poderosa do dispositivo e não são expostos a comportamento malicioso adicional. Reveja a política completa para garantir a conformidade.
Política completaCódigo com acesso máximo ao dispositivo.
Existe uma diferença entre código com acesso máximo malicioso e não malicioso. Por exemplo, as apps com acesso máximo não maliciosas informam o utilizador antecipadamente de que irão controlar o dispositivo com acesso máximo e não executam outras ações potencialmente prejudiciais que se aplicam a outras categorias de PHAs.
As apps com acesso máximo maliciosas não informam o utilizador de que irão controlar o dispositivo com acesso máximo ou informam o utilizador antecipadamente acerca do acesso máximo, mas também executam outras ações que se aplicam a outras categorias de PHAs.
| O que deve fazer | O que não deve fazer |
| Informe os utilizadores antecipadamente de que a sua app vai ter acesso root ao dispositivo. | Não obtenha acesso root a um dispositivo sem informar o utilizador. |
| Obtenha o consentimento explícito do utilizador antes de ter acesso root. | Não execute outras ações prejudiciais numa app com acesso root. |
| Confirme que o código da sua app não tem outros comportamentos maliciosos. | Não use código com acesso root para ocultar outra funcionalidade maliciosa. |
Spam
Spyware
O Google Play proíbe a recolha ou a partilha maliciosa de dados do dispositivo ou do utilizador. Independentemente da divulgação ao utilizador ou do consentimento deste, a recolha e a partilha de dados têm de estar relacionadas com a funcionalidade em conformidade com a política. Reveja a política completa para garantir a conformidade.
Política completaO spyware é uma aplicação, um código ou um comportamento malicioso que recolhe, exfiltra ou partilha dados do utilizador ou do dispositivo que não estão relacionados com a funcionalidade compatível com a política.
O código ou o comportamento malicioso que possa ser considerado espionagem sobre o utilizador ou exfiltre dados sem um aviso ou um consentimento adequado também é considerado spyware.
Os exemplos de violações de spyware incluem, entre outros:
- A gravação de áudio ou de chamadas feitas para o telemóvel
- O roubo de dados de apps
- Uma app com código malicioso de terceiros (por exemplo, um SDK) que transmite dados para fora do dispositivo de uma forma inesperada para o utilizador e/ou sem um aviso ou um consentimento adequado.
Todas as apps têm de estar em conformidade com todas as Políticas do Programa para Programadores do Google Play, incluindo políticas de dados do dispositivo e do utilizador, nomeadamente software indesejável para dispositivos móveis, dados do utilizador, autorizações e APIs com acesso a informações confidenciais e requisitos de SDKs.
| O que deve fazer | O que não deve fazer |
| Faculte um aviso claro e obtenha o consentimento explícito do utilizador antes de qualquer recolha ou transmissão de dados. | Não permita que os SDKs de terceiros na sua app gravem áudio, chamadas ou obtenham dados de apps sem o consentimento explícito do utilizador e a funcionalidade em conformidade com a política. |
| Implemente um registo e uma auditoria robustos para o acesso e a transmissão de dados de todos os SDKs de terceiros, de modo a detetar e resolver a exfiltração de dados não autorizada. | Não faça uma recolha de dados oculta nem recolha mais dados do que a app precisa para a respetiva função declarada. |
| Certifique-se de que os SDKs integrados na sua app apenas recolhem os dados mínimos necessários e que a respetiva finalidade ou comportamento não fazem com que a sua app viole as Políticas do Google Play. | Não inclua SDKs de terceiros na sua app que transmitam dados de formas inesperadas ou sem o consentimento adequado. |
| Não presuma que os SDKs de terceiros nas suas práticas de recolha de dados da app estão em conformidade sem uma revisão exaustiva. |
Cavalo de Troia
Um cavalo de troia é um código que contém um componente malicioso oculto. Esta política proíbe apps que realizam ações indesejáveis contra o utilizador sem o respetivo conhecimento. Como programador, tem de garantir que o código da sua app é transparente e não tem funcionalidades ocultas nem prejudiciais. Reveja a política completa para garantir a conformidade.
Política completaCódigo que parece benigno, como um jogo que afirma ser apenas um jogo, mas que realiza ações indesejadas contra o utilizador.
Normalmente, esta classificação é utilizada em combinação com outras categorias de PHAs. Um cavalo de Troia tem um componente inócuo e um componente prejudicial oculto. Por exemplo, um jogo que envia mensagens SMS premium do dispositivo do utilizador em segundo plano sem o seu conhecimento.
| O que deve fazer | O que não deve fazer |
| Certifique-se de que o código da sua app é transparente e cumpre o objetivo declarado. | Não oculte funcionalidades maliciosas numa app aparentemente inofensiva. |
| Confirme que todas as funcionalidades da app são divulgadas ao utilizador. | Não execute ações em segundo plano sem o conhecimento e o consentimento explícitos do utilizador. |
| Certifique-se de que todos os SDKs de terceiros incluídos são seguros e não contêm comportamentos ocultos. | Não represente de forma fraudulenta o objetivo da sua app para enganar os utilizadores. |
Nota sobre apps invulgares
Se o Google Play Protect não tiver informações suficientes para validar a segurança da sua nova app, esta pode ser classificada como "invulgar". Este estado não significa que a sua app seja prejudicial, mas que necessita de uma revisão adicional. Reveja a política completa para garantir a conformidade.
Política completa
| O que deve fazer | O que não deve fazer |
| Disponibilize informações completas e precisas na ficha da app. | Não oculte a funcionalidade nem use código oculto. |
| Certifique-se de que o código da sua app está limpo e bem documentado para revisão. | Não use bibliotecas de terceiros não validadas. |
Nota sobre a categoria Backdoor
Uma backdoor é um código que permite um comportamento malicioso. Se o carregamento de código dinâmico for usado para realizar ações prejudiciais, a sua app está em violação. Tem de garantir que o código da sua app não ativa nenhuma funcionalidade oculta ou maliciosa. Se for encontrada uma vulnerabilidade sem intenção maliciosa, é-lhe pedido que a corrija. Reveja a política completa para garantir a conformidade.
Política completaA classificação de categoria de software malicioso de backdoor depende da forma como o código atua. Uma condição necessária para qualquer código ser classificado como backdoor é permitir comportamentos que colocariam o código numa das outras categorias de software malicioso se fosse executado automaticamente. Por exemplo, se uma app permitir o carregamento de código dinâmico e o código carregado dinamicamente estiver a extrair mensagens de texto, será classificada como software malicioso de backdoor.
No entanto, se uma app permitir a execução de código arbitrário e não tivermos qualquer razão para acreditar que esta execução de código foi adicionada para realizar um comportamento malicioso, a app será tratada como tendo uma vulnerabilidade, em vez de ser considerada software malicioso de backdoor, e será solicitado ao programador que a corrija.
| O que deve fazer | O que não deve fazer |
| Teste rigorosamente qualquer código que permita a execução dinâmica. | Não use o carregamento de código dinâmico para realizar ações ocultas e maliciosas. |
| Certifique-se de que o código da sua app não tem vulnerabilidades que possam ser exploradas. | Não permita a execução de código arbitrário sem verificações de segurança cuidadosas. |
| Corrija imediatamente quaisquer vulnerabilidades de segurança encontradas na sua app. | Não use bibliotecas de terceiros não validadas que possam ativar uma backdoor. |
Riskware
O riskware é uma app que usa técnicas de evasão para ocultar funcionalidades maliciosas. Faz-se passar por uma app legítima, usando métodos como a ocultação ou o carregamento dinâmico de código para revelar conteúdo prejudicial posteriormente. Tem de garantir que a sua app é transparente e não usa essas técnicas para enganar os revisores ou os utilizadores. Reveja a política completa para garantir a conformidade.
Política completaUma aplicação que usa uma variedade de técnicas de evasão para servir ao utilizador uma funcionalidade diferente, ou falsa, da aplicação. Estas apps fazem-se passar por aplicações ou jogos legítimos para parecerem inócuas às lojas de apps e utilizadores, e usam técnicas como a ocultação, o carregamento dinâmico de código ou o cloaking para revelar conteúdo potencialmente prejudicial.
O riskware é semelhante a outras categorias de PHA, especificamente os cavalos de troia, sendo que as técnicas usadas para ocultar a atividade maliciosa são a principal diferença.
| O que deve fazer | O que não deve fazer |
| Certifique-se de que o código da sua app é nítido e fácil de rever. | Não use ocultação nem cloaking para ocultar a funcionalidade. |
| Seja transparente acerca de todas as funções da sua app. | Não use o carregamento de código dinâmico para publicar conteúdo malicioso. |
| Divulgue todas as funcionalidades na descrição da app. | Não faça com que o comportamento da sua app seja diferente para os revisores em comparação com os utilizadores normais. |
Help us improve this policy article by taking a 2-minute survey.