Exclusão de responsabilidade: os resumos de políticas tratam-se apenas de vistas gerais; consulte sempre a política completa para garantir a conformidade. Em caso de conflito, a política completa tem precedência
O Google Play proíbe a sua app (ou SDKs de terceiros na sua app) de interferir ou aceder de forma não autorizada ao dispositivo do utilizador, outros dispositivos, rede, API ou serviço, outras apps no dispositivo, todos os serviços Google ou à rede de uma operadora autorizada. Isto engloba vários comportamentos prejudiciais, de elevado risco ou perturbadores, como executar atualizações automáticas fora da Play Store, transferir código executável não autorizado, explorar vulnerabilidades de segurança, facilitar a pirataria ou criar batotas para jogos que afetem outras apps. Proteger a integridade do dispositivo do utilizador e do ecossistema em geral é fundamental. Reveja a política completa para garantir a conformidade.
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 da 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.
- Apps que contornam as proteções do sandbox do Android para obter a identidade ou a atividade do utilizador de outras apps.
Principais considerações
| O que deve fazer | O que não deve fazer |
| Certifique-se de que a sua app e quaisquer SDKs integrados estão em conformidade com os requisitos de otimização do sistema Android nas Diretrizes de qualidade de apps principais. | Não instale outras apps num dispositivo sem o consentimento explícito do utilizador. |
Respeite a definição FLAG_SECURE. Além disso, os contentores no dispositivo têm de respeitar a definição REQUIRE_SECURE_ENV. |
Não facilite serviços de proxy a terceiros, a menos que seja essa a finalidade principal, orientada para o utilizador, da app. |
| Use tarefas de transferência de dados iniciadas pelo utilizador apenas para transferências de dados de rede iniciadas pelo utilizador que são executadas apenas enquanto necessário. | Não use SDKs de terceiros na sua app que transfiram código executável (como ficheiros dex ou .so) de fora do Google Play (exceto em VMs/intérpretes). |
| Consulte o Programa de melhoria de segurança de apps para mais informações acerca dos problemas de segurança mais recentes denunciados aos programadores. | Não ignore a gestão de energia do sistema, a menos que seja elegível. |
| Aja em conformidade com a Política de Serviços em Primeiro Plano. | Não bloqueie nem interfira com outra app que apresente anúncios. |
Não use a autorização FULL-SCREEN INTENT para forçar a interação com notificações e anúncios perturbadores. |
Utilização de serviços em primeiro plano
A Política de Autorização de Serviço em Primeiro Plano garante a transparência e a privacidade do utilizador e um desempenho ideal do dispositivo. Para as apps que segmentem o Android 14 ou superior, é necessário declarar tipos de serviços em primeiro plano (FGS) válidos no manifesto e na Play Console, facultando descrições, o impacto no utilizador e um vídeo de demonstração que justifique a respetiva utilização com base em ações percetíveis iniciadas pelo utilizador. Reveja a política completa para garantir a conformidade.
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.
Principais considerações
| O que deve fazer | O que não deve fazer |
| Execute os FGS apenas durante o tempo necessário para concluir a tarefa. | Não use os FGS se a gestão do sistema da sua tarefa não prejudicar a experiência do utilizador na sua app. Considere alternativas como o WorkManager. |
| Certifique-se de que os FGS fornecem uma funcionalidade essencial da app que seja benéfica para o utilizador, são iniciados pelo utilizador, são visíveis nas notificações ou são percetíveis pelo utilizador (por exemplo, o áudio de uma música). | Não declare tipos de FGS inválidos ou incorretos no manifesto da sua app. |
| Envie um formulário de declaração na Play Console se segmentar o Android 14 ou superior e descreva o exemplo de utilização para cada autorização de serviços em primeiro plano (FGS) usada. Certifique-se de que está selecionado o tipo de FGS adequado. |
Tarefas de transferência de dados iniciadas pelo utilizador
Para manter o controlo do utilizador e evitar atividades prolongadas em segundo plano, o Google Play fornece diretrizes rigorosas para apps que usam a API de tarefas de transferência de dados iniciadas pelo utilizador. As transferências de dados devem ser pedidas diretamente pelo utilizador, garantindo que a app executa um comando em vez de iniciar transferências de forma independente. Essas transferências são exclusivamente para tarefas de transferência de dados de rede e só devem funcionar durante o tempo necessário para concluir a ação pedida. Reveja a política completa para garantir a conformidade.
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.
Principais considerações
| O que deve fazer | O que não deve fazer |
| Inicie as transferências com a ação do utilizador. | Não inicie as transferências automaticamente. |
| Use apenas para tarefas de transferência de dados da rede. | Não use a API para tarefas não relacionadas com a rede. |
| Pare quando a transferência estiver concluída. | Não execute mais tempo do que o necessário. |
Requisitos Flag Secure
FLAG_SECURE é uma flag de ecrã declarada na app que indica que os dados confidenciais na IU devem ser limitados a superfícies seguras, evitando capturas de ecrã e a visualização e captura de ecrãs não seguros. Os programadores usam-na para impedir que o conteúdo seja transmitido ou visto fora da app/do dispositivo. O Google Play requer que todas as apps respeitem as declarações FLAG_SECURE de outras apps e não as contornem por motivos de segurança e privacidade. Reveja a política completa para garantir a conformidade.
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. Principais considerações
| O que deve fazer | O que não deve fazer |
Declare FLAG_SECURE para dados confidenciais na IU que precisem de proteção contra captação. |
Não contorne nem crie soluções para evitar as definições de |
Respeite as declarações FLAG_SECURE de outras apps por motivos de segurança e privacidade. |
Não transmita nem guarde ou coloque em cache conteúdo protegido por FLAG_SECURE fora do dispositivo, mesmo que seja uma ferramenta de acessibilidade. |
Apps que executam contentores Android no dispositivo
Para evitar questões de segurança e privacidade, os programadores podem usar uma flag “REQUIRE_SECURE_ENV” no manifesto da app quando as apps de contentor Android no dispositivo não tiverem todas as funcionalidades de segurança do SO Android. A flag indica que a app não deve ser executada num ambiente simulado. As apps que fornecem estes contentores devem respeitar esta flag, não carregando apps que a declarem, e estão proibidas de contornar esta medida de segurança. Reveja a política completa para garantir a conformidade.
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
- 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).
Principais considerações
| O que deve fazer | O que não deve fazer |
As apps que fornecem contentores no dispositivo têm de verificar a flag REQUIRE_SECURE_ENV nos manifestos de outras apps e não as devem carregar. |
Não ignore a flag. Se uma app declarar a flag REQUIRE_SECURE_ENV, não pode carregá-la para o contentor. |
| Evite criar soluções para contornar a flag. É proibido contornar a flag, por exemplo, carregando versões mais antigas de uma app. | Não contorne as medidas de segurança. Não crie soluções para substituir a preferência de segurança de uma app. |
| Evite APIs de utilização de proxies. Não funcione como um proxy intercetando ou chamando APIs fora do contentor. | Não crie a impressão de que as apps estão a ser executadas num ambiente seguro quando não estão. |
| Reveja os requisitos da política para contentores Android no dispositivo. |