Exoneração de responsabilidade: os resumos das políticas são apenas visões gerais. Sempre consulte a política na íntegra para verificar a conformidade. A política completa prevalecerá em caso de conflito.
O Google Play proíbe que seu app (ou qualquer SDK de terceiro no seu app) faça o acesso não autorizado ou interfira com o dispositivo do usuário, outros dispositivos, rede, API ou serviço, outros apps no dispositivo, qualquer Serviço do Google ou rede de uma operadora autorizada. Isso abrange uma variedade de comportamentos nocivos, de alto risco ou invasivos, como fazer atualizações automáticas fora da Play Store, baixar código executável não autorizado, explorar vulnerabilidades de segurança, facilitar a invasão ou criar trapaças para jogos que afetam outros apps. É essencial proteger a integridade do dispositivo do usuário e do ecossistema em geral. Por favor, revise a política completa para garantir a compliance.
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 comuns de violação por abuso de dispositivos e de rede:
- Apps que impedem que outro app exiba anúncios ou interferem na exibição deles
- Apps para trapacear em 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 burlar 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 burlar o gerenciamento de energia do sistema
- Apps que facilitam serviços de proxy para terceiros, o que só pode ser feito se essa for a finalidade 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 obtidos de fontes não confiáveis (por exemplo, URLs obtidos com intents não confiáveis)
- 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
- Apps que contornam as proteções do sandbox Android para derivar a atividade ou identidade do usuário de outros apps
Principais considerações
| O que fazer | O que não fazer |
| Confira se o app e todos os SDKs integrados estão em conformidade com os requisitos de otimização do sistema Android descritos nas principais diretrizes de qualidade para apps. | Não instale outros apps em um dispositivo sem consentimento explícito do usuário. |
Respeite a configuração FLAG_SECURE. Contêineres no dispositivo também precisam respeitar REQUIRE_SECURE_ENV. |
Não facilite serviços de proxy para terceiros a não ser que essa seja a funcionalidade principal do app voltada aos usuários. |
| Use jobs de transferência de dados iniciada pelo usuário apenas para transferências de dados em rede iniciadas desse modo e executadas somente pelo tempo necessário. | Não use SDKs de terceiros no app que baixam código executável (como arquivos dex ou .so) de fora do Google Play, a não ser em VMs/intérpretes. |
| 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. | Não ignore o gerenciamento de energia do sistema, a não ser que o app esteja qualificado para isso. |
| Obedeça à política de serviços em primeiro plano. | Não bloqueie ou interfira com outro app exibindo anúncios. |
Não use a permissão FULL-SCREEN INTENT para forçar a interação com notificações e anúncios invasivos. |
Uso de serviço em primeiro plano
A política da permissão de serviço em primeiro plano garante a transparência do usuário, a privacidade e o desempenho ideal do dispositivo. Para apps destinados ao Android 14 ou versões mais recentes, você precisa declarar tipos válidos de serviço em primeiro plano (SPP) no manifesto e no Play Console. Ofereça descrições, o impacto ao usuário e um vídeo de demonstração justificando o uso com base em ações perceptíveis iniciadas pelo usuário. Por favor, revise a política completa para garantir a conformidade.
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.
Os apps só podem declarar uma permissão de serviço em primeiro plano caso o uso:
- ofereça um recurso benéfico para o usuário e relevante para a funcionalidade 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.
Os seguintes casos de uso de serviços em primeiro plano estão isentos dos critérios acima:
- Tipos de serviço em primeiro plano systemExempted ou shortService
- Se os recursos do Play Asset Delivery estão sendo usados, tipo de serviço em primeiro plano "dataSync"
Saiba mais sobre o uso dos serviços em primeiro plano.
Principais considerações
| O que fazer | O que não fazer |
| Execute o serviço em primeiro plano (SPP) apenas pelo tempo necessário para concluir a tarefa. | Não use o SPP se a gestão de sistema da tarefa não interromper a experiência do usuário no app. Considere alternativas como o WorkManager. |
| O SPP precisa oferecer uma funcionalidade benéfica ao usuário e central ao app, ser iniciado pelo usuário e também estar visível em notificações ou perceptível (por exemplo, áudio de uma música). | Não declare tipos de SPP inválidos ou imprecisos no manifesto do app. |
| Envie um formulário de declaração no Play Console se estiver segmentando o Android 14 ou versões mais recentes e descreva o caso de uso de todas as permissões de serviços em primeiro plano (SPP) usadas. Confira se você selecionou o tipo correto de SPP. |
API User-initiated Data Transfer Jobs
Para manter o controle do usuário e evitar atividades prolongadas em segundo plano, o Google Play fornece diretrizes rigorosas para apps que usam a API de jobs de transferência de dados iniciados pelo usuário. As transferências de dados precisam ser solicitadas diretamente pelo usuário, garantindo que o app execute um comando em vez de iniciar as transferências de maneira independente. Essas transferências são exclusivamente para tarefas de transferência de dados de rede e só podem funcionar pela duração necessária para concluir a ação solicitada. Por favor, revise a política completa para garantir a conformidade.
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.
Principais considerações
| O que fazer | O que não fazer |
| Inicie transferências apenas com a ação do usuário. | Não inicie transferências automaticamente. |
| Use somente para tarefas de transferência de dados de rede. | Não use a API para tarefas não relacionadas a rede. |
| Pare quando a transferência for finalizada. | O tempo de execução não pode ser mais longo do que o necessário. |
Requisitos relacionados à FLAG_SECURE
FLAG_SECURE é uma flag de tela declarada pelo app para indicar que os dados sensíveis na interface devem ser limitados a plataformas seguras, evitando capturas de tela e visualização não seguras. Os desenvolvedores usam isso quando o conteúdo não pode ser transmitido ou visualizado fora do app/dispositivo. O Google Play exige que todos os apps respeitem as declarações FLAG_SECURE de outros apps e não as contornem para a segurança e privacidade. Por favor, revise a política completa para garantir a compliance.
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. Principais considerações
| O que fazer | O que não fazer |
Declare FLAG_SECURE para dados sensíveis na interface que precisa de proteção contra a captura. |
Não ignore nem crie alternativas para as configurações de |
Respeite as declarações de FLAG_SECURE de outros apps para segurança e privacidade. |
Não transmita, salve nem armazene em cache conteúdo protegido por FLAG_SECURE fora do dispositivo, mesmo se for uma ferramenta de acessibilidade. |
Apps que são executados em contêineres Android no dispositivo
Para evitar preocupações de segurança e privacidade, os desenvolvedores poderão usar uma flag "REQUIRE_SECURE_ENV" no manifesto do app quando os apps de contêiner Android no dispositivo não tiverem todos os recursos de segurança do SO Android. A flag indica que o app não deve ser executado em um ambiente simulado. Obedecer à flag é obrigatório, portanto, os apps que fornecem esses contêineres não podem carregar apps que declaram a flag nem contornar essa medida de segurança. Por favor, revise a política completa para garantir a conformidade.
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
- 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.
Principais considerações
| O que fazer | O que não fazer |
Os apps que criam contêineres no dispositivo precisam conferir se os outros apps têm a flag REQUIRE_SECURE_ENV no manifesto e não os carregar, se for o caso. |
Ignorar a flag. Não é permitido carregar apps no contêiner se eles declaram a flag REQUIRE_SECURE_ENV. |
| Evitar as táticas alternativas. É proibido ignorar a flag carregando versões mais antigas dos apps, por exemplo. | Ignorar as medidas de proteção. Não crie táticas alternativas para se sobrepor à preferência de segurança dos apps. |
| Evitar aplicar proxies a APIs. Não opere como um proxy interceptando ou chamando APIs fora do contêiner. | Fazer parecer que os apps estão rodando em um ambiente seguro quando isso não for o caso. |
| Consulte os requisitos da política para apps de contêiner Android no dispositivo. |