Abuso de dispositivos e de rede

Este artigo vai ser atualizado

Vamos adicionar as mudanças divulgadas recentemente a este artigo.

Incluiremos um novo exemplo na nossa política contra abuso de dispositivos e de rede para determinar que não são permitidos apps que usam a permissão de intent para tela cheia para forçar a interação do usuário com notificações ou anúncios invasivos. (em vigor a partir de 31 de maio de 2024)

Para conferir a prévia da versão atualizada do artigo "Abuso de dispositivos e de rede", acesse esta página.

Não são permitidos apps que causam danos, interferências ou interrupções ou acessam de maneira não autorizada o dispositivo do usuário, assim como outros dispositivos ou computadores, servidores, redes, interfaces de programação do app (APIs, na sigla em inglês) ou serviços. Isso inclui, sem limitação, outros apps no dispositivo, qualquer serviço do Google ou uma rede de operadora de telefonia autorizada.

Os apps no Google Play precisam obedecer aos requisitos padrão de otimização do sistema Android listados nas diretrizes principais de qualidade de apps para o Google Play.

Os apps distribuídos pelo Google Play só podem ser modificados, substituídos ou atualizados pelo mecanismo de atualização do Google Play. Da mesma forma, um app só pode fazer o download de código executável (por exemplo, arquivos dex, JAR ou .so) do Google Play. Essa restrição não se aplica a códigos executados em máquinas virtuais ou intérpretes que ofereçam acesso indireto às APIs do Android (como o JavaScript em um WebView ou navegador).

Apps ou código de terceiros (por exemplo, SDKs) com linguagens interpretadas (JavaScript, Python, Lua etc.) carregadas em tempo de execução (por exemplo, não empacotadas com o app) não podem permitir possíveis violações das políticas do Google Play.

Não são permitidos códigos que introduzam ou explorem vulnerabilidades de segurança. Confira o Programa de melhoria da segurança dos aplicativos para saber mais sobre os problemas de segurança mais recentes sinalizados para os desenvolvedores.

Exemplos de violações comuns
  • Apps que impedem que outro app exiba anúncios ou interferem na exibição deles
  • Apps para fraudar jogos que afetam a jogabilidade de outros apps
  • Apps que facilitam ou oferecem instruções de como invadir serviços, softwares e hardwares ou como fraudar proteções de segurança
  • Apps que acessam ou usam um serviço ou uma API de um modo que viola os Termos de Serviço da API ou do serviço em questão
  • Apps que não estão qualificados para a lista de permissões e tentam ignorar o gerenciamento de energia do sistema
  • Apps que facilitam serviços de proxy para terceiros, o que só pode ser feito se esse for o objetivo principal do app
  • Apps ou código de terceiros (por exemplo, SDKs) que fazem download de código executável (como arquivos dex ou código nativo) de uma fonte que não seja o Google Play
  • Apps que instalam outros apps em um dispositivo sem o consentimento prévio do usuário
  • Apps que facilitam a distribuição ou instalação de software malicioso ou contêm links para esse tipo de software
  • Apps ou código de terceiros (por exemplo, SDKs) contendo um WebView com interface JavaScript adicionada que carrega conteúdo da Web não confiável (por exemplo, URL http://) ou URLs não verificados de fontes não confiáveis (por exemplo, URLs obtidos com intents não confiáveis).

 

Uso de serviço em primeiro plano

A permissão de serviço em primeiro plano garante o uso apropriado dos serviços desse tipo voltados ao usuário. Para apps destinados ao Android 14 e versões mais recentes, é necessário especificar um tipo de serviço em primeiro plano válido para cada serviço dessa categoria usado no app e declarar a permissão de serviço em primeiro plano adequada para o tipo. Por exemplo, se o caso de uso do seu app exigir geolocalização do mapa, é necessário declarar a permissão FOREGROUND_SERVICE_LOCATION no manifesto do app.

Com exceção dos tipos de serviço em primeiro plano systemExempted e shortService, os apps só poderão declarar uma permissão desse tipo caso o uso:

  • ofereça um recurso benéfico para o usuário e relevante para o recurso principal do app;
  • seja iniciado pelo usuário ou perceptível por ele (por exemplo, áudio de uma música, transmissão de mídia para outro dispositivo, notificação precisa e clara ao usuário e solicitação do usuário para enviar uma foto à nuvem);
  • possa ser encerrado ou interrompido pelo usuário;
  • não possa ser interrompido nem adiado pelo sistema sem gerar uma experiência negativa ao usuário ou fazer com que o recurso antecipado por ele não funcione como pretendido (por exemplo, uma chamada telefônica precisa começar imediatamente e não pode ser adiada pelo sistema);
  • seja executado apenas pelo tempo necessário para concluir a tarefa.

Saiba mais sobre o uso de serviço em primeiro plano.

 

API User-initiated Data Transfer Jobs

Os apps só podem usar a API User-initiated Data Transfer Jobs se o uso for:

  • iniciado pelo usuário;
  • para tarefas de transferência de dados da rede;
  • executado apenas pelo tempo necessário para concluir a transferência de dados.

Saiba mais sobre o uso das APIs de transferência de dados iniciada pelo usuário.

 

Requisitos relacionados à FLAG_SECURE

FLAG_SECURE é uma sinalização de exibição declarada no código de um app para indicar que a IU contém dados confidenciais que precisam ser limitados a uma plataforma segura durante o uso do app. Essa sinalização foi criada para impedir que os dados apareçam em capturas de tela ou sejam visualizados em telas não seguras. Os desenvolvedores declaram essa sinalização quando o conteúdo não deve ser visualizado nem transmitido fora do app ou do dispositivo dos usuários.

Por motivos de segurança e privacidade, todos os apps distribuídos no Google Play precisam respeitar a declaração FLAG_SECURE de outros apps. Os apps não devem facilitar nem criar alternativas para ignorar as configurações de FLAG_SECURE em outros apps.

Os apps qualificados como ferramenta de acessibilidade não precisam atender a esse requisito, desde que não transmitam, salvem nem armazenem em cache conteúdo protegido por FLAG_SECURE para acesso fora do dispositivo do usuário.

 

Apps que são executados em contêineres Android no dispositivo

Os apps executados em um contêiner Android no dispositivo oferecem ambientes que simulam todo ou partes de um SO Android. É possível que a experiência nesses ambientes não reflita o pacote completo de recursos de segurança do Android. Por isso, os desenvolvedores têm a opção de adicionar uma flag de manifesto de ambiente seguro para comunicar aos contêineres Android no dispositivo que eles não podem operar na versão simulada do sistema Android.

Sinalização de ambiente seguro no manifesto

A flag REQUIRE_SECURE_ENV pode ser declarada no manifesto do app para indicar que ele não deve ser executado em um contêiner Android no dispositivo. Para fins de segurança e privacidade, os apps que fornecem contêineres Android no dispositivo precisam respeitar os apps que declaram essa flag. Além disso:
  • Revise os manifestos dos apps que eles pretendem carregar no contêiner Android no dispositivo para essa flag.
  • Não carregue os apps que declararam essa flag no contêiner Android no dispositivo.
  • Não opere como um proxy interceptando ou chamando APIs no dispositivo para que pareçam estar instalados no contêiner.
  • Não facilite nem crie soluções alternativas para ignorar a flag, como carregar uma versão mais antiga de um app para burlar a flag REQUIRE_SECURE_ENV do atual.
Saiba mais sobre essa política na Central de Ajuda.

Isso foi útil?

Como podemos melhorá-lo?

Precisa de mais ajuda?

Siga as próximas etapas:

Pesquisa
Limpar pesquisa
Fechar pesquisa
Google Apps
Menu principal
14651545725657716193
true
Pesquisar na Central de Ajuda
true
true
true
true
true
92637
false
false