Pré-visualização: abuso na rede e em dispositivos

Pré-visualização da política (em vigor a partir de 31 de maio de 2024)

Este artigo mostra uma pré-visualização das atualizações da política de outubro de 2023.

Estamos a adicionar um novo exemplo à nossa Política de Abuso na Rede e em Dispositivos para declarar que não permitimos que as apps usem a autorização de intenção de ecrã inteiro para forçar a interação do utilizador com notificações ou anúncios perturbadores.

Para ver o artigo "Abuso na rede e em dispositivos" atual, visite esta página.

Não são permitidas apps que interfiram, perturbem, danifiquem ou acedam de forma não autorizada ao dispositivo do utilizador, outros dispositivos ou computadores, servidores, redes, interfaces de programação de apps (APIs) ou serviços, incluindo, entre outros, outras apps no dispositivo, qualquer serviço Google ou uma rede de operador autorizado.

As apps no Google Play têm de cumprir os requisitos de otimização do sistema Android predefinidos documentados nas Diretrizes de qualidade de apps principais do Google Play.

Uma app distribuída através do Google Play não se pode modificar, substituir ou atualizar a si própria através de qualquer método que não seja o mecanismo de atualização do Google Play. Do mesmo modo, uma app não pode transferir código executável (por exemplo, ficheiros dex, JAR ou .so) proveniente de outras fontes que não o Google Play. Esta restrição não se aplica a código executável numa máquina virtual ou num intérprete que proporcione acesso indireto a APIs do Android (como JavaScript num WebView ou navegador). 

As apps ou o código de terceiros (por exemplo, SDKs) com linguagens interpretadas (JavaScript, Python, Lua, etc.) carregadas no tempo de execução (por exemplo, não fornecidas com a app) não podem permitir potenciais violações das Políticas do Google Play.

Não é permitido código que introduza ou explore vulnerabilidades de segurança. Consulte o Programa de melhoria de segurança de apps para obter mais informações acerca dos problemas de segurança mais recentes sinalizados aos programadores.

Exemplos de violações comuns de abuso na rede e em dispositivos:

• Apps que bloqueiam ou interferem com outra app ao apresentar anúncios.
• Apps de batota em jogos que afetam a jogabilidade de outras apps.
• Apps que facilitam ou fornecem instruções sobre como piratear serviços, software ou hardware, ou contornar proteções de segurança.
• Apps que acedem ou usam um serviço ou uma API de uma forma que viola os respetivos termos de utilização.
• Apps que não são elegíveis para adicionar à lista de autorizações e tentam ignorar a gestão de energia do sistema.
• As apps que facilitam serviços de proxy a terceiros só podem fazê-lo em apps em que seja essa a finalidade principal, centrada no utilizador, da app.
• Apps ou código de terceiros (por exemplo, SDKs) que transferem código executável, como ficheiros dex ou código nativo, proveniente de outras fontes que não o Google Play.
• Apps que instalam outras apps num dispositivo sem o consentimento prévio do utilizador.
• Apps que estabelecem ligação ou facilitam a distribuição ou a instalação de software malicioso.
• Apps ou o código de terceiros (por exemplo, SDKs) que incluam um WebView com interface de JavaScript adicionada que carrega conteúdo Web não fidedigno (por exemplo, um URL http://) ou URLs não validados obtidos de fontes não fidedignas (por exemplo, URLs obtidos de intenções não fidedignas).
• Apps que usam a autorização de intenção de ecrã inteiro para forçar a interação do utilizador com notificações ou anúncios perturbadores.

 

Utilização de serviços em primeiro plano A autorização do serviço em primeiro plano garante a utilização adequada dos serviços em primeiro plano orientados para o utilizador. Para apps que segmentem o Android 14 e superior, tem de especificar um tipo de serviço em primeiro plano válido para cada serviço em primeiro plano usado na sua app e declarar a autorização de serviço em primeiro plano adequada para esse tipo. Por exemplo, se o exemplo de utilização da sua app requer a geolocalização do mapa, tem de declarar a autorização FOREGROUND_SERVICE_LOCATION no manifesto da app. As apps só podem declarar uma autorização de serviço em primeiro plano se a utilização: Oferecer uma funcionalidade benéfica para o utilizador e relevante para a funcionalidade essencial da app For iniciada pelo utilizador ou for percetível pelo utilizador (por exemplo, áudio da reprodução de uma música, transmissão de conteúdo multimédia para outro dispositivo, notificação do utilizador clara e precisa ou pedido do utilizador para carregar uma foto para a nuvem) Puder ser terminada ou parada pelo utilizador Não puder ser interrompida nem diferida pelo sistema sem provocar uma experiência do utilizador negativa ou fazer com que a funcionalidade antecipada pelo utilizador não funcione como esperado (por exemplo, uma chamada telefónica tem de ser iniciada imediatamente e não pode ser diferida pelo sistema) Só funcionar durante o tempo necessário para concluir a tarefa Os seguintes exemplos de utilização de serviços em primeiro plano estão isentos dos critérios acima: Serviços em primeiro plano dos tipos systemExempted ou shortService; Serviço em primeiro plano do tipo dataSync apenas aquando da utilização das funcionalidades da Play Asset Delivery A utilização do serviço em primeiro plano é explicada de modo mais pormenorizado aqui.

 

Tarefas de transferência de dados iniciadas pelo utilizador As apps só podem usar a API User-Initiated Data Transfer Jobs se a utilização: For iniciada pelo utilizador Se destinar a tarefas de transferência de dados por rede Só funcionar durante o tempo necessário para concluir a transferência de dados A utilização de APIs User-Initiated Data Transfer é explicada de modo mais pormenorizado aqui.

 

Requisitos Flag Secure FLAG_SECURE é uma flag de ecrã declarada no código de uma app para indicar que a respetiva IU (interface do utilizador) contém dados confidenciais que se destinam a ser limitados a uma superfície segura durante a utilização da app. Esta flag foi concebida para evitar que os dados apareçam em capturas de ecrã ou sejam vistos em ecrãs não seguros. Os programadores declaram esta flag quando o conteúdo da app não deve ser transmitido, visto nem transmitido fora da app ou do dispositivo dos utilizadores. Por questões de segurança e privacidade, todas as apps distribuídas no Google Play são obrigadas a respeitar a declaração FLAG_SECURE de outras apps. Ou seja, as apps não podem facilitar nem criar soluções para ignorar as definições FLAG_SECURE noutras apps. As apps que se qualificam como uma ferramenta de acessibilidade estão isentas deste requisito, desde que não transmitam, guardem nem coloquem em cache conteúdos protegidos pela flag FLAG_SECURE para acesso fora do dispositivo do utilizador.

 

Apps que executam contentores Android no dispositivo As apps num contentor Android no dispositivo fornecem ambientes que simulam a totalidade ou partes de um SO Android subjacente. A experiência nestes ambientes pode não refletir o conjunto completo de funcionalidades de segurança do Android e, por isso, os programadores podem optar por adicionar uma flag do manifesto do ambiente segura para comunicar aos contentores Android no dispositivo que não podem operar no respetivo ambiente do Android simulado. Flag do manifesto do ambiente segura REQUIRE_SECURE_ENV é uma flag que pode ser declarada no manifesto de uma app para indicar que esta app não pode ser executada em apps num contentor Android no dispositivo. Por questões de segurança e privacidade, as apps que fornecem contentores Android no dispositivo têm de respeitar todas as apps que declaram esta flag e: Rever os manifestos das apps que querem carregar no respetivo contentor Android no dispositivo para esta flag. Não carregar as apps que declararam esta flag no respetivo contentor Android no dispositivo. Não funcionar como um proxy ao intercetar ou chamar APIs no dispositivo para parecerem estar instaladas no contentor. Não facilitar nem criar soluções para contornar a flag (como carregar uma versão mais antiga de uma app para contornar a flag REQUIRE_SECURE_ENV da app atual). Saiba mais acerca desta política no nosso Centro de Ajuda.