Juntos, podemos criar a plataforma de apps e jogos mais confiável do mundo

Conteúdo restrito

Conteúdo prejudicial a crianças

Os apps que não proíbem os usuários de criar, enviar ou distribuir conteúdo que facilite a exploração ou o abuso de crianças estão sujeitos à remoção imediata do Google Play. Isso inclui todos os materiais de abuso sexual infantil. Para denunciar esse tipo de conteúdo em um produto do Google, clique em Denunciar abuso. Se você encontrar algo desse tipo em qualquer local da Internet, entre em contato direto com as autoridades competentes do seu país.

Proibimos o uso de apps de modo que coloque crianças em risco. Isso inclui, entre outras práticas, o uso de apps para promover comportamentos predatórios em relação a crianças, por exemplo:

• Interação inadequada direcionada a uma criança, por exemplo, apalpar ou acariciar
• Aliciamento infantil, por exemplo, fazer amizade on-line para facilitar contato sexual on-line ou off-line e/ou trocar imagens sexuais com uma criança
• Sexualização de menores, por exemplo, imagens que retratam, incentivam ou promovem o abuso sexual de crianças ou a representação delas de alguma forma que possa resultar na exploração sexual infantil
• "Sextorção", por exemplo, ameaçar ou chantagear uma criança usando acesso real ou suposto a imagens íntimas dela
• Tráfico infantil, por exemplo, fazer propaganda de crianças ou propostas para exploração sexual comercial

Se identificarmos materiais de abuso sexual infantil, vamos adotar as medidas apropriadas, que podem incluir denúncias ao Centro Nacional para Crianças Desaparecidas e Exploradas dos Estados Unidos. Se você acredita que uma criança corre perigo ou foi alvo de abuso, exploração ou tráfico, entre em contato com as autoridades locais e com uma organização de segurança infantil indicada neste link.

Além disso, não são permitidos apps que tenham conteúdo interessante para crianças, mas apresentem temas adultos, incluindo, mas não se limitando a:

• apps com violência e sangue excessivos;
• apps que retratam ou incentivam atividades nocivas e perigosas.

Também não permitimos apps que promovam uma visão negativa da própria imagem ou do corpo, incluindo aqueles que retratam cirurgia plástica, perda de peso e outras modificações estéticas à aparência física de uma pessoa para fins de entretenimento.

Conteúdo inadequado

Conteúdo sexual e linguagem obscena

Não são permitidos apps que tenham ou promovam conteúdo sexual ou linguagem obscena, incluindo pornografia ou qualquer conteúdo ou serviço com o objetivo de satisfação sexual. Apps ou conteúdo que aparentam promover ou solicitar atos sexuais em troca de remuneração também não são permitidos. Não permitimos apps que tenham ou promovam conteúdos associados a comportamento sexualmente predatório ou que distribuam conteúdo sexual não consensual. O conteúdo com nudez talvez seja permitido se for principalmente para fins educacionais, documentais, científicos ou artísticos, e não apenas uma exposição sem justificativa.

Os apps de catálogo (ou seja, aqueles que listam títulos de livros/vídeos como parte de um catálogo geral de conteúdos) podem distribuir títulos de livros, incluindo e-books e audiolivros, ou de vídeos que têm conteúdo sexual caso atendam aos seguintes requisitos:

• Os títulos de livros/vídeos que têm conteúdo sexual representam uma fração pequena do catálogo geral do app
• O app não promove ativamente títulos de livros/vídeos que têm conteúdo sexual. Esses títulos ainda poderão aparecer nas recomendações com base no histórico do usuário ou durante promoções gerais
• O app não distribui nenhum título de livro/vídeo que tem conteúdo de risco para crianças, pornográfico ou qualquer outro conteúdo sexual considerado ilegal pela legislação aplicável
• O app protege menores de idade restringindo o acesso a títulos de livros/vídeos que têm conteúdo sexual

Mesmo se tiver conteúdo que viole esta política e estiver indisponível em outras regiões, um app pode ser disponibilizado para os usuários de uma região específica caso o conteúdo seja considerado apropriado nesse local.

Veja alguns exemplos de violações comuns:

• Representações de nudez sexual ou posições sexualmente sugestivas em que há pessoas nuas, desfocadas ou seminuas e/ou em que a roupa seria inadequada em um contexto público apropriado
• Imagens, animações ou ilustrações de atos sexuais ou poses sexualmente sugestivas ou a representação sexual das partes do corpo
• Conteúdo que retrata ou funciona como acessório sexual, guias sexuais, temas sexuais ilegais e fetiches
• Conteúdo obsceno ou linguagem obscena, incluindo, mas não se limitando a, palavrões, insultos, texto explícito ou palavras-chave de conteúdo adulto/sexual na página "Detalhes do app" ou no app
• Conteúdo que retrata, descreve ou incentiva a zoofilia
• Apps que promovam entretenimento relacionado a sexo, serviços de acompanhantes ou outras atividades que possam ser interpretadas como realização ou solicitação de atos sexuais em troca de remuneração, incluindo, mas não se limitando a, serviços de namoro ou encontros sexuais compensados em que seja necessário ou esteja implícito que um participante dará dinheiro, presentes ou apoio financeiro a outro participante, como "sugar dating"
• Apps que degradam ou objetificam pessoas, como os que alegam despir ou permitir ver através das roupas, mesmo que estejam rotulados como apps de entretenimento ou brincadeira
• Conteúdo ou comportamento que tente ameaçar ou explorar pessoas de maneira sexual, como fotos íntimas sem consentimento, câmera escondida, conteúdo sexual não consensual criado com deepfake ou tecnologia semelhante ou conteúdo de agressão

Discurso de ódio

Não são permitidos apps que promovam a violência ou incitem ódio contra indivíduos ou grupos com base em raça ou origem étnica, religião, deficiência, idade, nacionalidade, condição de veterano, orientação sexual, gênero, identidade de gênero, casta, status de imigrante ou outras características associadas à discriminação sistêmica ou à marginalização.

Apps com conteúdo educacional, documental, científico ou artístico (EDCA) relacionado a nazistas podem ser bloqueados em determinados países, de acordo com as legislações e regulamentações locais.

Veja alguns exemplos de violações comuns:

• Conteúdo ou discurso que declara que um grupo protegido é desumano, inferior ou digno de ser odiado.
• Apps que contêm insultos, estereótipos ou teorias sobre um grupo protegido ter características negativas (por exemplo, ser mal-intencionado, corrupto, mau etc.) ou que afirmam, explícita ou implicitamente, que o grupo é considerado uma ameaça.
• Conteúdo ou discurso que incentiva os outros a acreditar que pessoas devem ser odiadas ou discriminadas porque são membros de um grupo protegido.
• Conteúdo que promove símbolos de ódio, como bandeiras, símbolos, insígnias, instrumentos ou comportamentos associados a grupos de ódio.

Violência

Veja alguns exemplos de violações comuns:

• São proibidas as representações gráficas ou descrições de violência realista ou ameaças violentas a qualquer pessoa ou animal.
• Não são permitidos apps que promovam automutilação, suicídio, transtornos alimentares, jogos de asfixia nem outras ações que podem resultar em ferimentos graves ou morte.

Extremismo violento

Organizações terroristas ou outros grupos ou movimentos perigosos que participaram, coordenaram ou se responsabilizaram por atos de violência contra civis não podem publicar apps no Google Play para nenhum propósito, incluindo recrutamento.

Não são permitidos apps com conteúdo relacionado a extremismo violento ou ao planejamento, à organização ou à glorificação de violência contra civis, como promoção de atos terroristas, incitação à violência ou glorificação de ataques terroristas. Se você for postar algum conteúdo relacionado a extremismo violento para fins educacionais, documentais, científicos ou artísticos ("EDCA"), forneça informações relevantes sobre esse contexto.

Eventos sensíveis

Veja alguns exemplos de violações comuns:

• Insensibilidade em relação à morte de uma ou mais pessoas reais devido a suicídio, overdose, causas naturais etc.
• Negação da ocorrência de um evento trágico significativo e bem documentado
• Lucro aparente com um evento sensível sem benefício perceptível para as vítimas

Bullying e assédio

Veja alguns exemplos de violações comuns:

• Bullying com vítimas de conflitos internacionais ou religiosos
• Conteúdo com o objetivo de explorar pessoas, incluindo extorsão, chantagem etc.
• Postagem de conteúdo para humilhar um indivíduo publicamente
• Assédio a vítimas de um evento trágico ou a amigos e familiares dessas pessoas

Produtos perigosos

Não permitimos apps que possibilitem a venda de explosivos, armas de fogo, munição nem determinados acessórios para armas de fogo.

• Os acessórios restritos incluem aqueles que permitem que uma arma de fogo simule acionamento automático ou que converta uma arma de fogo em arma automática (por exemplo, coronhas com amortecimento, gatilhos com sistema Gatling, encaixes para trava de gatilho automática ou kits de conversão), além de carregadores ou cintas com mais de 30 cartuchos.

Não são permitidos apps que forneçam instruções para a fabricação de explosivos, armas de fogo, munição, acessórios restritos para armas de fogo ou outras armas. Isso inclui instruções sobre como converter uma arma de fogo em arma automática, ou de acionamento automático simulado.

Maconha

Veja alguns exemplos de violações comuns:

• Permitir que os usuários solicitem maconha por meio de um recurso de carrinho de compras no app.
• Ajudar os usuários a organizar a entrega ou a retirada de maconha.
• Facilitar a venda de produtos que contenham THC (tetra-hidrocanabinol), incluindo óleos de CBD com THC.

Tabaco e bebidas alcoólicas

• Não é permitido descrever ou incentivar o uso ou a venda de bebidas alcoólicas ou tabaco a menores.
• Não é permitido sugerir que o consumo de tabaco pode melhorar o comportamento social, sexual, profissional, intelectual ou atlético.
• Não é permitido retratar o uso excessivo de bebidas alcoólicas de maneira favorável, incluindo a representação de consumo compulsivo ou de competições.
• Não são permitidos anúncios, promoções ou destaques de produtos de tabaco, incluindo anúncios, banners, categorias e links para sites de venda de tabaco.
• A venda limitada de produtos de tabaco em apps de entrega de alimentos/mantimentos pode ser permitida em determinadas regiões, sujeita a salvaguardas de restrição de idade, como a verificação de identidade na entrega.
• Talvez seja permitida a venda de produtos comercializados para cessação do tabagismo, sujeita a salvaguardas de restrição de idade.

Serviços financeiros

Não permitimos apps que exponham os usuários a produtos e serviços financeiros enganosos ou nocivos.

Para os fins desta política, são considerados produtos e serviços financeiros aqueles que estão relacionados ao gerenciamento e investimento de moedas e criptomoedas, incluindo consultoria personalizada.

Caso seu app tenha ou promova produtos e serviços financeiros, será preciso obedecer a regulamentações estaduais e locais de todos os países ou regiões a que ele é destinado. Por exemplo, incluir a divulgação de informações específicas exigidas pela legislação local.

Para apps que oferecem qualquer tipo de recurso financeiro, preencher o formulário de declaração de tais funcionalidades no Play Console é um requisito obrigatório.

Opções binárias

Empréstimos pessoais

Definimos os empréstimos pessoais como a concessão de crédito em dinheiro por um indivíduo, organização ou entidade a um consumidor individual de modo não recorrente e sem o propósito de financiamento estudantil ou compra de um ativo fixo. Os consumidores de empréstimos pessoais precisam de informações sobre a qualidade, as características, as taxas, o cronograma de quitação, os riscos e as vantagens desses produtos para tomar decisões conscientes sobre a possibilidade de assumir o empréstimo.

• Alguns exemplos disso são os empréstimos pessoais, consignados, empréstimos peer-to-peer e com alienação da propriedade.
• Não estão incluídos: hipotecas, financiamentos para automóveis e linhas de crédito rotativo (como cartões de crédito ou linhas de crédito pessoal).

Os apps que oferecem empréstimo pessoal, incluindo mas não se limitando a, apps que oferecem empréstimos de maneira direta, geradores de leads e aqueles que conectam consumidores a credores terceirizados, precisam ter a categoria "Finanças" no Play Console e divulgar as seguintes informações nos próprios metadados:

• Períodos mínimo e máximo para quitação
• A taxa percentual anual (APR, na sigla em inglês) máxima, que geralmente inclui juros, taxas e outros custos por um ano, ou outra taxa similar calculada de acordo com a legislação local
• Um exemplo representativo do custo total do empréstimo, incluindo o valor inicial e todas as taxas aplicáveis
• Uma Política de Privacidade que declare de maneira abrangente o acesso, a coleta, o uso e o compartilhamento de dados pessoais e sensíveis dos usuários, sujeita às restrições descritas nesta política

Não são permitidos apps de empréstimo pessoal que exijam quitação em até 60 dias a partir da data de emissão. Definimos esse serviço como "empréstimo pessoal de curto prazo".

Os apps de empréstimo pessoal operando em países em que regulamentações específicas permitem de maneira explícita essas práticas de empréstimo de curto prazo sob estruturas legais estabelecidas poderão ser considerados exceções a essa política. Nesses casos raros, faremos uma avaliação de acordo com as diretrizes legais e regulatórias locais aplicáveis.

O Google precisa conseguir associar sua conta de desenvolvedor às licenças e documentações enviadas que comprovam sua qualificação para prestar serviços de empréstimo pessoal. Em alguns casos, será necessário apresentar outras informações e documentações para confirmar que sua conta está em conformidade com as leis e regulamentações locais.

Os apps de empréstimo pessoal, apps que têm como função principal facilitar o acesso a esse serviço (como facilitadores ou geradores de leads), apps complementares de empréstimo (calculadoras de empréstimo, guias de empréstimo etc.) e apps de Acesso ao Salário Ganho (EWA, na sigla em inglês) não podem acessar dados sensíveis, como fotos e contatos. As seguintes permissões são proibidas:

• Read_external_storage
• Read_media_images
• Read_contacts
• Access_fine_location
• Read_phone_numbers
• Read_media_videos
• Query_all_packages
• Write_external_storage

Os apps que usam APIs ou informações sensíveis estão sujeitos a restrições e requisitos adicionais. Encontre mais informações na política de permissões.

Empréstimos pessoais com taxa percentual anual (APR) alta

Nos Estados Unidos, não são permitidos apps de concessão de empréstimo pessoal em que a taxa percentual anual (APR) seja igual ou maior que 36%. Os apps de empréstimo pessoal nos Estados Unidos precisam exibir a APR máxima, calculada de maneira consistente com a lei de transparência em empréstimos Truth in Lending Act (TILA).

A política se aplica aos apps que oferecem empréstimos de maneira direta, aos geradores de leads e aos que conectam consumidores a credores terceirizados.

Requisitos específicos dos países

Os apps de empréstimo pessoal destinados aos países listados precisam obedecer a requisitos adicionais e apresentar documentação complementar como parte da declaração de recursos financeiros no Play Console. Você precisa, a pedido do Google Play, enviar informações adicionais ou documentos relacionados a compliance dos requisitos de regulamentação e licenciamento aplicáveis.

1. Índia
   • Se você tiver uma licença pelo Reserve Bank of India (RBI) para oferecer empréstimos pessoais, precisará enviar uma cópia dela para nossa análise.
   • Se você não tem envolvimento direto em atividades de empréstimo de dinheiro e apenas fornece uma plataforma para facilitar essas operações entre usuários e bancos ou instituições financeiras não bancárias (NBFCs) registradas, é preciso informar isso de maneira explícita na declaração.
     • Além disso, os nomes de todas as NBFCs e bancos registrados precisam ser declarados em destaque na descrição do app.
2. Indonésia
   • Caso o app esteja envolvido com serviços de empréstimo de dinheiro baseados em tecnologia da informação, nos termos do Regulamento OJK nº 77/POJK.01/2016 (e alterações periódicas), será necessário enviar uma cópia da licença válida para nossa análise.
3. Filipinas
   • Todas as empresas de financiamento e empréstimo que oferecem crédito por plataformas de empréstimo on-line (OLPs) precisam ter os números de registro da Comissão de Valores Mobiliários (SEC) e do certificado de autoridade (CA) da Comissão de Valores Mobiliários das Filipinas (PSEC, siglas em inglês).
     • Além disso, é preciso divulgar o nome corporativo, o nome da empresa, o número de registro da PSEC e o certificado de autoridade para operar uma empresa de financiamento/empréstimo (CA) na descrição do app.
   • Os apps envolvidos em atividades de financiamento coletivo com base em crédito, como empréstimo entre pessoas (P2P), ou conforme definido nas regras e nos regulamentos que regem o financiamento coletivo (Regras de CF), precisam processar transações com intermediários de financiamento coletivo registrados na PSEC.
4. Nigéria
   • Os credores digitais precisam seguir e preencher os PRINCÍPIOS E DIRETRIZES REGULAMENTARES/DE REGISTRO TEMPORÁRIOS E LIMITADOS PARA EMPRÉSTIMO DIGITAL DE 2022 (e alterações periódicas) da Comissão Federal de Proteção à Concorrência e ao Consumidor (FCCPC, na sigla em inglês) da Nigéria, além de ter uma carta de aprovação verificável da FCCPC.
   • Os agregadores de empréstimo precisam apresentar a documentação e/ou a certificação para serviços de empréstimo digital e os detalhes de contato de todos os credores digitais parceiros.
5. Quênia
   • As provedoras de crédito digitais (DCPs) precisam concluir o processo de registro da DCP e ter uma licença do Banco Central do Quênia (CBK, siglas em inglês). É preciso enviar uma cópia da sua licença do CBK na declaração.
   • Se você não tem envolvimento direto em atividades de empréstimo de dinheiro e apenas fornece uma plataforma para facilitar essas operações entre as DCPs registradas e os usuários, informe isso de maneira explícita na declaração e envie uma cópia da licença da DCP dos parceiros em questão.
   • No momento, só aceitamos declarações e licenças de entidades publicadas de acordo com o Diretório de Provedoras de Crédito Digitais no site oficial do CBK.
6. Paquistão
   • Cada credor de uma instituição financeira não bancária (NBFC) só pode publicar um app de empréstimo digital (DLA, na sigla em inglês). Os desenvolvedores que tentarem publicar mais de um DLA por NBFC poderão ter a conta de desenvolvedor e todas as outras associadas encerradas.
   • É necessário enviar um documento do SECP que comprova sua qualificação para oferecer ou facilitar serviços de empréstimo digital no Paquistão.
7. Tailândia
   • Os apps de empréstimo pessoal direcionados a usuários na Tailândia, com taxas de juros de 15% ou mais, precisam ter uma licença válida do Banco da Tailândia (BoT) ou do Ministério das Finanças (MoF, siglas em inglês). Os desenvolvedores precisam apresentar documentação que comprove a capacidade de oferecer ou facilitar empréstimos pessoais na Tailândia. Essa documentação deve incluir o seguinte:
     • Uma cópia da licença emitida pelo Banco da Tailândia para operar como provedora de empréstimo pessoal ou organização financeira nano.
     • Uma cópia da licença comercial Pico Finance emitida pelo Ministério das Finanças para operar como um credor Pico ou Pico-plus.

Veja um exemplo de uma violação comum:

Jogos de azar com dinheiro real, jogos e concursos

Permitimos apps de jogos de azar com dinheiro real, anúncios relacionados a esses tipos de jogos, programas de fidelidade com resultados gamificados e apps de fantasy games diários que atendam a determinados requisitos.

Apps de jogos de azar

Sujeito a restrições e conformidade com todas as políticas do Google Play, permitimos apps que viabilizem ou facilitem jogos de azar on-line em países selecionados, desde que o desenvolvedor conclua o processo de inscrição para apps de jogos de azar distribuídos no Google Play, seja um operador governamental aprovado e/ou registrado como um operador licenciado pela autoridade governamental adequada no país especificado e apresente uma licença operacional válida no país especificado para o tipo de jogos de azar on-line que quer oferecer.

Só permitimos apps de jogos de azar licenciados ou autorizados que tenham os tipos de produtos de jogos de azar on-line a seguir.

• Jogos de cassino on-line
• Apostas esportivas
• Corrida de cavalos (onde regulamentada e licenciada separadamente das apostas esportivas)
• Loterias
• Fantasy games diários

Os apps precisam atender aos seguintes requisitos:

• O desenvolvedor precisa passar pelo processo de inscrição para distribuir o app no Google Play.
• O app precisa obedecer a todas as legislações e padrões do setor aplicáveis dos países em que é distribuído.
• O desenvolvedor precisa ter uma licença de jogos de azar válida para cada país ou estado/território em que o app é distribuído.
• O desenvolvedor não pode oferecer um tipo de jogos de azar que exceda o escopo da licença.
• O app precisa impedir que usuários menores de idade façam uso dele.
• O app precisa impedir o acesso e o uso em países, estados/territórios ou áreas geográficas não cobertos pela licença de jogos de azar fornecida ao desenvolvedor.
• O app NÃO pode ser publicado como pago no Google Play nem usar o Faturamento do Google Play no app.
• O app precisa ser gratuito para download e instalação na Google Play Store.
• O app precisa ter a classificação "AO" (Adult Only, "somente adultos") ou equivalente pela Coalizão Internacional de Classificação Indicativa (IARC, na sigla em inglês).
• O app e a página de detalhes dele precisam mostrar informações claras sobre a participação responsável em jogos de azar.

Outros apps de jogos com dinheiro real, concursos e torneios

Para todos os outros apps que não atendem aos requisitos de qualificação de apps de jogos de azar mencionados acima e que não estão incluídos em "Outros testes de jogos com dinheiro real" abaixo, não permitimos conteúdo ou serviços que permitam ou facilitem a participação dos usuários em jogos de azar ou o uso de dinheiro real (incluindo itens no app comprados em dinheiro) para receber um prêmio de valor monetário real. Isso inclui, entre outros, cassinos on-line, apostas esportivas, loterias e jogos que aceitam dinheiro ou oferecem prêmios em dinheiro ou outros itens de valor real (exceto os programas permitidos nos requisitos dos programas de fidelidade gamificados descritos abaixo).

Exemplos de violações

• Jogos que aceitam dinheiro em troca de uma oportunidade de ganhar um prêmio físico ou monetário
• Apps que têm elementos ou recursos de navegação (por exemplo, itens de menu, guias, botões, WebViews etc.) com uma "call-to-action" para apostar ou participar de jogos, concursos ou torneios que usam dinheiro real, como apps que convidam os usuários com palavras como "APOSTE!", "INSCREVA-SE!" ou "CONCORRA!" em um torneio para ter a chance de ganhar um prêmio em dinheiro
• Apps que aceitam ou gerenciam apostas, moedas no app, ganhos ou depósitos para apostar em ou ganhar um prêmio físico ou monetário

Outros pilotos de jogos com dinheiro real

Eventualmente, podemos lançar pilotos por tempo limitado para alguns tipos de jogos com dinheiro real em regiões específicas. Saiba mais nesta página da Central de Ajuda. O piloto de jogos de garra on-line no Japão foi encerrado em 11 de julho de 2023. A partir de 12 de julho de 2023, os apps de jogos de garra on-line poderão ser exibidos no Google Play, sujeitos à legislação aplicável e a determinados requisitos.

Programas de fidelidade gamificados

Quando for permitido por lei e não houver requisitos adicionais de licenciamento de jogos ou jogos de azar, permitimos programas de fidelidade que recompensam os usuários com prêmios reais ou o equivalente monetário, de acordo com os seguintes requisitos de qualificação da Play Store:

Para todos os apps (jogos e outros):

• Os benefícios, as cortesias ou as recompensas do programa de fidelidade precisam ser claramente complementares e subordinados a qualquer transação monetária qualificada no app (em que a transação monetária qualificada precisa ser uma transação separada real para fornecer produtos ou serviços independentes do programa de fidelidade) e não podem estar sujeitos a compras ou vinculados a modos de troca que violem as restrições da Política de jogos de azar com dinheiro real, jogos e concursos.
  • Por exemplo, nenhuma parte da transação monetária qualificada poderá representar uma tarifa ou um prêmio para participar do programa de fidelidade, e a transação monetária qualificada não poderá resultar na compra de bens ou serviços acima do preço normal.

Para apps de jogos:

• Os pontos de fidelidade ou as recompensas com benefícios, cortesias ou prêmios associados a uma transação monetária qualificada só podem ser concedidos e resgatados de forma fixa, em que a proporção é documentada de forma visível no app e também dentro das regras oficiais disponíveis publicamente para o programa. Além disso, o ganho de benefícios ou o valor de resgate não poderá ser apostado, concedido nem multiplicado de acordo com o desempenho no jogo ou em resultados baseados em probabilidades.

Para apps que não são de jogos:

• Os pontos de fidelidade ou as recompensas poderão ser vinculados a um concurso ou a resultados com base em probabilidades, desde que atendam aos requisitos indicados abaixo. Os programas de fidelidade com benefícios, cortesias ou recompensas associados a uma transação monetária qualificada precisam:
  • publicar as regras oficiais para o programa no app;
  • para programas que envolvam sistemas de recompensas variáveis, aleatórias ou baseadas em probabilidades, divulgar nos termos oficiais do programa 1) as chances dos programas que usam probabilidades fixas para determinar as recompensas e 2) o método de seleção (por exemplo, as variáveis usadas para determinar a recompensa) de todos os programas;
  • especificar um número fixo de vencedores, prazo fixo de inscrição e data de concessão do prêmio, por promoção, de acordo com os termos oficiais de um programa que oferece sorteios, prêmios ou outras promoções de estilo semelhante;
  • documentar todas as proporções fixas de acréscimo e resgate de pontos ou recompensas de fidelidade de maneira visível no app e nos termos oficiais do programa.

Anúncios de jogos de azar ou jogos, concursos e torneios com dinheiro real em apps distribuídos pelo Google Play

Permitimos apps com anúncios que promovem jogos de azar e jogos, concursos e torneios com dinheiro real caso atendam aos seguintes requisitos:

• O app, o anúncio e os anunciantes precisam obedecer a todas as legislações e padrões do setor aplicáveis nos locais em que o anúncio for exibido.
• O anúncio precisa atender a todos os requisitos locais de licenciamento aplicáveis a todos os produtos e serviços promovidos que sejam relacionados com jogos de azar.
• O app não pode exibir anúncios de jogos de azar para menores de 18 anos.
• O app não pode estar inscrito no programa Feito para Família.
• O app não pode segmentar pessoas menores de 18 anos.
• Se você promover um app de jogos de azar (conforme definido acima), o anúncio precisará mostrar claramente informações sobre como participar de jogos de azar de maneira responsável na página de destino, na página "Detalhes do app" ou no próprio app.
• O app não pode ter conteúdo de jogos de azar simulados (por exemplo, apps sociais de cassino ou caça-níqueis virtuais).
• O app não pode ter funções de suporte para jogos de azar nem para jogos, loterias ou torneios com dinheiro real (por exemplo, funcionalidades que ajudem com apostas, pagamentos, acompanhamento de placares/desempenho/prognósticos esportivos ou gerenciamento de fundos de jogos de azar).
• O conteúdo do app não pode promover ou direcionar os usuários a serviços de jogos de azar ou jogos, loterias ou torneios com dinheiro real.

Somente os apps que atendem a todos esses requisitos na seção listada (acima) podem incluir anúncios de jogos de azar e jogos, loterias ou torneios com dinheiro real. Os "Apps de jogos de azar" (conforme definido acima) ou os "Apps de fantasy games diários" (conforme definido abaixo) aceitos que atendem aos requisitos de 1 a 6 acima podem incluir anúncios de jogos de azar ou de jogos, loterias ou torneios com dinheiro real.

Exemplos de violações

• Um app criado para usuários menores de idade exibe um anúncio que promove serviços de jogos de azar.
• Um jogo de cassino simulado promove ou direciona os usuários para cassinos com dinheiro real.
• Um app dedicado ao acompanhamento de prognósticos esportivos contém anúncios de jogos de azar integrados com links para um site de apostas esportivas.
• Apps com anúncios de jogos de azar que violam nossa política de anúncios enganosos, como anúncios exibidos aos usuários na forma de botões, ícones ou outros elementos interativos no app.

Apps de fantasy sport diário (DFS, na sigla em inglês)

Os apps de fantasy sports diários (DFS, na sigla em inglês), definidos conforme a lei local aplicável, só serão permitidos se cumprirem com os seguintes requisitos:

• O app 1) é distribuído apenas nos Estados Unidos ou 2) está qualificado de acordo com os requisitos para apps de jogos de azar e o processo de inscrição mencionados acima para países diferentes dos EUA.
• O desenvolvedor precisa passar pelo processo de inscrição para DFS e ser aceito para distribuir o app no Google Play.
• O app precisa estar em conformidade com todas as legislações e padrões do setor aplicáveis aos países em que é distribuído.
• O app precisa impedir que usuários menores de idade apostem ou façam transações monetárias por meio dele.
• O app NÃO pode ser publicado como pago no Google Play nem usar o Faturamento do Google Play no app.
• O app precisa ser gratuito para download e instalação na Play Store.
• O app precisa ter a classificação "AO" (Adult Only, "somente adultos") ou equivalente pela Coalizão Internacional de Classificação Indicativa (IARC, na sigla em inglês).
• O app e a página "Detalhes do app" precisam mostrar informações claras sobre a participação responsável em jogos de azar.
• O app precisa obedecer a todas as legislações e a todos os padrões do setor aplicáveis dos estados ou territórios dos EUA em que é distribuído.
• O desenvolvedor precisa ter uma licença válida em cada estado ou território dos EUA que exija isso para apps de fantasy sport diário.
• O app precisa impedir o uso em estados ou territórios dos EUA em que o desenvolvedor não tem a licença necessária para apps de fantasy sport diário.
• O app precisa impedir o uso em estados ou territórios dos EUA em que apps de fantasy sports diários são ilegais.

Atividades ilícitas

Veja alguns exemplos de violações comuns:

• Facilitar a venda ou compra de drogas ilícitas
• Descrever ou incentivar o uso ou a venda de drogas, álcool ou tabaco para menores
• Dar instruções para o cultivo ou fabricação de drogas ilícitas

Conteúdo gerado pelo usuário

O conteúdo gerado pelo usuário (UGC) são as contribuições dos usuários para o app que ficam visíveis ou acessíveis para pelo menos um subconjunto de usuários.

Os apps que têm ou apresentam UGC, incluindo navegadores ou clientes especializados para direcionar os usuários a uma plataforma de UGC, precisam implementar uma moderação de UGC adequada, robusta, eficaz e contínua que:

• exija que os usuários aceitem os Termos de Uso e/ou a política do usuário do app antes de criarem ou fazerem o upload de UGC;
• defina o que são conteúdos e comportamentos questionáveis (de maneira compatível com as Políticas do programa para desenvolvedores do Google Play) e fazer a proibição deles nos Termos de Uso ou nas políticas do usuário do app;
• implemente uma moderação de UGC de maneira razoável e compatível com os tipos de UGC hospedados pelo app. Isso inclui oferecer um sistema no app para denunciar e bloquear UGC e usuários questionáveis, além de tomar medidas contra eles quando apropriado; Diferentes experiências com UGC podem exigir diferentes esforços de moderação. Por exemplo:
  • Apps com UGC que identifiquem um grupo específico de usuários por meios como verificação do usuário ou registro off-line (por exemplo, apps usados exclusivamente dentro de uma escola ou empresa, etc.) precisam oferecer uma funcionalidade no app para denunciar conteúdo e usuários.
  • Recursos de UGC que permitem interações individuais entre usuários específicos (por exemplo, mensagens diretas, inclusão de tags, menções, etc.) precisam oferecer uma funcionalidade no app para bloquear usuários.
  • Apps que oferecem acesso UGC acessível publicamente, como apps de redes sociais e blogs, precisam implementar funcionalidades no app para bloquear e denunciar usuários e conteúdo.
  • No caso de apps de realidade aumentada (RA), a moderação de UGC (incluindo o sistema de denúncias no app) precisa considerar o UGC de RA questionável (por exemplo, uma imagem de RA sexualmente explícita) e o local confidencial de ancoragem do RA (por exemplo, conteúdo de RA ancorado em um área restrita, como uma base militar ou uma propriedade privada em que a ancoragem de RA pode causar problemas para o proprietário).
• Ter salvaguardas para evitar que a monetização no app incentive o comportamento questionável do usuário.

Conteúdo sexual incidental

O conteúdo sexual é considerado "incidental" quando aparece em um app de UGC que (1) oferece acesso principalmente a conteúdo não sexual e (2) não promove nem recomenda conteúdo sexual ativamente. Conteúdo sexual definido como ilegal pela legislação aplicável e de risco para crianças não é considerado "incidental" e não é permitido.

Os apps de UGC podem ter conteúdo sexual incidental quando todos os requisitos a seguir são atendidos:

• Esse conteúdo é ocultado por padrão por filtros que exigem pelo menos duas ações do usuário para desativação completa, por exemplo: material escondido por um intersticial ofuscante ou não visível por padrão, a menos que a "pesquisa segura" seja desativada.
• As crianças, conforme definidas pela Política para famílias, são expressamente proibidas de acessar o app por sistemas de verificação de idade, como uma tela neutra de informações de idade ou um sistema apropriado como disposto pela legislação aplicável.
• O app fornece respostas precisas ao questionário de classificação do conteúdo relacionado a UGC, conforme exigido pela política de classificação do conteúdo.

Os apps que tiverem como função principal a exibição de UGC questionável serão removidos do Google Play. Da mesma forma, os apps usados principalmente para hospedar UGC questionável ou que forem conhecidos pelos usuários por serem lugares onde esse tipo de conteúdo se desenvolve também serão removidos do Google Play.

Veja alguns exemplos de violações comuns:

• Promoção de conteúdo sexualmente explícito gerado pelo usuário, incluindo a implementação de recursos pagos que incentivam principalmente o compartilhamento de conteúdo questionável
• Apps com UGC que não tenham salvaguardas suficientes contra ameaças, assédio ou bullying, especialmente voltados a menores
• Postagens, comentários ou fotos em um app que tenham como objetivo principal assediar ou expor outra pessoa a abuso, ataque malicioso ou deboche
• Apps que não atendam às reclamações dos usuários sobre conteúdo questionável

Conteúdo e serviços relacionados à saúde

Não são permitidos apps que exponham os usuários a conteúdo e serviços prejudiciais à saúde.

Se você oferece um app que tem ou promove conteúdo e serviços de saúde, ele precisa obedecer às leis e regulamentações locais.

Apps de saúde

Caso seu app acesse dados de saúde e seja um app de saúde ou ofereça recursos relacionados, ele precisa obedecer às atuais Políticas para Desenvolvedores do Google Play, inclusive as de Privacidade, fraude e uso indevido de dispositivos e Eventos sensíveis, além dos requisitos abaixo:

• Declaração do Console:
  • Acesse a página "Conteúdo do app" ("Política" > "Conteúdo do app") no Play Console e selecione a categoria ou as categorias em que o app se encaixa.
• Requisitos para a Política de Privacidade e a declaração em destaque:
  • O app precisa incluir um link para a Política de Privacidade no campo designado no Play Console e outro link ou texto da política no próprio app. Sua política precisa estar disponível de forma não editável em um URL ativo, publicamente acessível e sem fronteira geográfica virtual, conforme definido na seção "Segurança dos dados". Não use PDFs.
  • A Política de Privacidade, assim como outras declarações no app, precisa explicar claramente como o app acessa, coleta, usa e compartilha dados pessoais e sensíveis do usuário, sem se limitar aos dados divulgados na seção "Segurança dos dados" acima. Caso tenha recursos ou dados regulamentados por permissões perigosas ou de execução, o app precisará atender a todos os requisitos de solicitação de consentimento e declaração em destaque aplicáveis.
  • As permissões que não são necessárias para o app de saúde executar a funcionalidade principal não precisam ser solicitadas, e as permissões que não são usadas precisam ser removidas. Para consultar a lista de permissões consideradas no escopo de dados sensíveis relacionados à saúde, consulte Categorias de apps de saúde e informações adicionais.
  • Caso o app não seja primariamente de saúde, mas tenha recursos relacionados e acesse dados de saúde, ele ainda estará no escopo da política de apps de saúde. A relação entre a funcionalidade principal do app e a coleta de dados relacionados à saúde precisa estar clara para o usuário, por exemplo: seguradoras, apps de jogos que coletam dados de atividade do usuário para avançar etc. A Política de Privacidade do app precisa refletir esse uso limitado.
• Requisitos adicionais:
  Caso seu app de saúde se qualifique para uma das designações a seguir, será preciso cumprir os requisitos relevantes, além de selecionar a categoria apropriada no Play Console:
  • Apps de saúde governamentais: caso você tenha autorização do governo ou de uma organização de saúde reconhecida para desenvolver e distribuir um app em colaboração com eles, será necessário apresentar um comprovante de qualificação no formulário de aviso com antecedência.
  • Apps de monitoramento de contatos/estado de saúde: caso o app seja de monitoramento de contatos e/ou de estado de saúde, selecione "Prevenção de doenças e saúde pública" no Play Console e envie as informações necessárias (usando o formulário de aviso com antecedência acima).
  • Apps de pesquisa em seres humanos: os apps que fazem pesquisas em seres humanos relacionadas à saúde precisam seguir todas as regras e regulamentos, incluindo, mas não se limitando a, receber o consentimento informado dos participantes ou, no caso de menores, do pai, mãe ou responsável. Os apps de pesquisa em saúde também precisam receber aprovação de um Conselho de Revisão Institucional e/ou de um comitê de ética independente equivalente, a menos que sejam isentos. Um comprovante dessa aprovação precisa ser enviado mediante solicitação.
  • Apps de dispositivos médicos ou SaMD: os apps considerados dispositivos médicos ou SaMDs (software como dispositivo médico, na sigla em inglês) precisam receber e manter uma carta de autorização ou outra documentação de aprovação emitida por uma autoridade regulatória ou órgão responsável pela governança e conformidade do app. A comprovação dessa autorização ou aprovação precisa ser enviada mediante solicitação.

Dados do app Conexão Saúde

Medicamentos controlados

Substâncias não aprovadas

Veja alguns exemplos de violações comuns:

• Todos os itens desta lista de exemplos de suplementos e produtos farmacêuticos proibidos

• Produtos com efedrina

• Produtos com gonadotrofina coriônica humana (hCG) destinados à perda ou ao controle de peso ou promovidos em conjunto com esteroides anabolizantes

• Suplementos herbáceos e dietéticos com componentes farmacêuticos ativos ou ingredientes perigosos

• Declarações falsas ou enganosas sobre saúde, incluindo afirmações que implicam que um produto tem a mesma eficácia de substâncias controladas ou medicamentos vendidos sob prescrição médica

• Promoção de produtos não aprovados pelo governo insinuando que eles são seguros e eficazes para a prevenção, cura ou tratamento de doenças ou problemas de saúde específicos

• Produtos sujeitos a qualquer aviso ou ação regulamentar ou governamental

• Produtos com nomes muito semelhantes a uma substância farmacêutica, suplemento ou substância controlada não aprovada

Desinformação relacionada à saúde

Veja alguns exemplos de violações comuns:

• Declarações enganosas sobre vacinas, como dizer que elas podem alterar o DNA de uma pessoa
• Defesa de tratamentos prejudiciais e não aprovados
• Defesa de outras práticas prejudiciais à saúde, como terapia de conversão

Funcionalidades médicas

Pagamentos – Serviços clínicos

Conteúdo baseado em blockchain

Com a rápida evolução da tecnologia blockchain, pretendemos disponibilizar uma plataforma para que os desenvolvedores possam crescer com inovação e oferecer experiências avançadas e imersivas aos usuários.

Para os fins desta política, a expressão "conteúdo baseado em blockchain" refere-se a ativos digitais tokenizados protegidos em um blockchain. Caso seu app tenha esse tipo de conteúdo, será preciso obedecer aos requisitos mencionados.

Corretoras de criptomoedas e carteiras de software

A compra, manutenção ou troca de criptomoedas deve ser realizada por serviços certificados em jurisdições regulamentadas.

Você precisa obedecer à regulamentação aplicável de cada região ou país segmentado pelo seu app. Além disso, evite publicar o app em locais onde seus produtos e serviços são proibidos. O Google Play pode solicitar informações ou documentos adicionais para garantir compliance com os requisitos de regulamentação ou licenciamento aplicáveis.

Criptomineração

Requisitos de transparência para distribuição de ativos digitais tokenizados

Caso seu app venda ou ofereça como prêmio ativos digitais tokenizados aos usuários, será preciso incluir essa informação no formulário de declaração de recursos financeiros na página "Conteúdo do app" no Play Console.

Ao criar um produto no app, você precisa informar que ele representa um ativo digital tokenizado na seção de detalhes. Para saber mais, confira o artigo Criar um produto no app.

Requisitos adicionais para gamificação de NFTs

De acordo com a Política de jogos, concursos e jogos de azar com dinheiro real do Google Play, os apps de jogos de azar que integram ativos digitais tokenizados, como NFTs, devem concluir o processo de aplicação.

Para todos os outros apps que não atendem aos requisitos de qualificação relacionados a apps de jogos de azar e que não estão incluídos em outros pilotos de jogos com dinheiro real, nenhum valor monetário deve ser aceito em troca da chance de receber um NFT de valor desconhecido. Os NFTs comprados devem ser consumidos ou usados no jogo para aprimorar a experiência dos jogadores ou para ajudar os usuários a avançar no jogo. Não é permitido usar NFTs para apostar ou negociar a oportunidade de ganhar prêmios de valor monetário real (incluindo outros NFTs).

Veja alguns exemplos de violações comuns:

• Apps que vendem pacotes de NFTs sem divulgar o conteúdo específico e os valores dos tokens.
• Jogos sociais de cassino pagos, como caça-níqueis, que oferecem NFTs como recompensa.

Conteúdo gerado por IA

Conteúdo gerado por IA

O conteúdo gerado por IA é criado por modelos de IA generativa com base em comandos de usuários. Exemplos de conteúdo gerado por IA:

• Chatbots de IA generativa de conversação de texto para texto, em que o principal recurso do app é interagir com o chatbot
• Imagens geradas por IA com base em comandos de texto, imagem ou voz

Para garantir a segurança dos usuários e obedecer à Cobertura da política do Google Play, os apps que geram conteúdo usando IA precisam estar em conformidade com as políticas para desenvolvedores do Google Play. Isso inclui proibir e impedir a geração de conteúdo restrito, como conteúdo que facilita a exploração ou o abuso de crianças e que permite comportamento enganoso.

Os apps que geram conteúdo usando IA precisam oferecer recursos para que os usuários sinalizem ou denunciem aos desenvolvedores o conteúdo ofensivo sem precisar sair do app. Essas denúncias precisam ser usadas por desenvolvedores para ajustar os filtros de conteúdo e a moderação nos apps.

Propriedade intelectual

Não são permitidos apps ou contas de desenvolvedor que violam direitos de propriedade intelectual de outras pessoas (incluindo marcas registradas, direitos autorais, patentes, segredos comerciais e outros direitos de propriedade). Também são proibidos os apps que incentivam a violação de direitos de propriedade intelectual ou levam a esse tipo de infração.

Responderemos a notificações claras de suposta violação de direitos autorais. Para receber mais informações ou preencher uma solicitação da DMCA, visite nossa página de procedimentos sobre direitos autorais.

Para enviar uma reclamação sobre a venda ou promoção de produtos falsificados em um app, envie um aviso de falsificação.

Se você for proprietário de uma marca registrada e acreditar que há um app no Google Play que viole seus direitos de marca registrada, entre em contato diretamente com o desenvolvedor para resolver o problema. Se não for possível chegar a uma solução, envie uma reclamação de marca registrada por meio deste formulário.

Se você tiver documentação por escrito comprovando sua permissão para usar a propriedade intelectual de terceiros no app ou na página "Detalhes do app" (como nomes de marcas, logotipos e recursos gráficos), entre em contato com a equipe do Google Play antes do envio para garantir que o app não seja rejeitado por violação de propriedade intelectual.

Uso não autorizado de conteúdo protegido por direitos autorais

Apps que violem direitos autorais não são permitidos. Modificar conteúdo protegido por direitos autorais ainda pode ser considerado uma violação. Pode ser solicitado que os desenvolvedores forneçam evidências dos direitos deles sobre conteúdo protegido por direitos autorais.

Tenha cuidado ao usar conteúdo protegido por direitos autorais para demonstrar a funcionalidade do seu app. Em geral, a abordagem mais segura é criar algo original.

Veja alguns exemplos de violações comuns:

• Arte da capa de álbuns de música, videogames e livros
• Imagens de publicidade para filmes, programas de TV e jogos de video game.
• Pôsteres ou imagens de quadrinhos, desenhos animados, filmes, clipes musicais ou programas de TV.
• Logotipos de times profissionais ou de universidades.
• Fotos tiradas da conta de mídia social de uma figura pública.
• Imagens profissionais de figuras públicas.
• Reproduções ou "artes de fãs" indistinguíveis de uma obra original protegida por direitos autorais.
• Apps de sons que reproduzam clipes de áudio de conteúdo protegido por direitos autorais.
• Reproduções completas ou traduções de livros que não sejam de domínio público

Incentivo à violação de direitos autorais

Veja alguns exemplos de violações comuns:

• Apps de streaming que permitem aos usuários fazer o download de uma cópia local de conteúdo protegido por direitos autorais sem autorização

• Apps que incentivem os usuários a fazer streaming e download de obras protegidas por direitos autorais, incluindo músicas e vídeos, em violação a uma legislação de direitos autorais aplicável:

  
   

  ① A descrição nesta página "Detalhes do app" incentiva os usuários a fazer o download de conteúdo protegido por direitos autorais sem autorização.
  ② A captura de tela nesta página "Detalhes do app" incentiva os usuários a fazer o download de conteúdo protegido por direitos autorais sem autorização.

Violação de marca registrada

Apps que violem marcas registradas alheias não são permitidos. A marca registrada pode ser uma palavra, um símbolo ou uma combinação destes que identifique a origem de um produto ou serviço. Uma vez adquirida, a marca registrada oferece ao proprietário direitos exclusivos de uso da marca no que se refere a certos produtos ou serviços.

A violação de marca registrada se dá pelo uso indevido ou não autorizado de marca registrada idêntica ou semelhante de modo a confundir o usuário no que se refere à origem do produto. Se usar marcas registradas de terceiros de maneira que possa confundir o usuário, o app poderá ser suspenso.

Falsificação

Privacidade, fraude e uso indevido de dispositivos

Dados do usuário

Você precisa ser transparente sobre como lida com os dados do usuário (por exemplo, dados coletados do usuário ou sobre ele, incluindo informações do dispositivo). Isso significa divulgar o acesso, a coleta, o uso, o tratamento e o compartilhamento dos dados do usuário do seu app e limitar o uso dos dados às finalidades divulgadas em conformidade com a política. Qualquer tratamento de dados pessoais e sensíveis do usuário também está sujeito aos requisitos adicionais da seção "Dados pessoais e sensíveis do usuário" abaixo. Além dessas exigências do Google Play, é preciso seguir os requisitos prescritos pelas legislações de privacidade e proteção de dados aplicáveis.

Se você inclui código de terceiros, como, por exemplo, um SDK, no seu app, é necessário garantir que o código usado e as práticas do terceiro em relação aos dados do usuário do app obedeçam às Políticas do programa para desenvolvedores do Google Play, incluindo os requisitos de uso e divulgação. Por exemplo, você precisa garantir que os fornecedores de SDK não vendam os dados pessoais e sensíveis dos usuários do app. Esse requisito se aplica mesmo se a transferência dos dados do usuário for após o envio ao servidor ou ao incorporar código de terceiros no app.

Dados pessoais e sensíveis do usuário

Os dados pessoais e sensíveis de usuários incluem, entre outros, informações de identificação pessoal, financeiras e de pagamento; dados de autenticação; agenda; contatos; localização do dispositivo; dados de SMS e chamadas; dados de saúde; dados do Conexão Saúde; inventário de outros apps no dispositivo; conteúdo do microfone e da câmera; e outros dados sensíveis de uso ou do dispositivo. Caso seu app lide com dados pessoais e sensíveis de usuários, você precisa fazer o seguinte:

• Limite o acesso, a coleta, o uso e o compartilhamento de dados pessoais e sensíveis coletados pelo app à funcionalidade do app e do serviço e às finalidades que estão em conformidade com a política e atendem às expectativas do usuário.
  • Os apps que estendem o uso de dados pessoais e sensíveis do usuário para veiculação de anúncios precisam obedecer à política de anúncios do Google Play.
  • Você também pode transferir dados necessários para provedores de serviços ou por motivos legais, como obedecer a uma solicitação governamental válida, à legislação aplicável ou como parte de uma fusão ou aquisição com o aviso legalmente adequado aos usuários.
• Lide com todos os dados pessoais ou sensíveis de usuários de maneira segura, incluindo a transmissão desses dados com criptografia moderna, como HTTPS.
• Use uma solicitação de permissões de execução sempre que disponível, antes de acessar os dados controlados por permissões do Android.
• Não venda dados pessoais e sensíveis do usuário.
  • "Venda" significa a troca ou transferência de dados sensíveis e pessoais do usuário para um terceiro por compensação monetária.
    • A transferência de dados pessoais e sensíveis iniciada pelo usuário (por exemplo, quando o usuário está usando um recurso do app para transferir um arquivo a um terceiro ou quando o usuário escolhe usar um app de pesquisa de finalidade dedicada) não é considerada como venda.

Requisito de consentimento e divulgação em destaque

Quando o app acessar, coletar, usar ou compartilhar dados pessoais e sensíveis do usuário de maneira que não corresponda às expectativas do usuário do produto ou recurso em questão (por exemplo, se a coleta de dados ocorrer em segundo plano quando o usuário não está interagindo com o app), você precisa atender aos seguintes requisitos:

Divulgação em destaque: é necessário fornecer uma divulgação no app a respeito da coleta, do uso e do compartilhamento de dados. Essa divulgação:

• precisa estar dentro do próprio app, não somente na descrição dele ou em um site;
• precisa ser exibida no uso normal do app e não pode exigir que o usuário navegue até um menu ou até as configurações;
• precisa descrever os dados que são acessados ou coletados;
• precisa explicar como os dados serão usados e/ou compartilhados;
• não pode ser colocada somente na Política de Privacidade ou nos Termos de Serviço;
• não pode ser incluída em outras divulgações não relacionadas à coleta de dados pessoais e sensíveis de usuários.

Consentimento e permissões de execução: as solicitações de consentimento do usuário no app e de permissões de execução precisam ser imediatamente precedidas por uma divulgação no app que atende aos requisitos dessa política. Essa solicitação:

• precisa apresentar a caixa de diálogo de consentimento de uma maneira clara e inequívoca;
• precisa exigir do usuário uma ação de confirmação, como um toque para aceitar ou a marcação de uma caixa de seleção;
• não pode interpretar como consentimento o ato de fechar a divulgação e ir para outra tela (por exemplo, tocar na tela para sair ou pressionar os botões home ou "Voltar");
• não pode usar mensagens que expiram ou são dispensadas automaticamente como modo de receber o consentimento do usuário; e
• precisa ser concedida pelo usuário antes do app começar a coletar ou acessar os dados pessoais e sensíveis do usuário.

Os apps que contam com outros fundamentos jurídicos para tratar dados pessoais e sensíveis do usuário sem consentimento, como um interesse legítimo de acordo com o GDPR da UE, precisam obedecer a todos os requisitos legais aplicáveis e ter divulgações apropriadas aos usuários, incluindo no app, conforme exigido pela política.

Para atender aos requisitos da política, recomendamos que você use o modelo de divulgação em destaque a seguir quando necessário:

• "[O app] coleta/transmite/sincroniza/armazena [tipo de dados] para ativar ["recurso"], [em qual contexto]."
• Exemplo: "O Fitness Funds coleta dados de local para ativar o monitoramento de atividades físicas, mesmo quando o app está fechado ou não está em uso, e para veicular publicidade." 
• Exemplo: "O Call Buddy coleta dados de registro de chamadas de leitura e gravação para ativar o gerenciamento de contatos, mesmo quando o app não está em uso."

Se o app integrar código de terceiro, como, por exemplo, um SDK, feito para coletar dados pessoais e sensíveis do usuário por padrão, você precisa, até duas semanas após receber uma solicitação do Google Play (ou, se o pedido do Google Play oferecer um prazo mais longo, dentro desse período), oferecer evidência suficiente mostrando que o app obedece à solicitação de consentimento e declaração em destaque da política, incluindo em relação ao acesso, à coleta, ao uso ou ao compartilhamento de dados por código de terceiro.

Veja alguns exemplos de violações comuns:

• Um app que coleta a localização do dispositivo, mas não tem uma divulgação em destaque que explique qual recurso usa esses dados e/ou que indique o uso do app em segundo plano
• Um app com uma permissão de execução que solicita acesso aos dados antes de exibir a divulgação em destaque especificando para que as informações são usadas
• Um app que acessa o inventário de apps instalados do usuário e não trata essas informações como dados pessoais ou sensíveis sujeitos aos requisitos da Política de Privacidade, de tratamento de dados e de solicitação de consentimento e declaração em destaque
• Um app que acessa os dados do smartphone ou dos contatos de um usuário e não os trata como informações pessoais ou sensíveis sujeitas aos requisitos da Política de Privacidade, de tratamento de dados e de solicitação de consentimento e declaração em destaque
• Um app que registra a tela do usuário e não trata as informações como dados pessoais ou sensíveis sujeitos a essa política
• Um app que coleta a localização do dispositivo e não divulga de maneira detalhada o uso desses dados nem obtém o consentimento de acordo com os requisitos acima
• Um app que usa permissões restritas em segundo plano, inclusive para fins de rastreamento, pesquisa ou marketing, e não divulga de forma abrangente esse uso nem obtém consentimento de acordo com os requisitos acima
• Um app com um SDK que coleta informações pessoais e sensíveis do usuário e não as trata como sujeitas aos requisitos da política de dados do usuário, de acesso, de tratamento de dados (incluindo a proibição de venda) e de solicitação de consentimento e declaração em destaque

Consulte este artigo para saber mais sobre a solicitação de consentimento e declaração em destaque.

Restrições de acesso a dados pessoais e sensíveis

Além dos requisitos acima, a tabela abaixo descreve as obrigações para atividades específicas.

Seção "Segurança dos dados"

Todos os desenvolvedores precisam ter uma seção de segurança de dados clara e precisa em cada app, detalhando a coleta, o uso e o compartilhamento de dados do usuário. O desenvolvedor é responsável pela precisão do marcador e por manter as informações atualizadas. Quando relevante, essa seção precisa ser consistente com as divulgações feitas na Política de Privacidade do app.

Consulte este artigo para ver mais informações sobre como preencher a seção "Segurança dos dados".

Política de Privacidade

Todos os apps precisam incluir um link para a Política de Privacidade no campo designado no Play Console e outro link ou texto da política no próprio app. A Política de Privacidade e as declarações no app precisam descrever de maneira detalhada como o app acessa, coleta, usa e compartilha os dados do usuário, sem se limitar aos dados divulgados na seção "Segurança dos dados". Isso precisa incluir:

• informações sobre o desenvolvedor e um ponto de contato de privacidade ou mecanismo para o envio de consultas;
• a divulgação dos tipos de dados pessoais e sensíveis dos usuários que o app acessa, coleta, usa e compartilha, além de qualquer grupo com que esses dados são compartilhados;
• procedimentos seguros de tratamento de dados pessoais e sensíveis do usuário;
• a política de retenção e exclusão de dados do desenvolvedor;
• uma indicação clara do tipo de política (por exemplo, colocar "Política de Privacidade" no título).

A entidade (por exemplo, o desenvolvedor ou a empresa) indicada na página "Detalhes do app" da Google Play Store ou o nome do app precisa aparecer na Política de Privacidade. Apps que não acessam dados pessoais e sensíveis de usuários também precisam enviar uma Política de Privacidade.

Sua política precisa estar disponível de forma não editável em um URL ativo, publicamente acessível e sem fronteira geográfica virtual. Não use PDFs.

Requisito de exclusão de contas

Se o app permite que os usuários criem uma conta, também precisa permitir que eles solicitem a exclusão dela. Os usuários precisam ter uma opção facilmente identificável para iniciar a exclusão da conta de dentro do app ou fora dele, por exemplo, acessando seu site. É necessário inserir um link para esse recurso da Web no campo de formulário de URL designado no Play Console.

Ao excluir uma conta do app com base na solicitação de um usuário, também é preciso excluir os dados do usuário associados a essa conta. O "congelamento" ou a desativação temporária da conta não se qualifica como exclusão. Se for necessário reter determinados dados por motivos legítimos, como segurança, prevenção de fraudes ou compliance regulatória, você precisará informar claramente aos usuários sobre suas práticas de retenção de dados (por exemplo, na sua Política de Privacidade).

Uso do ID definido pelo app

O Android apresentará um novo ID para oferecer compatibilidade com casos de uso essenciais, como análise e prevenção de fraudes. Os termos para o uso desse ID estão disponíveis abaixo.

• Uso: o ID definido pelo app não pode ser usado para personalização e avaliação de anúncios.
• Associação com informações de identificação pessoal ou outros identificadores: o ID do conjunto de apps não pode ser conectado a outros identificadores do Android (por exemplo, AAID) ou a dados pessoais e sensíveis para fins publicitários.
• Transparência e consentimento: a coleta e o uso do ID definido pelo app e o compromisso com estes termos precisam ser divulgados aos usuários em uma notificação de privacidade legalmente adequada, incluindo na sua Política de Privacidade. É necessário receber o consentimento legalmente válido dos usuários quando necessário. Para saber mais sobre nossos padrões de privacidade, consulte a política de Dados do usuário.

EU-U.S. Privacy Shield (Escudo de Proteção da Privacidade entre os Estados Unidos e a União Europeia) e Swiss-U.S. Privacy Shield (Escudo de Proteção da Privacidade entre os Estados Unidos e a Suíça)

Se você acessar, usar ou tratar informações pessoais disponibilizadas pelo Google que identificarem direta ou indiretamente um indivíduo e tiverem origem na União Europeia ou na Suíça ("Informações pessoais da UE"), será preciso:

• agir em conformidade com todos os regulamentos, legislação, regras e diretrizes referentes à privacidade, segurança e proteção de dados;
• acessar, usar ou processar as informações pessoais da UE somente para fins compatíveis com o consentimento recebido do indivíduo relacionado a esses dados;
• implementar medidas técnicas e organizacionais adequadas para proteger as informações pessoais da UE contra perda e uso indevido, assim como divulgação, alteração, destruição ou acesso não autorizados ou ilegais;
• fornecer o nível de proteção exigido pelos Princípios do Privacy Shield (Escudo de Proteção da Privacidade).

Você deverá monitorar a conformidade com essas condições regularmente. Se em algum momento você não atender a essas condições ou se houver uma grande possibilidade de isso acontecer, notifique nossa equipe imediatamente enviando um e-mail para [email protected]. Além disso, interrompa o tratamento de informações pessoais da UE ou tome medidas razoáveis e apropriadas para restabelecer um nível adequado de proteção.

Desde 16 de julho de 2020, o Google não usa mais o EU-U.S. Privacy Shield (Escudo de Proteção da Privacidade entre os Estados Unidos e a União Europeia) para transferir dados pessoais originados no Espaço Econômico Europeu ou no Reino Unido para os Estados Unidos. Saiba mais. Veja outras informações na Seção 9 do Contrato de distribuição do desenvolvedor (DDA, na sigla em inglês).

Permissões e APIs que acessam informações sensíveis

As solicitações de permissões e de APIs que acessam informações sensíveis precisam fazer sentido para os usuários. O app só pode solicitar permissões e APIs que acessam informações sensíveis necessárias para implementar recursos ou serviços atuais promovidos na página "Detalhes do app". Não use permissões ou APIs que acessam informações sensíveis com acesso a dados do usuário ou do dispositivo para finalidades ou recursos não revelados, não implementados ou não permitidos. Dados pessoais ou sensíveis acessados por permissões ou APIs que acessam informações sensíveis não podem ser vendidos nem compartilhados com a finalidade de facilitar uma venda.

Solicite permissões e APIs que acessam informações sensíveis para acessar dados de acordo com o contexto (via solicitações incrementais). Isso ajuda os usuários a entender por que a permissão é necessária. Use os dados somente para as finalidades consentidas pelo usuário. Posteriormente, se você quiser usar os dados para outros fins, será necessário pedir permissão aos usuários e receber a confirmação deles para os usos adicionais.

Permissões restritas

Além do indicado acima, as permissões restritas são aquelas designadas como perigosas, especiais,  de assinatura ou conforme documentado abaixo. Elas estão sujeitas aos seguintes requisitos e restrições adicionais:

• Os dados do dispositivo ou do usuário acessados por permissões restritas são considerados dados pessoais e sensíveis do usuário. Os requisitos da política de dados do usuário se aplicam.
• Respeite a decisão dos usuários se eles recusarem uma solicitação de permissão restrita. Eles não podem ser manipulados nem forçados a consentir com permissões que não sejam essenciais. Faça o possível para atender os usuários que não concedem acesso a permissões confidenciais. Por exemplo, você pode permitir que o usuário insira manualmente um número de telefone, caso ele tenha restringido o acesso aos registros de chamadas.
• É expressamente proibido usar permissões que violam as políticas de malware do Google Play, o que inclui o abuso de privilégios elevados.

Algumas permissões restritas podem estar sujeitas a requisitos adicionais, conforme detalhado abaixo. O objetivo dessas restrições é proteger a privacidade do usuário. Podemos fazer exceções limitadas aos requisitos abaixo em casos muito raros em que os apps fornecem um recurso de alto interesse ou essencial ao usuário sem que haja algum método alternativo disponível para isso. Avaliamos as exceções propostas em relação aos possíveis efeitos sobre a privacidade ou segurança dos usuários.

Permissões de SMS e registro de chamadas

As permissões de SMS e registro de chamadas são consideradas dados pessoais e sensíveis de usuários sujeitos à política de Informações pessoais e sensíveis e às seguintes restrições:

Apps sem o recurso de gerenciador padrão de "SMS", "Telefone" ou "Assistente" não podem declarar o uso das permissões acima no manifesto. Isso inclui o uso de texto marcador no manifesto. Os apps também precisam estar ativamente registrados como gerenciador padrão de "SMS", do "Telefone" ou do "Assistente" antes de solicitar que os usuários aceitem uma das permissões acima. Além disso, eles precisarão interromper imediatamente o uso da permissão quando não forem mais o gerenciador padrão. Os usos permitidos e exceções estão disponíveis nesta página da Central de Ajuda.

Os apps só podem usar a permissão e os dados derivados dela para fornecer a funcionalidade principal aprovada do app, que corresponde ao propósito principal dele. Isso pode incluir um conjunto de recursos principais que precisam ser documentados e promovidos com maior destaque na descrição do app. Sem os recursos principais, o app ficará "corrompido" ou não poderá ser usado. A transferência, o compartilhamento ou o uso licenciado desses dados só pode ocorrer para fornecer os recursos principais ou serviços dentro do app. Além disso, o uso dessas informações não pode ser estendido para outras finalidades (por exemplo, melhorar outros apps e serviços ou para fins de marketing e publicidade). Não é permitido usar métodos alternativos (incluindo outras permissões, APIs ou fontes de terceiros) para extrair dados atribuídos às permissões de registro de chamadas ou SMS.

Permissões de localização

A localização do dispositivo é considerada um dado pessoal e sensíveis do usuário, sujeita às políticas de Informações pessoais e sensíveis e Localização em segundo plano e aos seguintes requisitos:

• Os apps não podem acessar dados protegidos por permissões de localização (por exemplo, ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_BACKGROUND_LOCATION) que não sejam mais necessários para fornecer os recursos ou serviços atuais.
• Nunca solicite permissões de localização do usuário somente para fins de publicidade ou análise. Os apps que aproveitam o uso permitido desses dados para exibir publicidade precisam estar em conformidade com nossa política de Anúncios.
• Os apps precisam solicitar o escopo mínimo necessário (ou seja, localização aproximada em vez de exata e em primeiro plano em vez de segundo plano) para fornecer o recurso ou serviço atual que exige a localização. Além disso, os usuários devem esperar que o recurso ou serviço precise acessar o nível de localização solicitado. Por exemplo, podemos recusar apps que solicitam ou acessam o local em segundo plano sem uma justificativa convincente.
• A localização em segundo plano só pode ser usada para oferecer recursos úteis aos usuários e relevantes para a funcionalidade principal do app.

Os apps terão permissão para acessar a localização com o serviço em primeiro plano (quando o app só tem acesso em primeiro plano, por exemplo, "durante o uso") se o uso:

• tiver sido iniciado para dar continuidade a uma ação do usuário no app; e
• for finalizado imediatamente após o app concluir o caso de uso pretendido pelo usuário.

Os apps desenvolvidos especificamente para crianças precisam estar em conformidade com a política do Feito para Família.

Para saber mais sobre os requisitos da política, confira este artigo de ajuda.

Permissão de acesso a todos os arquivos

Os arquivos e atributos de diretório no dispositivo de um usuário são considerados dados pessoais e sensíveis dele e estão sujeitos à política de informações pessoais e sensíveis e aos seguintes requisitos:

• Os apps só podem solicitar acesso ao armazenamento dos dispositivos que seja fundamental para o funcionamento. Eles não podem fazer isso em nome de terceiros para fins não relacionados à funcionalidade principal do app para o usuário.
• Os dispositivos Android com a versão R ou mais recente precisarão da permissão MANAGE_EXTERNAL_STORAGE para gerenciar o acesso no armazenamento compartilhado. Todos os apps direcionados ao R que solicitam acesso amplo ao armazenamento compartilhado ("Acesso a todos os arquivos") precisam passar por uma análise de acesso apropriada antes da publicação. Os apps que podem usar essa permissão precisam solicitar claramente que os usuários ativem a opção "Acesso a todos os arquivos" nas configurações de "Acesso especial ao app". Para saber mais sobre os requisitos do R, confira este artigo de ajuda.

Permissão de visibilidade do pacote (app)

O inventário dos apps instalados consultados em um dispositivo são considerados dados pessoais e sensíveis, sujeitos à política de Informações pessoais e sensíveis e aos seguintes requisitos:

Os apps que têm a finalidade principal de lançar, pesquisar ou interoperar com outros apps podem ter visibilidade do escopo apropriado para outros apps instalados no dispositivo, conforme descrito abaixo:

• Ampla visibilidade do app: é a capacidade de um app de ter uma visibilidade extensa (ou "ampla") dos apps instalados ("pacotes") em um dispositivo.
  • Para apps destinados à API de nível 30 ou mais recente, a visibilidade ampla para apps instalados com a permissão QUERY_ALL_PACKAGES é restrita a casos de uso específicos em que o reconhecimento e/ou interoperabilidade com qualquer um ou todos os apps no dispositivo são necessários para que ele funcione. 
    • Não será possível usar QUERY_ALL_PACKAGES se o app puder operar com uma declaração de visibilidade do pacote com escopo segmentado. Por exemplo, consultar e interagir com pacotes específicos em vez de solicitar uma visibilidade ampla.
  • O uso de métodos alternativos para aproximar o nível de visibilidade ampla associado à permissão QUERY_ALL_PACKAGES também está restrito à funcionalidade principal do app apresentada para o usuário e à interoperabilidade com todos os apps descobertos por esse método.
  • Consulte este artigo da Central de Ajuda e veja os casos autorizados para o uso da permissão QUERY_ALL_PACKAGES.
• Visibilidade limitada do app: quando um app minimiza o acesso aos dados, ao consultar apps específicos usando métodos mais segmentados (em vez de "amplos"). Por exemplo, consultar apps específicos que atendam à declaração do manifesto do app. É possível usar esse método para consultas nos casos em que o app tenha interoperabilidade em conformidade com a política ou gerenciamento desses apps.
• A visibilidade do inventário de apps instalados em um dispositivo precisa estar diretamente relacionada à finalidade ou funcionalidade principal que os usuários acessam no app.

Os dados de inventário de apps consultados nos apps distribuídos no Google Play nunca poderão ser vendidos nem compartilhados para análise ou monetização de anúncios.

API de acessibilidade

A API de acessibilidade não pode ser usada para:

• mudar as configurações do usuário sem permissão ou impedir que ele desative ou desinstale qualquer app ou serviço, a menos que autorizado pela família ou responsável com um app de controle dos pais ou por administradores autorizados com um software de gerenciamento empresarial;
• evitar os controles e as notificações de privacidade integrados do Android;
• mudar ou usar a interface do usuário de maneira enganosa ou que viole as Políticas para desenvolvedores do Google Play.

A API de acessibilidade não foi projetada e não pode ser solicitada para gravação de áudio de chamadas remotas.

O uso da API de acessibilidade precisa ser documentado na página "Detalhes do app".

Diretrizes para IsAccessibilityTool

Os apps com funcionalidades básicas destinadas a oferecer apoio direto às pessoas com deficiências estão qualificados para usar o IsAccessibilityTool e, assim, se autodesignar publicamente como "app de acessibilidade".

Os apps sem qualificação para usar o IsAccessibilityTool não podem incorporar o sinalizador e precisam atender aos requisitos de consentimento e divulgação em destaque conforme descrito na política de Dados do usuário já que o recurso relacionado à acessibilidade não é óbvio para o usuário. Consulte o artigo da Central de Ajuda API AccessibilityService para mais informações.

Quando possível, os apps precisam usar APIs e permissões com escopos mais limitados em vez da API de acessibilidade para alcançar a funcionalidade desejada.

Permissão "solicitar pacotes de instalação"

Com a permissão REQUEST_INSTALL_PACKAGES, um app pode solicitar a instalação de pacotes de apps.​​ Para usar essa permissão, a funcionalidade principal do app precisa incluir as seguintes funções:

• Envio ou recebimento de pacotes de apps; e
• Instalação de pacotes de apps iniciada pelo usuário

As funcionalidades permitidas incluem as seguintes opções:

• Pesquisa ou navegação na Web
• Serviços de comunicação compatíveis com anexos
• Compartilhamento, transferência ou gerenciamento de arquivos
• Gerenciamento de dispositivos corporativos
• Backup e restauração
• Migração do dispositivo/transferência do smartphone
• App complementar para sincronizar o smartphone com um wearable ou dispositivo de IoT, como um smartwatch ou uma smart TV

A funcionalidade principal é definida como o objetivo principal do app. Essa função e todos os recursos essenciais que a compõem precisam ser documentados e promovidos com destaque na descrição do app.

Permissões do Health Connect by Android

Conexão Saúde é uma plataforma Android que permite que apps de saúde e fitness armazenem e compartilhem os mesmos dados no dispositivo, em um ecossistema unificado. Ela também oferece um local único para os usuários controlarem quais aplicativos podem ler e gravar esses dados. O app Conexão Saúde é compatível com leitura e gravação de vários tipos de dados, de passos à temperatura corporal.

As informações acessadas com as permissões da plataforma são consideradas dados pessoais e sensíveis do usuário. Elas estão sujeitas à política de dados do usuário. Caso seu app seja qualificado como um app de saúde ou tenha funcionalidades relacionadas à saúde e acesse dados dessa natureza, como os do app Conexão Saúde, ele precisará obedecer à Política de apps de saúde.

Consulte este guia para desenvolvedores Android sobre como começar a usar o app Conexão Saúde. Para pedir acesso aos tipos de dados do Conexão Saúde, clique neste link.

Os apps distribuídos pelo Google Play precisam atender aos requisitos da política seguinte para ler e/ou gravar dados no Conexão Saúde.

Acesso e uso adequados do Conexão Saúde

O app Conexão Saúde só pode ser usado de acordo com as políticas, Termos e Condições aplicáveis para casos de uso aprovados, conforme estabelecido nesta política. Portanto, apenas os apps ou serviços que atendam a um dos casos de uso aprovados podem pedir acesso às permissões.

Os casos de uso aprovados incluem: condicionamento físico e bem-estar, recompensas, coaching de condicionamento físico, bem-estar corporativo, cuidados médicos, pesquisa em saúde e jogos.

Somente aplicativos ou serviços com um ou mais recursos projetados para beneficiar a saúde e o condicionamento físico dos usuários podem pedir acesso às permissões do app Conexão Saúde. Eles incluem:

• Aplicativos ou serviços que permitem aos usuários registrar, gerar relatórios, monitorar e/ou analisar diretamente informações sobre atividades físicas, sono, bem-estar mental, nutrição, medidas de saúde, descrições físicas e/ou outros dados e medições relacionados à saúde ou condicionamento físico.
• Aplicativos ou serviços que permitem aos usuários armazenar informações sobre atividades físicas, sono, bem-estar mental, nutrição, medidas de saúde, descrições físicas e/ou outros dados e medições relacionados à saúde ou ao condicionamento físico no dispositivo.

O acesso ao app Conexão Saúde não pode ser usado para violar esta política, ou outros Termos e Condições, ou políticas aplicáveis da plataforma, inclusive para as seguintes finalidades:

• Não use o app Conexão Saúde para desenvolver outro app. Ele tampouco deve ser incorporado em qualquer app, ambiente ou atividade em que seu uso ou falha possa levar à morte, lesões corporais ou danos ambientais ou patrimoniais, como a criação ou operação de instalações nucleares, controle de tráfego aéreo, sistemas de suporte à vida ou armamentos.
• Não acesse dados coletados pelo app Conexão Saúde usando aplicativos headless. É preciso exibir um ícone claramente identificável na bandeja, nas configurações do app no dispositivo, nos ícones de notificação etc.
• Não use o app Conexão Saúde com aplicativos que sincronizam dados entre dispositivos ou plataformas incompatíveis.
• Não use o app Conexão Saúde para se conectar a aplicativos, serviços ou recursos direcionados exclusivamente a crianças.
• Tome medidas razoáveis e apropriadas para que todos os aplicativos ou sistemas que usam o app Conexão Saúde sejam protegidos contra acesso, uso, destruição, perda, mudança ou divulgação não autorizados ou ilegais.

Também é sua responsabilidade garantir a conformidade com requisitos regulamentares ou legais aplicáveis com base no uso pretendido do app Conexão Saúde e dos dados dessa plataforma. Exceto conforme expressamente indicado na embalagem ou nas informações fornecidas pelo Google referentes a produtos ou serviços específicos, o Google não endossa o uso nem garante a precisão dos dados do app Conexão Saúde para qualquer caso ou finalidade, principalmente para uso médico, de pesquisa ou de saúde. O Google se isenta de qualquer responsabilidade associada ao uso de dados coletados no app Conexão Saúde.

Uso limitado

Ao usar o app Conexão Saúde, o acesso e uso dos dados devem obedecer a limitações específicas:

• O uso de dados deve ser limitado ao fornecimento ou melhoria do caso de uso apropriado ou dos recursos visíveis na interface do usuário do aplicativo.
• Os dados do usuário só podem ser transferidos a terceiros com o consentimento explícito do usuário, para fins de segurança (por exemplo, investigação de abusos), para obedecer às leis ou regulamentações aplicáveis, ou como parte de fusões/aquisições.
• O acesso humano aos dados do usuário é restrito, a menos que haja consentimento explícito do usuário, para fins de segurança, para obedecer às leis ou quando agregados para operações internas de acordo com requisitos legais.
• Todas as outras transferências, usos ou vendas de dados do app Conexão Saúde são proibidos, incluindo o seguinte:
  • Transferir ou vender dados do usuário para terceiros, como plataformas de publicidade, corretores de dados ou revendedores de informações.
  • Transferir, vender ou usar dados do usuário para veicular anúncios, incluindo publicidade personalizada ou baseada em interesses.
  • Transferir, vender ou usar dados do usuário para determinar classificações de crédito ou para finalidades de empréstimo.
  • Transferir, vender ou usar dados do usuário com qualquer produto ou serviço que possa se qualificar como dispositivo médico, a menos que o app do dispositivo médico obedeça a todas as regulamentações, inclusive obtendo todas as liberações ou aprovações dos órgãos regulamentares relevantes (por exemplo, a FDA, equivalente à ANVISA dos EUA) para o uso pretendido dos dados do app Conexão Saúde, e o usuário tenha dado consentimento explícito para isso.
  • Transferir, vender ou usar dados do usuário para qualquer finalidade ou de qualquer maneira que envolva Informações protegidas de saúde (conforme definido pela HIPAA), a menos que você receba aprovação prévia por escrito do Google para tal uso.

Escopo mínimo

Solicite acesso somente às permissões necessárias para implementar os recursos e serviços do seu produto. Esses pedidos devem ser específicos e se limitar aos dados necessários.

Avisos e controles transparentes e precisos

O Conexão Saúde gerencia dados de saúde e condicionamento físico, inclusive informações sensíveis, e obriga que todos os aplicativos tenham uma Política de Privacidade abrangente. Essa política deve declarar de maneira transparente como o app coleta, usa e compartilha os dados do usuário. Além dos requisitos legais, os desenvolvedores precisam ter as seguintes informações na Política de Privacidade:

• Descrição exata da identidade do app, esclarecendo os dados acessados e a conexão deles com os recursos e recomendações em destaque do app
• Práticas de retenção e exclusão de dados
• Procedimentos de processamento de dados (por exemplo, transmissão por criptografia moderna, como HTTPS)

Gerenciamento seguro dos dados

Todos os dados do usuário precisam ser processados de maneira segura. Tome medidas razoáveis e apropriadas para que todos os apps ou sistemas que usam o Health Connect sejam protegidos contra acesso, uso, destruição, perda, alteração ou divulgação não autorizados ou ilegais.

As práticas de segurança recomendadas incluem a implementação e manutenção de um sistema de gerenciamento de segurança da informação, conforme descrito na ISO/IEC 27001, além de medidas para garantir que o app ou serviço da Web seja robusto e livre de problemas comuns de segurança, como estabelecido pela OWASP Top 10.

Dependendo da API acessada e do número de usuários, exigimos que o aplicativo ou serviço passe por uma avaliação de segurança periódica e receba uma carta de avaliação de um terceiro designado, caso o produto transfira dados do dispositivo do usuário.

Serviço VPN

VpnService é uma classe de base para que os apps ampliem e criem soluções de VPN próprias. Somente os apps que usam VpnService e têm a VPN como recurso principal podem criar um encapsulamento seguro no nível do dispositivo para um servidor remoto. Exceções incluem apps que exigem um servidor remoto para oferecer o recurso principal, por exemplo:

• Apps de controle da família e gerenciamento empresarial
• Monitoramento de uso de apps
• Apps de segurança de dispositivos, como antivírus, gerenciamento de dispositivos móveis e firewall
• Ferramentas relacionadas à rede, como acesso remoto
• Apps de navegação na Web
• Apps de operadoras que precisam de funcionalidade VPN para oferecer serviços de telefonia ou conectividade

O VpnService não pode ser usado para:

• coletar dados pessoais e confidenciais do usuário sem consentimento e declaração em destaque;
• redirecionar ou manipular o tráfego de usuários de outros apps em um dispositivo para fins de monetização, por exemplo: redirecionar o tráfego de publicidade para um país que não seja o do usuário;

Os apps que usam o VpnService precisam:

• documentar o uso dessa classe na página "Detalhes do app";
• criptografar os dados do dispositivo para o endpoint do encapsulamento de VPN;
• obedecer a todas as Políticas do programa para desenvolvedores, incluindo as relacionadas a fraude de anúncio, permissões e malware.

Permissão de alarme exato

A nova permissão USE_EXACT_ALARM vai ser introduzida para dar acesso à funcionalidade de alarme exato em apps a partir do Android 13 (nível desejado da API 33).

USE_EXACT_ALARM é uma permissão restrita, e os apps só deverão declará-la se o recurso principal deles for compatível com a necessidade de um alarme exato. Os apps que solicitam essa permissão restrita estão sujeitos a revisão, e aqueles que não atenderem aos critérios de caso de uso aceitável não vão ser publicados no Google Play.

Casos de uso aceitáveis para a permissão de alarme exato

Seu app só deverá usar a funcionalidade USE_EXACT_ALARM quando o recurso principal dele voltado para o usuário exigir ações com tempo preciso, por exemplo:

• Apps de alarme ou cronômetro
• Apps de calendário que exibem notificações de eventos

Se seu caso de uso para a funcionalidade de alarme exato não estiver listado acima, avalie a possibilidade de usar SCHEDULE_EXACT_ALARM.

Permissão de intent para tela cheia

Para apps destinados ao Android 14 (nível desejado da API 34) e versões mais recentes, a USE_FULL_SCREEN_INTENT é uma permissão de acesso especial para apps. A permissão USE_FULL_SCREEN_INTENT só será concedida de modo automático se a funcionalidade principal do app se enquadrar em uma das categorias abaixo que requerem notificações de alta prioridade:

• definir um alarme
• receber ligações ou videochamadas

Os apps que solicitam essa permissão estão sujeitos a um processo de análise, e aqueles que não atenderem aos critérios descritos acima não receberão a permissão por padrão. Nesse caso, para usar a USE_FULL_SCREEN_INTENT, os apps precisarão solicitar a permissão do usuário.

O uso da permissão USE_FULL_SCREEN_INTENT precisa obedecer às políticas para desenvolvedores do Google Play, incluindo nossas diretrizes sobre software indesejado para dispositivos móveis, abuso de dispositivos e de rede e anúncios. As notificações de intent para tela cheia não podem interferir, interromper, danificar nem acessar o dispositivo do usuário de maneira não autorizada. Além disso, os apps não podem interferir em outros apps nem na usabilidade do dispositivo.

Saiba mais sobre a permissão USE_FULL_SCREEN_INTENT na nossa Central de Ajuda.

Abuso de dispositivos e de rede

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.

Veja alguns exemplos de violações comuns:

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

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.

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.

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.

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

• 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.

Comportamento enganoso

Declarações enganosas

Veja alguns exemplos de violações comuns:

• Apps que deturpem a funcionalidade ou que não a descrevam clara e precisamente:
  • Um app que alega ser um jogo de corrida na descrição e nas capturas de tela, mas na verdade é um quebra-cabeças usando a imagem de um carro
  • Um app que alega ser um antivírus, mas contém somente um manual explicando como remover vírus
• Apps que alegam ter funcionalidades impossíveis de serem implementadas (por exemplo, apps repelentes de insetos), mesmo que sejam representados como pegadinhas, dissimulações, piadas etc.
• Apps categorizados incorretamente, incluindo, mas não se limitando a, classificação ou categoria do app
• Conteúdo comprovadamente falso ou enganoso que pode interferir nos processos de votação ou nos resultados de eleições
• Apps que alegam falsamente afiliação a uma entidade governamental ou afirmam fornecer ou facilitar serviços públicos sem a devida autorização
• Apps que alegam falsamente ser o app oficial de uma entidade estabelecida (títulos como "App oficial do Justin Bieber" não são permitidos sem os direitos ou as permissões necessárias)

(1) O app faz declarações médicas ou relacionadas à saúde (cura do câncer) que são enganosas.
(2) O app alega ter funções impossíveis de serem implementadas (usar o smartphone como bafômetro).

Alterações enganosas nas configurações do dispositivo

Apps que façam alterações nas configurações do dispositivo ou em recursos fora do app sem o conhecimento e consentimento do usuário não são permitidos. As configurações e os recursos do dispositivo incluem configurações do sistema e do navegador, favoritos, atalhos, ícones e widgets, além da apresentação de apps na tela inicial.

Além disso, não são permitidos:

• Apps que modifiquem as configurações ou os recursos de um dispositivo com o consentimento do usuário, mas de maneira que não possa ser revertida facilmente
• Apps ou anúncios que modifiquem as configurações ou os recursos do dispositivo, como um serviço para terceiros ou para fins de publicidade
• Apps que induzam os usuários a remover ou desativar apps de terceiros ou modificar configurações ou recursos do dispositivo
• apps que incentivem os usuários a remover ou desativar apps de terceiros ou modificar configurações ou recursos do dispositivo, a menos que sejam parte de um serviço de segurança verificável.

Permitir comportamento desonesto

Não são permitidos apps que ajudem os usuários a enganar outras pessoas ou com funcionamento enganoso de alguma forma, incluindo, entre outros, apps que gerem ou facilitem a geração de RGs, CPFs, passaportes, diplomas, cartões de crédito, contas bancárias e carteiras de motorista. É necessário apresentar informações precisas em divulgações, títulos, descrições e imagens/vídeos relacionados à função e/ou ao conteúdo do app. Além disso, o desempenho e a precisão devem atender à expectativa do usuário.

O download de recursos adicionais do app (por exemplo, recursos de jogos) só poderá ser feito se eles forem necessários para usar o app. Os recursos salvos precisam obedecer a todas as políticas do Google Play e, antes de iniciar o download, é obrigatório fazer uma solicitação ao usuário e informar claramente o tamanho do app.

A declaração do app como uma "brincadeira", "para fins de entretenimento" ou outro sinônimo não o isenta da aplicação das nossas políticas.

Veja alguns exemplos de violações comuns:

• Apps que imitam outros aplicativos ou sites para induzir os usuários a divulgar informações pessoais ou de autenticação
  • Apps que retratam ou exibem números de telefone, contatos, endereços ou informações que permitam identificar uma pessoa, sejam elas não confirmadas ou reais, de pessoas ou entidades sem o consentimento delas
• Apps com funcionalidade principal diferente com base na região geográfica, nos parâmetros do dispositivo ou em outros dados dependentes do usuário em que essas diferenças não são divulgadas em destaque para o usuário na página "Detalhes do app"
• Apps que mudam significativamente entre as versões sem alertar o usuário (por exemplo, a seção "Novidades") e atualizar a página "Detalhes do app"
• Apps que tentam modificar ou ofuscar o comportamento durante a revisão
• Apps com downloads facilitados por rede de fornecimento de conteúdo (CDN) quando não há uma solicitação ao usuário antes de começar nem é informado o tamanho do download

Mídia manipulada

Não são permitidos apps que promovam ou ajudem a criar informações falsas ou enganosas veiculadas em imagens, áudios, vídeos e/ou textos. Não são aceitos apps desenvolvidos para promover ou perpetuar imagens, vídeos e/ou textos comprovadamente enganosos ou que possam causar danos relacionados a eventos sensíveis, política, questões sociais ou outras questões de interesse público.

Apps que manipulem ou modifiquem mídia (além dos ajustes convencionais e aceitáveis em termos editoriais por questões de clareza e qualidade) precisam informar ou usar uma marca-d'água na mídia cuja modificação talvez não seja facilmente detectada pelas pessoas em geral. Pode haver exceções em caso de interesse público e de sátiras ou paródias óbvias.

Veja alguns exemplos de violações comuns:

• Apps que adicionam uma figura pública a uma manifestação durante um evento politicamente sensível.
• Apps que usam figuras públicas ou mídia de eventos sensíveis para promover o recurso de modificação de mídia na página "Detalhes do app".
• Apps que alteram clipes de mídia para imitar a transmissão de notícias.
  

  (1) O app oferece funcionalidades para alterar clipes de mídia para imitar uma transmissão de notícias e adicionar pessoas famosas ou públicas ao clipe sem uma marca d'água.

Transparência em relação ao comportamento

Declarações falsas

Não são permitidos apps nem contas de desenvolvedor que:

• se façam passar por outra pessoa ou organização ou que deturpem ou ocultem a propriedade ou o objetivo principal;
• se envolvam em atividades coordenadas para enganar os usuários. Isso inclui, entre outros, apps ou contas que deturpam ou ocultam o país de origem ou que direcionam conteúdo para usuários em outros países;
• se coordenem com outros apps, sites, desenvolvedores ou contas para ocultar ou fazer declarações falsas sobre a identidade do app ou do desenvolvedor ou outros detalhes relevantes, caso o conteúdo do app se relacione a política, questões sociais ou assuntos de interesse público.

Política de nível desejado da API do Google Play

Para proteger os usuários, o Google Play exige os seguintes níveis da API para todos os apps:

Novos apps e atualizações PRECISAM ser voltados para um nível da API do Android com no máximo um ano de diferença em relação à versão mais recente. Se esse requisito não for atendido, não vai ser possível enviar o app ou a atualização no Play Console.

Os apps que já estão no Google Play, mas não foram atualizados e que não forem voltados para um nível de API com no máximo dois anos de diferença em relação à versão mais recente do Android não vão estar disponíveis para novos usuários com versões mais recentes do Android no dispositivo.Quem já tiver feito a instalação no Google Play ainda vai conseguir encontrar, reinstalar e usar o app em qualquer versão do Android compatível com ele.

Para orientações técnicas sobre como atender ao requisito de nível desejado da API, consulte o guia de migração.

Requisitos de SDK

Os desenvolvedores geralmente dependem de código de terceiros (por exemplo, SDKs) para integrar funcionalidades e serviços importantes aos apps. Ao incluir um SDK no seu app, é importante manter os usuários seguros e o app protegido contra vulnerabilidades. Nesta seção, demonstramos como alguns dos nossos requisitos de privacidade e segurança se aplicam ao contexto do SDK e são projetados para ajudar os desenvolvedores a integrar SDKs aos apps com segurança.

Ao incluir um SDK no seu app, você é responsável por garantir que o código e as práticas de terceiros não façam o app violar as Políticas do programa para desenvolvedores do Google Play. É importante entender como os SDKs no app lidam com os dados do usuário e saber quais permissões eles usam, quais dados eles coletam e por quê.  Lembre-se de que a coleta e o manuseio de dados do usuário por um SDK precisam estar alinhados com o uso desses dados em conformidade com a política do app.

Para garantir que o uso de um SDK não viole os requisitos da política, leia e entenda as seguintes políticas na íntegra e observe os requisitos relativos a SDKs abaixo:

Política de dados do usuário

Você precisa ser transparente sobre como lida com os dados do usuário (por exemplo, dados coletados do usuário ou sobre ele, incluindo informações do dispositivo). Isso significa divulgar o acesso, a coleta, o uso, o tratamento e o compartilhamento dos dados do usuário do seu app e limitar o uso dos dados às finalidades divulgadas em conformidade com a política.

Se você inclui código de terceiros, como um SDK, no seu app, é necessário garantir que o código usado e as práticas do terceiro em relação aos dados do usuário do app obedeçam às Políticas do programa para desenvolvedores do Google Play, incluindo os requisitos de uso e divulgação. Por exemplo, você precisa garantir que os fornecedores de SDK não vendam os dados pessoais e sensíveis dos usuários do app. Esse requisito se aplica mesmo se a transferência dos dados do usuário for após o envio ao servidor ou ao incorporar código de terceiros no app.

Política de permissões e APIs que acessam informações sensíveis

As solicitações de permissões e de APIs que acessam informações sensíveis precisam fazer sentido para os usuários. O app só pode solicitar permissões e APIs que acessam informações sensíveis necessárias para implementar recursos ou serviços atuais promovidos na página "Detalhes do app". Não use permissões ou APIs que acessam informações sensíveis com acesso a dados do usuário ou do dispositivo para finalidades ou recursos não revelados, não implementados ou não permitidos. Dados pessoais ou sensíveis acessados por permissões ou APIs que acessam informações sensíveis não podem ser vendidos nem compartilhados com a finalidade de facilitar uma venda.

Consulte a Política de permissões e APIs que acessam informações sensíveis.

Exemplos de violações causadas pelo SDK

• O app inclui um SDK que solicita a localização em segundo plano para uma finalidade não permitida ou não divulgada. 
• O app inclui um SDK que transmite IMEI derivado da permissão read_phone_state do Android sem o consentimento do usuário.

Política de malware

Uso de SDKs Em Apps

Ao incluir um SDK no seu app, você é responsável por garantir que o código e as práticas de terceiros não façam o app violar as Políticas do programa para desenvolvedores do Google Play. É importante entender como os SDKs no app lidam com os dados do usuário e saber quais permissões eles usam, quais dados eles coletam e por quê.

Requisitos de SDK

Os desenvolvedores geralmente dependem de código de terceiros (por exemplo, SDKs) para integrar funcionalidades e serviços importantes aos apps. Ao incluir um SDK no seu app, é importante manter os usuários seguros e o app protegido contra vulnerabilidades. Nesta seção, demonstramos como alguns dos nossos requisitos de privacidade e segurança se aplicam ao contexto do SDK e são projetados para ajudar os desenvolvedores a integrar SDKs aos apps com segurança.

Ao incluir um SDK no seu app, você é responsável por garantir que o código e as práticas de terceiros não façam o app violar as Políticas do programa para desenvolvedores do Google Play. É importante entender como os SDKs no app lidam com os dados do usuário e saber quais permissões eles usam, quais dados eles coletam e por quê.  Lembre-se de que a coleta e o manuseio de dados do usuário por um SDK precisam estar alinhados com o uso desses dados em conformidade com a política do app.

Para garantir que o uso de um SDK não viole os requisitos da política, leia e entenda as seguintes políticas na íntegra e observe os requisitos relativos a SDKs abaixo:

Apps com escalonamento de privilégios que dão acesso root a dispositivos sem a permissão do usuário são considerados apps de acesso root.

Política de software indesejado para dispositivos móveis

Comportamento transparente e divulgações claras

Todos os códigos precisam cumprir as promessas feitas ao usuário. Os apps precisam fornecer todas as funcionalidades informadas. Os apps não podem confundir os usuários.

Exemplos de violação:

• Fraude de anúncio
• Engenharia social

Proteção dos dados do usuário

Divulgue com clareza e transparência o acesso, o uso, a coleta e o compartilhamento de dados pessoais e sensíveis do usuário. As aplicações dos dados do usuário precisam estar de acordo com todas as políticas relevantes sobre o assunto, quando aplicáveis, e é necessário tomar todas as precauções para proteger os dados.

Exemplos de violação:

• Coleta de dados (confira a seção sobre spyware)
• Abuso de permissões restritas

Consulte a política de software indesejado para dispositivos móveis

Política de abuso de dispositivos e de rede

Não são permitidos apps que causem danos, interferências ou interrupções ou acessem de maneira não autorizada o dispositivo do usuário, assim como outros dispositivos ou computadores, servidores, redes, interfaces de programação do aplicativo (APIs) 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.

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.

Confira a política de abuso de dispositivos e de rede.

Exemplos de violações causadas pelo SDK

Política contra comportamento enganoso

Não são permitidos apps que tentam enganar os usuários ou permitem comportamento desonesto, incluindo, mas não se limitando a, apps com uma funcionalidade impossível. Os apps precisam incluir divulgação, descrição e imagens/vídeos precisos das funções em todos os metadados. Os apps não podem tentar imitar a funcionalidade ou os avisos do sistema operacional ou de outros apps. As mudanças nas configurações do dispositivo precisam ser facilmente reversíveis pelo usuário e ter o conhecimento e consentimento dele.

Confira a política contra comportamento enganoso na íntegra.

Transparência em relação ao comportamento

Exemplo de violação causada por um SDK

• Seu app tem um SDK que usa técnicas para escapar das revisões.

Que políticas para desenvolvedores do Google Play geralmente são associadas a violações causadas por SDKs?

Para ajudar você a garantir que todos os códigos de terceiros que seu app use estejam em conformidade com as políticas do programa para desenvolvedores do Google Play, consulte as seguintes políticas na íntegra:

• Política de dados do usuário 
• Permissões e APIs que acessam informações sensíveis 
• Política de abuso de dispositivos e de rede 
• Malware 
• Software indesejado para dispositivos móveis 
• Programa de SDKs de anúncio autocertificados para famílias
• Política de anúncios 
• Comportamento enganoso
• Políticas do programa para desenvolvedores do Google Play 

Embora essas políticas sejam as mais relevantes, é importante lembrar que um código de SDK inválido pode fazer o app violar uma política diferente não mencionada acima. Leia e fique por dentro de todas as políticas. É sua responsabilidade como desenvolvedor de apps garantir que os SDKs manipulem os dados do app sem violar as políticas.

Para saber mais, visite nossa Central de Ajuda.

Malware

 Malware é qualquer código capaz de colocar um usuário, os dados dele ou um dispositivo em risco. O malware inclui aplicativos potencialmente nocivos (PHAs), binários ou modificações do framework que consistem em apps de trojans, phishing e spyware, entre outros. Além dessas, estamos continuamente atualizando e adicionando novas categorias.

Com diferentes tipos e recursos, o malware geralmente tem um dos seguintes objetivos:

• Comprometer a integridade do dispositivo do usuário
• Controlar um dispositivo do usuário
• Ativar operações controladas remotamente para que um invasor acesse, use ou explore um dispositivo infectado
• Transmitir dados pessoais ou credenciais do dispositivo sem a divulgação e o consentimento adequados
• Enviar spam ou comandos do dispositivo infectado a outros dispositivos ou redes
• Enganar o usuário

Um app, binário ou uma modificação do framework podem ser nocivos e gerar um comportamento malicioso, mesmo que essa não tenha sido a intenção. Eles podem agir de diferentes maneiras, de acordo com uma série de variáveis. Portanto, o que é nocivo para um dispositivo Android pode não provocar risco algum em outro dispositivo Android. Por exemplo, um dispositivo que executa a última versão do Android não será afetado por apps nocivos que usam APIs obsoletas para realizar comportamentos maliciosos, mas um dispositivo que use uma versão muito antiga do Android pode estar em risco. Apps, binários ou modificações do framework serão sinalizados como malware ou PHA se claramente colocarem em risco vários ou todos os dispositivos e usuários do Android.

As categorias de malware abaixo refletem nossa crença fundamental de que os usuários devem compreender como os dispositivos deles estão sendo usados e promover um ecossistema seguro que permita uma inovação robusta e uma experiência confiável do usuário.

Acesse o Google Play Protect para saber mais.

Acessos "backdoor"

É um código que permite a execução de operações indesejadas, potencialmente nocivas e controladas remotamente em um dispositivo.

Essas operações podem incluir comportamentos que fazem com que o app, binário, ou a modificação da framework se classifique em uma categoria de malware quando a execução é automática. Em geral, o termo "backdoor" descreve como uma operação potencialmente nociva pode ocorrer em um dispositivo. Portanto, ele não se enquadra exatamente em categorias como fraude de faturamento e spyware comercial. Como resultado disso, em algumas circunstâncias, determinados acessos "backdoor" podem ser considerados uma vulnerabilidade pelo Google Play Protect.

Fraude por faturamento

É um código que cobra o usuário automaticamente de forma intencionalmente enganosa.

As fraudes de faturamento de dispositivos móveis estão divididas entre SMS, chamada e tarifa.

Fraude por SMS
É um código que emite cobranças pelo envio de SMS premium sem o consentimento do usuário ou que tenta encobrir a atividade de SMS ocultando acordos de divulgação ou mensagens SMS da operadora de telefonia móvel com notificações sobre cobranças ou confirmações de assinaturas.

Alguns códigos, apesar de tecnicamente expor o envio de SMS, também apresenta um comportamento adicional que permite fraude de SMS. Os exemplos incluem ocultar partes de um acordo de divulgação do usuário para que não seja legível e bloquear intencionalmente as mensagens SMS da operadora de telefonia móvel informando o usuário sobre cobranças ou confirmando uma assinatura.

Fraude por chamada
É um código que emite cobranças ao realizar chamadas para números premium sem o consentimento do usuário.

Fraude por tarifa
É um código que engana o usuário para que ele assine ou compre conteúdos por meio da conta do celular.

A fraude por tarifa inclui qualquer tipo de faturamento, exceto SMS e chamadas premium. Os exemplos disso são faturamento direto via operadora, ponto de acesso sem fio (WAP, na sigla em inglês) e transferência de créditos para dispositivos móveis. A fraude por WAP é um dos tipos mais prevalentes de fraudes por tarifa. A fraude por WAP pode incluir levar os usuários a clicar em um botão ou em um WebView transparente e carregado de forma silenciosa. Ao cumprir a ação, uma assinatura recorrente é iniciada, e geralmente a mensagem por e-mail ou SMS é interceptada para evitar que os usuários percebam a transação financeira.

Stalkerware

Código que coleta dados pessoais ou confidenciais do usuário de um dispositivo e os transmite a terceiros (outra empresa ou indivíduo) para monitoramento.

Os apps precisam incluir uma declaração em destaque adequada e receber consentimento conforme exigido pela política de dados do usuário.

Diretrizes para aplicativos de monitoramento

Os únicos apps de vigilância aceitáveis são os projetados ou comercializados exclusivamente para monitorar outro indivíduo, por exemplo, o monitoramento dos filhos pela família ou de funcionários individuais pela administração de uma empresa, desde que atendam totalmente aos requisitos descritos abaixo. Eles não podem ser usados para monitorar outras pessoas (um cônjuge, por exemplo), mesmo com conhecimento ou permissão delas e ainda que os apps exibam uma notificação contínua. Esses apps precisam usar a sinalização de metadados IsMonitoringTool no arquivo de manifesto para se designarem adequadamente como apps de monitoramento.

Os apps de monitoramento precisam atender a estes requisitos:

• Eles não podem se apresentar aos usuários como soluções de vigilância secreta ou de espionagem.
• Eles não podem usar técnicas de cloaking ou ocultar o comportamento de rastreamento nem tentar enganar os usuários sobre essa funcionalidade.
• Eles precisam apresentar aos usuários uma notificação contínua sempre que estiverem em execução e ter um ícone que os identifique facilmente.
• Os apps precisam divulgar a funcionalidade de monitoramento ou rastreamento na descrição da Google Play Store.
• Os apps e as páginas "Detalhes do app" no Google Play não podem apresentar meios de ativar nem acessar funcionalidades que violem esses termos, como links a um APK não compatível hospedado fora da plataforma.
• Os apps precisam obedecer às leis aplicáveis. Você é exclusivamente responsável por determinar a legalidade do app na localidade de destino.

Negação de serviço (DoS, na sigla em inglês)

É um código que, sem o conhecimento do usuário, executa um ataque de negação de serviço (DoS) ou faz parte de um ataque de DoS distribuído contra outros sistemas e recursos.

Por exemplo, isso pode acontecer ao enviar um volume alto de solicitações HTTP para gerar um carregamento excessivo em servidores remotos.

Componentes de downloads hostis

É um código que não é potencialmente nocivo por si só, mas que faz o download de outros PHAs.

Ele pode ser um componente de downloads hostil se:

• houver razões para acreditar que ele foi criado para espalhar PHAs e que fez download de PHAs ou contém um código que poderia fazer o download de PHAs e instalá-los; ou
• pelo menos 5% dos downloads feitos por ele são de PHAs com um limite mínimo de 500 downloads de apps observados, ou seja, 25 downloads de PHAs observados.

Os principais navegadores e apps de compartilhamento de arquivos não serão considerados componentes de downloads hostis desde que:

• não façam downloads sem a interação do usuário; e
• todos os downloads de PHA sejam iniciados por usuários que deram consentimento.

Ameaça que não atinge o Android

É um código com ameaças que não atingem o Android.

Esses apps não causam danos ao usuário ou dispositivo Android, mas têm componentes potencialmente nocivos a outras plataformas.

Phishing

É um código que finge ser de uma fonte confiável, solicita credenciais de autenticação do usuário ou informações de faturamento e envia esses dados a terceiros. Esta categoria também se aplica a código que intercepta a transmissão de credenciais do usuário.

Alguns alvos comuns de phishing são credenciais bancárias, números de cartão de crédito e credenciais de contas on-line para redes sociais e jogos.

Abuso de privilégios elevados

É um código que compromete a integridade do sistema ao romper o sandbox do app, conseguindo privilégios elevados ou alterando ou desabilitando o acesso a funções centrais ligadas à segurança.

Por exemplo:

• Um app que viola o modelo de permissões do Android ou rouba credenciais (como tokens OAuth) de outros apps
• Apps que abusam de recursos para impedir que sejam desinstalados ou interrompidos
• Um app que desativa o SELinux

Apps com escalonamento de privilégios que dão acesso root a dispositivos sem a permissão do usuário são considerados apps de acesso root.

Ransomware

É um código que toma o controle parcial ou total de um dispositivo ou dados de um dispositivo e exige que o usuário faça um pagamento ou realize alguma ação para recuperá-lo.

Alguns tipos de ransomware criptografam dados no dispositivo e exigem o pagamento para descriptografá-los e/ou aproveitam os recursos de administração do dispositivo para que não possa ser removido por um usuário típico. Por exemplo:

• Bloquear um usuário do próprio dispositivo e exigir dinheiro para devolver o controle ao usuário
• Criptografar dados no dispositivo e exigir o pagamento para descriptografar os dados
• Aproveitar os recursos do Gerenciador de políticas do dispositivo e bloquear a remoção pelo usuário

O código distribuído com o dispositivo que tenha como objetivo principal o gerenciamento subsidiado do dispositivo pode ser excluído da categoria de ransomware, desde que cumpra com os requisitos de bloqueio e gerenciamento seguros e de divulgação e consentimento do usuário adequados.

Acesso root

É um código que faz root no dispositivo.

Há uma diferença entre códigos de root maliciosos e não maliciosos. Por exemplo, apps de root não maliciosos permitem que o usuário saiba antecipadamente que eles farão root no dispositivo e não executam outras ações potencialmente nocivas que se aplicam a outras categorias de PHA.

Os apps de root maliciosos não informam o usuário que farão root no dispositivo ou informam antecipadamente, mas também executam ações que se aplicam a outras categorias de PHA.

Spam

Spyware

O spyware é um comportamento, código ou aplicativo malicioso que coleta, extrai ou compartilha dados do dispositivo ou do usuário que não têm relação com as funcionalidades que obedecem à política.

Um código ou comportamento malicioso que pode ser considerado espionagem ou extrai dados sem o devido consentimento ou aviso também é identificado como spyware.

Confira alguns exemplos de violações de spyware:

• Gravação de áudio e de chamadas telefônicas
• Roubo de dados do app
• Um app com código malicioso de terceiros (por exemplo, um SDK) que transmite dados para fora do dispositivo de forma inesperada ao usuário e/ou sem o devido consentimento ou aviso

Todos os apps precisam obedecer a todas as Políticas do programa para desenvolvedores do Google Play, incluindo as políticas de dados de dispositivos e usuários como Software indesejado para dispositivos móveis, Dados do usuário, Permissões e APIs que acessam informações sensíveis e Requisitos de SDK.

Cavalo de Troia

É um código que parece ser benigno, como um jogo que afirma ser só um jogo, mas que realiza ações indesejáveis contra o usuário.

Essa classificação geralmente é usada em combinação com outras categorias de PHA. Um cavalo de Troia tem um componente inofensivo e um nocivo oculto. Por exemplo, um jogo que envia mensagens SMS premium do dispositivo em segundo plano e sem o conhecimento do usuário.

Observação sobre apps incomuns

Observação sobre a categoria "backdoor"

A classificação na categoria de malware "backdoor" depende de como o código funciona. Uma condição necessária para que qualquer código seja classificado como de "backdoor" é que, ao ser executado automaticamente, ele permita comportamentos classificados em uma das outras categorias de malware. Por exemplo, se um app permitir o carregamento dinâmico de código, e o código carregado dinamicamente extrai mensagens de texto, o app será classificado como malware "backdoor".

Porém, se um app permitir a execução arbitrária de código, mas não tivermos motivos para acreditar que esse código tenha sido adicionado com o objetivo de realizar um comportamento malicioso, o app será considerado vulnerável, e não malware "backdoor". Nesse caso, será solicitado que o desenvolvedor crie um patch para corrigir o problema.

Maskware

São aplicativos que utilizam diversas técnicas evasivas para disponibilizar funcionalidades diferentes ou falsas para os usuários. Esses apps se disfarçam como jogos ou aplicativos legítimos de modo a parecerem inofensivos para as app stores, além de usarem técnicas como ofuscação, carregamento dinâmico de código ou cloaking para revelar o conteúdo malicioso.

O maskware é semelhante a outras categorias de PHA, principalmente os cavalos de troia, e a principal diferença está nas técnicas usadas para ocultar as atividades maliciosas.

Falsificação de identidade

Veja alguns exemplos de violações comuns:

• Desenvolvedores que indicam falsamente uma relação com outra empresa / desenvolvedor / entidade / organização

  

  ① O nome do desenvolvedor listado para este app sugere uma relação oficial com o Google, apesar de tal relação não existir.

• Apps com ícones e títulos que sugerem falsamente um relacionamento com outra empresa / desenvolvedor / entidade / organização

  ① O app usa um emblema nacional e induz os usuários a acreditar que ele é afiliado ao governo.
  ② O app copia o logotipo de uma entidade comercial para sugerir falsamente que é um app oficial da empresa.

• Títulos e ícones de apps que são tão semelhantes aos de outros produtos ou serviços que podem enganar os usuários

  

  
  ① O app usa o logotipo de um site de criptomoeda famoso como ícone para sugerir que é o site oficial.
  ② O app copia o personagem e o título de um programa de TV famoso no ícone e induz os usuários a pensar que ele é afiliado ao programa.

• Apps que alegam falsamente ser o app oficial de uma entidade estabelecida (títulos como "App oficial do Justin Bieber" não são permitidos sem os direitos ou as permissões necessárias)

• Apps que violam as Diretrizes da marca Android

Software indesejado para dispositivos móveis

No Google, acreditamos que, se o foco está no usuário, todo o resto é consequência. Nos princípios de software e na política de software indesejado, apresentamos recomendações gerais para softwares que proporcionam uma ótima experiência ao usuário. Essa política se baseia na política de software indesejado do Google e descreve os princípios do ecossistema Android e da Google Play Store. Qualquer software que viole tais princípios é potencialmente prejudicial para a experiência do usuário. Nós tomaremos as medidas para proteger esses usuários.

Conforme mencionado na política de software indesejado, descobrimos que a maioria dos softwares indesejados tem uma ou mais das mesmas características básicas:

• São enganosos, prometem um valor que não é fornecido.
• Tentam enganar os usuários para que estes os instalem ou aproveitam a instalação de outro programa.
• Não informam ao usuário todas as suas funções principais e significativas.
• Afetam o sistema do usuário de formas inesperadas.
• Coletam ou transmitem informações particulares sem o conhecimento dos usuários.
• Coletam ou transmitem informações particulares sem um tratamento seguro (por exemplo, transmissão por HTTPS).
• Agrupam-se com outro software e sua presença não é divulgada.

Em dispositivos móveis, o software é um código na forma de um app, binário, modificação de framework etc. Para evitar softwares prejudiciais ao ecossistema de software ou à experiência do usuário, tomaremos medidas em relação ao código que viola esses princípios.

A seguir, desenvolvemos a política de software indesejado para estender sua aplicabilidade a softwares para dispositivos móveis. Do mesmo modo, continuaremos refinando a política de software indesejado para dispositivos móveis para lidar com novos tipos de abuso.

Comportamento transparente e divulgações claras

Todos os códigos precisam cumprir as promessas feitas ao usuário. Os apps precisam fornecer todas as funcionalidades informadas. Os apps não podem confundir os usuários.

• Os apps precisam ser claros sobre a função e os objetivos.
• Explique de forma explícita e clara ao usuário quais alterações serão feitas pelo app no sistema. Permita que os usuários analisem e aprovem todas as opções e mudanças significativas da instalação.
• O software não pode deturpar o estado do dispositivo para o usuário, por exemplo, alegando que o sistema está em estado crítico de segurança ou infectado com vírus.
• Não use atividades inválidas criadas para aumentar o tráfego de anúncios e/ou as conversões.
• Não permitimos apps que enganem os usuários ao se passarem por outra pessoa (por exemplo, outro desenvolvedor, empresa, entidade) ou outro app. Não insinue que seu app está relacionado ou autorizado por uma pessoa sem a permissão dela.

Exemplos de violação:

• Fraude de anúncio
• Engenharia social

Proteger a privacidade e os dados do usuário

Divulgue com clareza e transparência o acesso, o uso, a coleta e o compartilhamento dos dados pessoais e sensíveis do usuário. Os usos dos dados do usuário precisam estar de acordo com todas as políticas relevantes sobre o assunto, quando aplicáveis, e é necessário tomar todas as precauções para proteger os dados.

Todos os apps precisam obedecer a todas as Políticas do programa para desenvolvedores do Google Play, incluindo as de dados de dispositivos e usuários, como Dados do usuário, Permissões e APIs que acessam informações sensíveis, Spyware e Requisitos de SDK.

• Não solicite ou induza os usuários a desativarem as proteções de segurança do dispositivo, como o Google Play Protect. Por exemplo, não ofereça mais recursos ou prêmios aos usuários em troca da desativação do Google Play Protect.

Não prejudique a experiência em dispositivos móveis

A experiência do usuário precisa ser simples, fácil de entender e se basear em escolhas claras feitas pelo usuário. Ela precisa apresentar uma proposta de valor clara para o usuário e não interromper a experiência divulgada ou esperada.

• Não exiba anúncios aos usuários de maneiras inesperadas que prejudiquem ou interfiram na usabilidade das funções do dispositivo nem os exiba fora do ambiente do app acionador sem que eles sejam facilmente dispensáveis e tenham o consentimento e a atribuição adequados.
• Os apps não podem interferir em outros apps nem na usabilidade do dispositivo.
• A desinstalação, quando aplicável, precisa ser clara.
• O software para dispositivos móveis não pode imitar solicitações do SO do dispositivo ou de outros apps. Não suprima alertas de outros apps ou do sistema operacional para o usuário, especialmente aqueles que informam sobre alterações no SO.

Exemplos de violação:

• Anúncios invasivos
• Uso não autorizado ou imitação de funcionalidade do sistema

Componente de download hostil

É um código que não é um software indesejado, mas faz download de outro software indesejado para dispositivos móveis (MUwS, na sigla em inglês).

Ele pode ser um componente de downloads hostil se:

• há razões para acreditar que ele foi criado para espalhar MUwS e que fez ou contém um código que poderia fazer o download de MUwS e instalá-los; ou
• pelo menos 5% dos downloads de app feitos por ele são de MUwS com um limite mínimo de 500 observados (ou seja, 25 downloads de MUwS observados).

Os principais navegadores e apps de compartilhamento de arquivos não serão considerados componentes de downloads hostis desde que:

• não façam downloads sem a interação do usuário; e
• todos os downloads de software sejam iniciados por usuários que deram consentimento.

Fraude de anúncios

Veja alguns exemplos de violações comuns:

• Um app que renderiza anúncios que não são visíveis para o usuário
• Um app que gera cliques em anúncios automaticamente sem a intenção do usuário ou que produz tráfego de rede equivalente para fornecer créditos de cliques de maneira fraudulenta
• Um app que envia cliques falsos de atribuição de instalação para receber pagamentos por instalações que não se originaram na rede do remetente
• Um app que exibe anúncios pop-up quando o usuário não está na interface do app
• Declarações falsas do inventário de anúncios por um app, por exemplo, um app que comunica a redes de publicidade que está em execução em um dispositivo iOS quando, na verdade, está em um dispositivo Android; um app que declara incorretamente o nome do pacote que está sendo monetizado

Uso não autorizado ou imitação de funcionalidade do sistema

Apps ou anúncios que imitem funcionalidades do sistema ou interfiram no funcionamento delas, como notificações ou avisos, não são permitidos. As notificações no nível do sistema só podem ser usadas para os recursos integrais de um app, como quando um app de uma companhia aérea notifica os usuários sobre promoções especiais ou quando um jogo notifica os usuários sobre as próprias promoções.

Veja alguns exemplos de violações comuns:

• Apps ou anúncios exibidos por meio de uma notificação ou um alerta do sistema:
  
  ① A notificação do sistema exibida neste app está sendo usada para veicular um anúncio.

Para ver mais exemplos relacionados, consulte a política de anúncios.

Engenharia social

Monetização e anúncios

Pagamentos

Anúncios

Para manter uma experiência de qualidade, consideramos o conteúdo do anúncio, o público-alvo, a experiência do usuário, o comportamento, bem como a segurança e a privacidade. Consideramos anúncios e ofertas associadas como parte do seu app. Eles também precisam obedecer a todas as outras políticas do Google Play. Além disso, temos requisitos adicionais para anúncios que geram receita em apps voltados para crianças no Google Play.

Você também pode saber mais sobre nossas políticas de promoção de apps e páginas "Detalhes do app" neste link, incluindo como lidar com práticas de promoção enganosas.

Conteúdo do anúncio

Anúncios inadequados

Veja alguns exemplos de violações comuns:

• Anúncios inadequados para a classificação do conteúdo do app

① Este anúncio é inadequado (Adolescente) para a classificação do conteúdo (Todos).
② Este anúncio é inadequado (Adulto) para a classificação do conteúdo (Adolescente).
③ A oferta do anúncio (promoção do download de um app para adultos) é inadequada para a classificação do conteúdo do jogo em que o anúncio foi exibido (Todos).

Requisitos de anúncios para famílias

Anúncios enganosos

Os anúncios não podem simular nem imitar a interface do usuário de qualquer recurso do app, como os elementos de aviso ou de notificação de um sistema operacional. É preciso estar claro para o usuário qual app veicula cada anúncio.

Veja alguns exemplos de violações comuns:

• Anúncios que imitam a interface do usuário de um app:

  

  ① O ícone de interrogação neste app é um anúncio que leva o usuário para uma página de destino externa.

• Anúncios que imitam uma notificação do sistema:

  
  

  ① ② Os exemplos acima mostram anúncios que imitam várias notificações do sistema.
  
  
  ① O exemplo acima mostra uma seção que imita outros recursos, mas só leva os usuários a um ou mais anúncios.

Anúncios invasivos

Os anúncios invasivos são exibidos aos usuários de maneiras inesperadas e podem resultar em cliques acidentais ou prejudicar ou interferir na usabilidade das funções do dispositivo.

É proibido forçar um usuário a clicar em um anúncio ou enviar informações pessoais para fins publicitários antes de usar o app por completo. Os anúncios só podem ser exibidos dentro do app que os veicula e não podem interferir em outros apps e anúncios ou na operação do dispositivo, incluindo portas e botões do sistema ou do dispositivo. Isso inclui sobreposições, recursos complementares e blocos de anúncios em forma de widget. Caso seu app exiba anúncios ou outra publicidade que interfira no uso normal, é necessário que eles sejam fáceis de dispensar sem qualquer prejuízo aos usuários.

Veja alguns exemplos de violações comuns:

• Anúncios que ocupam a tela inteira ou interferem na utilização normal e não oferecem um meio claro de dispensar o anúncio:
  

  ① Este anúncio não tem um botão para dispensar.

• Anúncios que forçam o usuário a clicar usando um falso botão "Dispensar" ou que aparecem repentinamente em áreas do app, mesmo que o usuário toque em outra função:
  

  ① Este anúncio usa um botão "Dispensar" falso.
  
  

  ② Este anúncio aparece repentinamente em áreas em que o usuário está acostumado a tocar para funções no app.

• Anúncios que são exibidos fora do app em que são veiculados:
  

  ① O usuário sai do app e vai para a tela inicial do dispositivo. De repente, um anúncio aparece nessa tela.

• Anúncios que são acionados pelo botão home ou por outros recursos projetados especificamente para sair do app:
  

  ① O usuário tenta sair do app e navegar até a tela inicial, mas, em vez disso, o fluxo esperado é interrompido por um anúncio.

Melhores experiências de anúncios

Os desenvolvedores precisam obedecer às diretrizes de anúncios a seguir para garantir experiências de alta qualidade aos usuários nos apps do Google Play. Os anúncios não podem ser exibidos das seguintes formas inesperadas para os usuários:

• Não são permitidos anúncios intersticiais em tela cheia de nenhum formato (vídeo, GIF, estáticos etc.) exibidos inesperadamente, geralmente quando o usuário optou por fazer outra coisa. 
  • Não são permitidos anúncios exibidos em jogos no início de uma fase ou de um segmento de conteúdo.
  • Não são permitidos anúncios intersticiais em vídeo em tela cheia exibidos antes da tela de carregamento do app (tela de apresentação).
• Não são permitidos anúncios intersticiais em tela cheia de nenhum formato que não possam ser fechados após 15 segundos. Intersticiais em tela cheia com permissão ou que não interrompam as ações dos usuários (por exemplo, após a tela de pontuação de um jogo) podem durar mais de 15 segundos.

Esta política não se aplica a anúncios premiados explicitamente ativados pelos usuários, por exemplo: um anúncio que os desenvolvedores oferecem explicitamente aos usuários em troca do desbloqueio de um conteúdo ou recurso específico do jogo. Esta política também não se aplica a monetização e publicidade que não interfiram no uso normal do app ou jogo, por exemplo: conteúdo em vídeo com anúncios integrados ou anúncios de banner que não sejam em tela cheia.

Veja alguns exemplos de violações comuns:

• Anúncios inesperados exibidos durante o jogo ou no início de um segmento de conteúdo, por exemplo: após o usuário clicar em um botão e antes que a ação pretendida pelo clique tenha efeito. Esses anúncios são inesperados, porque os usuários esperam começar um jogo ou interagir com o conteúdo.
  
  ① Um anúncio estático inesperado aparece durante o jogo no início de uma fase.
  
  ② Um anúncio em vídeo inesperado aparece no início de um segmento de conteúdo.
• Um anúncio em tela cheia que aparece durante o jogo e não pode ser fechado após 15 segundos.
  
  ① Um anúncio intersticial aparece durante o jogo e não oferece aos usuários a opção de pular em 15 segundos.

Apps feitos para veicular anúncios

Veja alguns exemplos de violações comuns:

• Apps em que um anúncio intersticial é exibido de maneira consecutiva após uma ação do usuário, incluindo, mas não se limitando a, cliques, ações de deslizar etc.
  

  ① A primeira página do app tem vários botões para interação. Quando o usuário clica em Iniciar app para usá-lo, um anúncio intersticial é exibido. Depois que o anúncio é fechado, o usuário volta ao app e clica em Serviço para usar o serviço, mas outro anúncio intersticial é exibido.
  
  
  ② Na primeira página, o usuário é conduzido a clicar em Jogar, porque é o único botão disponível para usar o app. Quando ele clica, um anúncio intersticial é exibido. Depois que o anúncio é fechado, o usuário clica em Iniciar, que é o único botão exibido, e outro intersticial aparece.

Monetização da tela de bloqueio

Fraude de anúncio

A fraude de anúncios é estritamente proibida. Para mais informações, consulte nossa Política contra fraude de anúncios.

Uso de dados de local para publicidade

Os apps que aproveitam o uso dos dados de local do dispositivo com base em permissão para exibir anúncios estão sujeitos à política de Informações pessoais e confidenciais e aos seguintes requisitos:

• O uso ou coleta de dados de local do dispositivo com base em permissão para fins publicitários precisa estar claro para o usuário e documentado na Política de Privacidade obrigatória do app. Isso inclui links para as Políticas de Privacidade relevantes da rede de publicidade que abordem o uso desse tipo de dados.
• De acordo com os requisitos de permissões de localização, essas permissões só podem ser solicitadas para implementar recursos ou serviços atuais no app, e não apenas para uso publicitário.

Uso do ID de publicidade do Android

A versão 4.0 do Google Play Services introduziu novas APIs e um ID para ser usado por provedores de análise e publicidade. Os termos para o uso desse ID estão disponíveis abaixo.

• Uso. O identificador de publicidade do Android (AAID) só pode ser utilizado para publicidade e análise de usuário. O status das configurações "Desativar publicidade com base em interesses" e "Desativar a Personalização de anúncios" precisa ser verificado em cada acesso do ID.
• Associação a informações de identificação pessoal ou outros identificadores.
  • Uso de publicidade: o identificador de publicidade pode não estar conectado a identificadores de dispositivo permanentes (por exemplo: SSAID, endereço MAC, IMEI etc.) para qualquer finalidade publicitária. O identificador de publicidade só pode ser conectado a informações de identificação pessoal com o consentimento explícito do usuário.
  • Uso para análises: o identificador de publicidade não pode ser conectado a informações de identificação pessoal ou associado a identificadores de dispositivo permanentes (por exemplo: SSAID, endereço MAC, IMEI etc.) para finalidades de análise. Leia a política de dados do usuáriopara mais orientações sobre identificadores de dispositivos permanentes.
• Respeito às seleções dos usuários.
  • Se for redefinido, o novo identificador de publicidade não poderá ser vinculado a outro anterior nem a dados derivados desse identificador sem o consentimento explícito do usuário.
  • É preciso respeitar a configuração "Desativar publicidade com base em interesses" ou "Desativar a Personalização de anúncios" do usuário. Se um usuário tiver ativado essa configuração, o identificador de publicidade não poderá ser usado na criação de perfis de usuários para fins publicitários ou para segmentação de usuários com publicidade personalizada. As atividades permitidas incluem publicidade contextual, limite de frequência, acompanhamento de conversões, geração de relatórios, segurança e detecção de fraudes.
  • Em dispositivos mais novos, quando um usuário exclui o identificador de publicidade do Android, o identificador é removido. Qualquer tentativa de acessar o identificador receberá uma sequência de zeros. Um dispositivo sem um identificador de publicidade não pode ser conectado a dados vinculados ou derivados de um identificador de publicidade anterior.
• Transparência aos usuários. A coleta e o uso do identificador de publicidade e o cumprimento destes termos precisam ser divulgados aos usuários em uma notificação de privacidade adequada às normas legais. Para saber mais sobre nossos padrões de privacidade, consulte nossa política de Dados do usuário.
• Concordância com os Termos de Uso. O identificador de publicidade só pode ser utilizado de acordo com a Política do programa para desenvolvedores do Google Play, tanto por você quanto por qualquer parte com quem ele seja compartilhado em função dos seus negócios. Todos os apps enviados ou publicados no Google Play precisam usar o ID de publicidade (quando disponível em um dispositivo) em vez de outros identificadores de dispositivo para fins publicitários.

Inscrições

Os desenvolvedores não podem enganar os usuários sobre nenhum serviço ou conteúdo de assinatura oferecido no app. É fundamental fornecer informações claras em qualquer promoção no app ou na tela de apresentação. Não permitimos apps que sujeitem os usuários a experiências de compra enganosas ou manipuladoras (incluindo compras no app ou assinaturas).

É preciso ser transparente sobre as ofertas. Isso inclui informar explicitamente quais são os termos da oferta, o custo da assinatura, a frequência do ciclo de faturamento e se é necessária uma assinatura para usar o app. Os usuários não podem ter que realizar ações adicionais para acessar as informações.

As assinaturas precisam fornecer valor contínuo ou recorrente aos usuários durante todo o período e não podem ser usadas para oferecer benefícios únicos, como SKUs de quantias de créditos ou moedas no app ou boosters de uso único para jogos. É possível oferecer incentivos ou bônus promocionais, desde que apenas complementem o valor contínuo ou recorrente oferecido durante o período da assinatura. Os produtos que não oferecem valor contínuo e recorrente precisam usar um produto no app, e não um produto de assinatura.

Não encubra nem qualifique benefícios únicos como assinaturas aos usuários. Isso inclui mudar a assinatura para uma oferta única (por exemplo, ao cancelar, descontinuar ou minimizar o valor recorrente) depois da compra do usuário.

Veja alguns exemplos de violações comuns:

• Assinaturas mensais que não informam aos usuários que serão renovadas e cobradas automaticamente todos os meses
• Assinaturas anuais que mostram o custo mensal com mais destaque
• Preços e termos da assinatura que não estão completamente no idioma local
• Promoções no app que não demonstram claramente que o usuário pode acessar o conteúdo sem uma assinatura (quando disponível)
• Nomes de SKU que não indicam com precisão a natureza da assinatura, como "Teste gratuito" ou "Teste a assinatura premium gratuitamente por três dias" para uma assinatura com cobrança recorrente automática
• Várias telas no fluxo de compra que levam os usuários a clicar acidentalmente no botão de inscrição
• Assinaturas que não oferecem valor contínuo ou recorrente: por exemplo, uma oferta de mil pedras preciosas para o primeiro mês e depois a redução do benefício para uma pedra preciosa nos meses seguintes
• Exigir a inscrição do usuário em uma assinatura de renovação automática para oferecer um benefício único e cancelar a assinatura após a compra sem a solicitação do usuário

① O botão de dispensar não é claramente visível, e talvez os usuários não entendam que podem acessar recursos sem aceitar a oferta de assinatura.

② A oferta exibe somente o custo mensal, e talvez os usuários não entendam que serão cobrados por seis meses ao fazer a assinatura.

③ A oferta exibe somente o preço inicial, e talvez os usuários não entendam o valor que será cobrado automaticamente quando o período promocional acabar.

④ A oferta precisa estar no mesmo idioma dos Termos e Condições para que os usuários a entendam completamente.

Exemplo 2:

① Cliques recorrentes na mesma área de botão fazem com que o usuário clique acidentalmente no botão final de “continuar” para se inscrever.

② O valor que será cobrado dos usuários ao final do período de teste é difícil de ler, de modo que os usuários podem pensar que o plano é gratuito.

Testes gratuitos e ofertas iniciais

Veja alguns exemplos de violações comuns:

• Ofertas que não explicam claramente a duração do teste gratuito nem do preço inicial
• Ofertas que não explicam claramente que o usuário será automaticamente inscrito em uma assinatura paga ao final do período de teste
• Ofertas que não demonstram claramente que o usuário pode acessar conteúdo sem um teste (quando disponível)
• Ofertas com termos e preços que não foram completamente localizados

① O botão de dispensar não é claramente visível, e talvez os usuários não entendam que podem acessar recursos sem se inscrever no teste gratuito.

② A oferta enfatiza o teste gratuito, e talvez os usuários não entendam que serão cobrados automaticamente no final desse período.

③ A oferta não informa o período de teste, e talvez os usuários não compreendam por quanto tempo terão acesso gratuito ao conteúdo da assinatura.

④ A oferta precisa ser localizada no mesmo idioma dos Termos e Condições para que os usuários a entendam completamente.

Gerenciamento, cancelamento e reembolso de assinaturas

Caso você venda assinaturas nos seus apps, é necessário divulgar claramente como os usuários podem gerenciar ou cancelar assinaturas. Além disso, é preciso incluir no app um método on-line e fácil de usar para cancelamento da assinatura. Para atender a esse requisito nas configurações da conta do app (ou página equivalente), você pode incluir:

• um link para a central de assinaturas do Google Play (para apps que usam o sistema de faturamento do Google Play); e/ou
• acesso direto ao seu processo de cancelamento.

De acordo com nossa política geral, se o usuário cancelar uma assinatura comprada pelo sistema de faturamento do Google Play, ele não vai receber um reembolso pelo período de faturamento atual. No entanto, ele vai continuar recebendo o conteúdo da assinatura até o fim do período de faturamento atual qualquer que seja a data do cancelamento. O cancelamento acontecerá após o término do período de faturamento atual.

Os fornecedores de conteúdo ou de acesso podem implementar uma política de reembolso mais flexível diretamente com os usuários. É responsabilidade sua notificar os usuários de qualquer alteração nas políticas de assinatura, cancelamento e reembolso e garantir que elas obedeçam à legislação aplicável.

Programa de SDKs de anúncios autocertificados para famílias

Se você veicula anúncios no app apenas para um público-alvo infantil, conforme descrito na Política para famílias, é necessário usar apenas versões de SDK de anúncio com autocertificação de conformidade com as políticas do Google Play, o que inclui os requisitos de SDKs de anúncio autocertificados para famílias abaixo.

Se o público-alvo do seu app inclui crianças e usuários mais velhos, confira se os anúncios exibidos para crianças têm origem exclusivamente em uma dessas versões de SDKs de anúncio autocertificados (por exemplo, com uma tela neutra de informações de idade).

É sua responsabilidade garantir que todas as versões de SDKs implementadas no seu app, inclusive as versões de SDKs de anúncio autocertificados, obedeçam a todas as políticas, legislações locais e regulamentações aplicáveis. O Google não oferece declarações nem garantias quanto à precisão das informações enviadas pelos SDKs de anúncio durante o processo de autocertificação.

Os SDKs de anúncio autocertificados para famílias só são necessários se você usa SDKs de anúncio para veicular anúncios a crianças. Os casos a seguir são aceitos sem a autocertificação de SDK de anúncio com o Google Play. No entanto, você continua sendo responsável por garantir que o conteúdo dos anúncios e as práticas de coleta de dados obedeçam à política de dados do usuário e à Política para famílias do Google Play:

• Divulgação interna em que você use SDKs para fazer promoção cruzada entre apps ou outras mídias e produtos de merchandising
• Transações diretas com anunciantes em que os SDKs são usados para o gerenciamento de inventário

Requisitos de SDKs de anúncios autocertificados para famílias

• Defina e proíba conteúdos e comportamentos de anúncios questionáveis nos termos ou nas políticas do SDK de anúncios. As definições precisam obedecer às Políticas do programa para desenvolvedores do Google Play.
• Crie um método para classificar seus criativos de anúncios de acordo com grupos adequados à idade. É necessário incluir pelo menos grupos para "Todos" e "Adultos". A metodologia de classificação precisa estar de acordo com a fornecida pelo Google aos SDKs após o preenchimento do formulário de interesse abaixo.
• Ofereça aos editores a opção de pedir o tratamento para direcionamento a crianças para veiculação de anúncios, por solicitação ou por app. Esse tratamento precisa obedecer a todas as legislações e regulamentações aplicáveis de proteção infantil, como a Lei de Proteção da Privacidade On-line das Crianças (COPPA) dos EUA e o Regulamento geral de proteção de dados (GDPR) da UE (links em inglês). O Google Play exige que os SDKs de anúncios desativem anúncios personalizados, publicidade com base em interesses e remarketing como parte do tratamento para direcionamento a crianças.
• Ofereça aos editores a opção de formatos de anúncio que obedecem à Política de anúncios e monetização para famílias do Google Play e atendem aos requisitos do Programa Aprovado por Professores. 
• Para os lances em tempo real de anúncios para crianças, é importante garantir que os criativos tenham sido revisados e que os indicadores de privacidade sejam propagados aos bidders.
• Envie ao Google informações suficientes (como um app de teste e as informações indicadas no formulário de interesse abaixo) para confirmar que o SDK de anúncio atende a todos os requisitos de autocertificação. Além disso, responda em tempo hábil qualquer pedido de mais informações, como o envio de novas versões para verificar a compliance do SDK de anúncio com todos os requisitos de autocertificação.
• Faça a autocertificação de que todas as novas versões obedecem às Políticas do programa para desenvolvedores do Google Play mais recentes, incluindo os requisitos da Política para famílias.

Observação: os SDKs de anúncio autocertificados para famílias precisam ter suporte para veiculação de anúncios feita em conformidade com todos os regulamentos e leis relevantes em relação a crianças caso haja regras desse tipo que se apliquem aos editores.

Veja mais informações sobre como colocar marca-d'água em criativos de anúncio e oferecer um app de teste.

Veja os requisitos de mediação para plataformas de veiculação ao exibir anúncios para crianças:

• Use somente SDKs de anúncios autocertificados para famílias ou implemente as salvaguardas necessárias para garantir que todos os anúncios veiculados por mediação obedeçam a esses requisitos.
• Transmita as informações necessárias para as plataformas de mediação a fim de indicar a classificação do conteúdo do anúncio e qualquer tratamento para direcionamento a crianças aplicável.

Os desenvolvedores podem encontrar uma lista de SDKs de anúncio autocertificados para famílias e conferir quais versões específicas desses SDKs de anúncio são autocertificadas para uso em apps do programa Feito para Família neste link.

Além disso, eles podem compartilhar este formulário de interesse com os SDKs de anúncio que querem receber a autocertificação.

Página "Detalhes do app" e promoção

Promoção de apps

Não são permitidos apps que usem ou se beneficiem, direta ou indiretamente, de práticas de promoção (como anúncios) enganosas ou prejudiciais ao ecossistema do desenvolvedor ou aos usuários. As práticas de promoção são consideradas enganosas ou prejudiciais se exibirem comportamento ou conteúdo que viole as Políticas do programa para desenvolvedores.

Veja alguns exemplos de violações comuns:

• Uso de anúncios enganosos em sites, apps ou outras propriedades, incluindo alertas ou notificações semelhantes àquelas do sistema
• Uso de anúncios sexualmente explícitos para direcionar os usuários à página "Detalhes do app" para download
• Promoção ou técnicas de instalação que causam o redirecionamento para o Google Play ou para o download do app sem uma ação informada do usuário
• Promoção não solicitada por serviços de SMS
• Texto ou imagem no título, ícone ou nome do desenvolvedor do app que indica o desempenho ou a classificação na loja, informações de preço ou promoções ou que sugere relações com programas do Google Play

É sua responsabilidade garantir que todas as redes de publicidade, afiliados ou anúncios associados com seu app estejam em conformidade com essas políticas.

Metadados

Os usuários dependem das descrições para entender a funcionalidade e a finalidade do app. Não permitimos apps com metadados enganosos, excessivos, irrelevantes, inadequados, com formatação incorreta ou sem valor descritivo, incluindo a descrição, o nome do desenvolvedor, o título, o ícone, as capturas de tela e as imagens promocionais do app. Os desenvolvedores precisam descrever claramente o app. Também não permitimos depoimentos de usuários não identificados ou anônimos na descrição do app.

O título, o ícone do app e o nome do desenvolvedor são especialmente úteis para os usuários encontrarem e saberem mais sobre seu app. Não use emojis, emoticons nem caracteres especiais repetidos nesses elementos de metadados. Evite usar TODAS AS LETRAS EM CAIXA ALTA, a menos que isso faça parte da sua marca. Não é permitido o uso de símbolos enganosos nos ícones dos apps. Por exemplo, um ponto que indique uma nova mensagem quando não há novas mensagens e símbolos de download/instalação quando o app não está relacionado ao download de conteúdo. O título do seu app precisa ter até 30 caracteres. Não use no título, no ícone ou no nome do desenvolvedor do aplicativo texto ou imagem que indiquem preços ou informações promocionais ou o desempenho e a classificação da loja, ou que sugiram relações com programas existentes do Google Play.

Além dos requisitos mencionados aqui, Políticas para desenvolvedores específicas ao Google Play podem exigir que você forneça outras informações de metadados.

Veja alguns exemplos de violações comuns:

        ① Depoimentos de usuários anônimos ou não identificados
        ② Comparação de dados de apps ou marcas
        ③ Blocos ou listas verticais/horizontais de palavras

        ① TODAS AS LETRAS EM CAIXA ALTA, a menos que isso faça parte do nome da marca
        ② Sequências de caracteres especiais irrelevantes para o app
        ③ Emojis, emoticons (incluindo kaomojis) e caracteres especiais
        ④ Símbolo enganoso
        ⑤ Texto enganoso

Confira alguns exemplos de texto, imagens ou vídeos inadequados para a página de detalhes:

• Imagens ou vídeos com conteúdo sexualmente sugestivo. Evite imagens sugestivas que tenham seios, nádegas, órgãos genitais ou outro conteúdo ou anatomia fetichizados, seja real ou ilustração.
• É proibido usar linguagem obscena, vulgar ou outra linguagem imprópria para um público geral na página "Detalhes do app".
• Não é permitido retratar violência explícita de maneira proeminente em imagens promocionais, vídeos nem ícones do app.
• Representação do uso ilícito de drogas. Mesmo o conteúdo educacional, documental, científico ou artístico (EDSA, na sigla em inglês) precisa ser adequado para todos os públicos na página "Detalhes do app".

Confira algumas práticas recomendadas:

• Destaque o que há de melhor no seu app. Compartilhe fatos interessantes para que os usuários entendam o que ele tem de especial.
• Verifique se o título e a descrição do app mostram precisamente a funcionalidade dele.
• Evite usar palavras-chave ou referências repetitivas ou sem relação com o app.
• A descrição do app precisa ser concisa e direta. Descrições mais curtas costumam resultar em uma melhor experiência do usuário, principalmente em dispositivos com telas menores. Uma descrição excessivamente extensa, com muitos detalhes, formatação incorreta ou repetições, pode resultar na violação desta política.
• A página "Detalhes do app" precisa ser adequada para o público em geral. Evite o uso de textos, imagens ou vídeos inadequados e obedeça às diretrizes acima.

Instalações, notas e avaliações de usuários

Os desenvolvedores não podem tentar manipular a colocação dos apps no Google Play. Isso inclui, mas não se limita a, melhorar os indicadores dos produtos por meios ilegítimos, como avaliações e classificações fraudulentas ou induzidas por incentivo, ou criar apps cuja função principal é incentivar os usuários a instalar outros apps.

Veja alguns exemplos de violações comuns:

• Pedir que os usuários deem uma nota ao app e oferecer um incentivo para isso:

  
      ① Esta notificação oferece um desconto ao usuário em troca de uma nota alta.
   
• Enviar avaliações repetidamente se passando por usuários para influenciar a colocação de um app no Google Play
   

• Enviar ou incentivar os usuários a enviar avaliações que incluam conteúdo inadequado, como afiliados, cupons, códigos de jogos, endereços de e-mail ou links para sites ou outros apps:

  

      ② Esta avaliação incentiva os usuários a promover o app RescueRover, oferecendo um cupom.

As notas e avaliações são indicadores da qualidade do app. É importante para os usuários que essas informações sejam autênticas e relevantes. Confira algumas práticas recomendadas sobre como responder às avaliações dos usuários:

• Mantenha sua resposta focada nas questões levantadas nos comentários dos usuários e não peça uma nota melhor.
   
• Inclua referências a recursos úteis, como um endereço de suporte ou uma página de perguntas frequentes.

Classificações de conteúdo

Como as classificações de conteúdo são usadas

Como são atribuídas as classificações de conteúdo

Para receber uma classificação do conteúdo, é necessário preencher um questionário de classificação no Play Console com perguntas sobre a natureza do conteúdo dos seus apps. De acordo com suas respostas, o app receberá uma classificação de conteúdo nos padrões de várias autoridades competentes. Declarações falsas sobre o conteúdo levam à remoção ou suspensão do app. Por isso, é importante responder corretamente ao questionário de classificação de conteúdo.

Para evitar que seu app seja listado como "Sem classificação", preencha o questionário de classificação de conteúdo para cada novo app enviado ao Play Console e para todos aqueles que já estão ativos no Google Play. Os apps sem classificação de conteúdo serão removidos da Play Store.

Se você fizer alterações em recursos ou no conteúdo do app que afetem as respostas fornecidas no questionário de classificação do conteúdo, será necessário preencher esse documento novamente no Play Console.

Acesse a Central de Ajuda para ver mais informações sobre as diferentes autoridades de classificação e saber como preencher o questionário de classificação do conteúdo.

Contestação de classificações

Notícias

Os apps de notícias têm as seguintes características:

• Declaram-se como app de "notícias" no Google Play Console.
• Estão listados na categoria "Notícias e revistas" na Google Play Store, com a indicação "notícias" no título, no ícone, no nome do desenvolvedor ou na descrição do app.

Exemplos de apps na categoria "Notícias e revistas" que se qualificam como apps de notícias:

• Apps que incluem termos referentes a "notícias" nas descrições, incluindo, mas não se limitando às seguintes opções:
  • Notícias mais recentes
  • Jornal
  • Últimas notícias
  • Notícias locais
  • Notícias diárias
• Apps com a palavra "notícias" no título, nos ícones ou no nome do desenvolvedor

No entanto, os apps que têm principalmente conteúdo gerado pelo usuário (por exemplo, apps de mídia social) não devem se declarar como de notícias e não são considerados integrantes dessa categoria.

Os apps de notícias que exigem a compra de uma assinatura precisam oferecer uma prévia do conteúdo no app para os usuários antes da aquisição. 

Os apps de notícias precisam:

• fornecer informações sobre a propriedade do app e a fonte dos artigos de notícias, incluindo, mas não se limitando ao editor ou autor original de cada matéria. Nos casos em que não for costume listar cada autor, o app de notícias precisa ser o editor original dos artigos. Links para contas de mídia social não podem ser considerados informações do autor ou editor; 
• ter uma página no app ou um site específico que indique claramente que inclui dados de contato, seja fácil de encontrar (por exemplo, um link na parte inferior da página inicial ou na barra de navegação do site) e forneça dados de contato válidos da empresa de notícias, incluindo um endereço de e-mail ou um número de telefone. Links para contas de mídia social não podem ser considerados informações de contato do editor.

Os apps de notícias não podem:

• apresentar erros ortográficos e/ou gramaticais marcantes;
• ter somente conteúdo estático (por exemplo, de mais de três meses atrás); nem
• ter marketing de afiliados ou receita de publicidade como principal finalidade.

Os apps de notícias podem usar anúncios e outras formas de marketing para gerar receita, desde que a finalidade principal do app não seja vender produtos e serviços nem gerar receita de publicidade.

Os apps de notícias que agregam conteúdo de diversas fontes de publicação precisam ser transparentes sobre a fonte do conteúdo no app. Além disso, cada uma dessas fontes precisa atender aos requisitos da política de notícias.

Consulte este artigo para saber como apresentar as informações exigidas. 

Spam, funcionalidade e experiência do usuário

Spam

Spam de mensagens

Veja um exemplo de uma violação comum:

• Quando o usuário pressiona o botão "Compartilhar", o app envia mensagens em nome dele sem que ele possa confirmar o conteúdo e os destinatários:
  

Spam de afiliados e visualizações da Web

Veja alguns exemplos de violações comuns:

• Apps com a função principal de direcionar o tráfego por referência a um site para receber crédito por inscrições ou compras do usuário no site em questão

• Apps com a função principal de exibir um WebView de um site sem permissão:

  

       ① Este app se chama "Ofertas do Ted", mas ele só fornece um WebView do Google Shopping.

Conteúdo repetitivo

Veja alguns exemplos de violações comuns:

• Não é permitido copiar conteúdo de outros apps sem adicionar valor nem conteúdo original.
• Não é permitido criar vários apps com funcionalidade, conteúdo e experiência do usuário muito semelhantes. Caso os apps tenham pouco volume de conteúdo, recomendamos que os desenvolvedores criem um único app com todo o conteúdo agregado.
  

Funcionalidade, conteúdo e experiência do usuário

Conteúdo e funcionalidade limitados

Não são permitidos apps que só tenham conteúdo e funcionalidade limitados.

Veja um exemplo de uma violação comum:

• Apps que são estáticos sem funcionalidades específicas, como os que só mostram texto ou abrem arquivos PDF
• Apps que têm pouquíssimo conteúdo e que não oferecem uma experiência do usuário envolvente, como os que consistem apenas em um único plano de fundo
• Apps que são desenvolvidos para não fazer nada ou que não têm uma função

Recursos com problemas

Veja alguns exemplos de violações comuns:

• Apps que não instalam
• Apps que instalam, mas não carregam
• Apps que carregam, mas não são responsivos

Outros programas

Instant Apps Android

Nosso objetivo com o Instant Apps Android é criar experiências do usuário que sejam agradáveis e descomplicadas e que, ao mesmo tempo, atendam aos mais altos padrões de privacidade e segurança. Nossas políticas foram criadas para fundamentar esse objetivo.

Os desenvolvedores que optem por distribuir Instant Apps Android pelo Google Play precisam aderir às políticas a seguir e a todas as outras políticas do programa para desenvolvedores do Google Play.

Identidade

Suporte a links

Especificações técnicas

Oferta de instalação do app

O app instantâneo poderá oferecer ao usuário o app instalável, mas esta não pode ser a finalidade principal dele. Ao oferecer uma instalação, os desenvolvedores precisam:

• usar o ícone "Instalar app" do Material Design (em inglês) e o rótulo "Instalar" para o botão de instalação;
• incluir até dois ou três avisos de instalação implícitos no app instantâneo;
• evitar o uso de banners ou outras técnicas semelhantes a anúncios ao mostrar solicitações de instalação aos usuários.

Veja mais detalhes sobre apps instantâneos e diretrizes adicionais de UX nas práticas recomendadas para a experiência do usuário.

Alteração do estado do dispositivo

Visibilidade do app

Identificadores de dispositivo

Os apps instantâneos não têm permissão de acesso a identificadores de dispositivo que (1) permanecem no dispositivo após o app instantâneo ser interrompido e (2) não podem ser redefinidos pelo usuário. Alguns exemplos são:

• Série da versão
• Endereços mac de qualquer chip de rede
• IMEI e IMSI

Se obtidos por meio da permissão de tempo de execução, os apps instantâneos poderão acessar o número de telefone. O desenvolvedor não pode tentar reconhecer o usuário usando esses identificadores nem de qualquer outra maneira.

Tráfego de rede

Política de emoji do Android

Nossa política de emojis foi desenvolvida para promover uma experiência do usuário consistente e inclusiva. Para isso, todos os apps precisam ser compatíveis com a versão mais recente do Unicode Emoji ao serem executados no Android 12 ou mais recente.

Os apps que usam o Android Emoji padrão sem implementações personalizadas já usam a versão mais recente do Unicode Emoji ao serem executados no Android 12 ou mais recente.

Os apps com implementações personalizadas de emoji, incluindo aqueles fornecidos por bibliotecas de terceiros, precisam ser totalmente compatíveis com a versão mais recente do Unicode ao serem executados no Android 12 ou mais recente em até quatro meses após o lançamento do novo Unicode Emoji.

Consulte este guia para saber como ser compatível com emojis modernos.

Famílias

O Google Play oferece uma plataforma completa para que os desenvolvedores possam exibir conteúdo de alta qualidade com classificação indicativa adequada a toda a família. Antes de enviar um app ao programa Feito para Família ou publicar conteúdo voltado para crianças na Google Play Store, você é responsável por garantir que ele seja adequado a esse público e obedeça a toda a legislação relevante.

Políticas para famílias do Google Play

A tecnologia é cada vez mais usada como ferramenta para melhorar a vida das famílias, e a procura dos responsáveis por conteúdo seguro e de alta qualidade para compartilhar com as crianças só aumenta. Você pode desenvolver apps específicos para crianças ou seu app pode atrair a atenção delas. O Google Play quer ajudar a fazer com que seu app seja seguro para todos os usuários, inclusive as famílias.

A palavra "crianças" pode ter diferentes significados dependendo do local e do contexto. É importante que você consulte uma assessoria jurídica para determinar a que obrigações e/ou restrições de idade o app está sujeito. Você é quem mais sabe como seu conteúdo funciona. Por isso, contamos com sua colaboração em fazer com que os apps do Google Play sejam seguros para todas as famílias.

Se o app obedece às Políticas para famílias do Google Play, você pode solicitar a avaliação dele para o Programa Aprovado por Professores, mas não garantimos a inclusão dos apps na iniciativa. 

Requisitos do Play Console

Público-alvo e conteúdo

Na seção Público-alvo e conteúdo do Google Play Console, você precisa indicar o público-alvo a que se destina o app antes de publicá-lo, selecionando uma opção na lista de faixas etárias fornecidas. Independentemente do que você identificar no Google Play Console, se você optar por incluir no app imagens e termos que possam ser considerados voltados para crianças, talvez isso afete a avaliação do Google Play em relação ao público-alvo declarado. O Google Play reserva-se o direito de fazer a própria análise das informações do app fornecidas por você para determinar se o público-alvo divulgado está correto.

Só selecione mais de uma faixa etária para o público-alvo se o app tiver sido desenvolvido para e for apropriado aos usuários nas faixas etárias selecionadas. Por exemplo, apps para bebês, crianças pequenas ou em idade pré-escolar precisam ter somente a faixa etária "Até 5 anos" selecionada como público-alvo. Se o app for destinado a uma série escolar específica, escolha a faixa etária que melhor representa esse nível de ensino. Selecione apenas faixas etárias que incluam adultos e crianças, caso você realmente tenha projetado seu app para todas as idades.

Atualizações da seção "Público-alvo e conteúdo"

É possível atualizar a qualquer momento as informações do app na seção "Público-alvo e conteúdo" no Google Play Console. É necessário atualizar o app para que essas informações sejam refletidas na Google Play Store. No entanto, todas as mudanças feitas nessa seção do Google Play Console poderão ser avaliadas quanto à conformidade com as políticas antes mesmo do envio da atualização do app.

Recomendamos fortemente que você informe aos usuários existentes do seu app sobre alterações no público-alvo ou se passar a permitir anúncios ou compras no aplicativo. Para fazer isso, use a seção "Novidades" na página "Detalhes do app" ou as notificações no app.

Declarações falsas no Play Console

Fazer declarações falsas no Play Console, inclusive na seção "Público-alvo e conteúdo", pode resultar na remoção ou suspensão do app. Por isso, é importante fornecer informações precisas.

Requisitos da Política para famílias

Se crianças forem um dos públicos-alvo do app, será preciso cumprir os seguintes requisitos. A não conformidade com eles poderá resultar na remoção ou suspensão do app.

1. Conteúdo do app: o conteúdo disponível no app precisa ser adequado para crianças. Caso o app tenha conteúdo que não seja globalmente adequado, mas que seja considerado adequado para usuário menor de idade em uma determinada região, ele talvez seja disponibilizado nessa região (regiões limitadas), mas vai permanecer indisponível em outras.
2. Funcionalidade do app: seu app não pode apenas oferecer uma visualização da Web de um site nem ter o objetivo principal de direcionar tráfego para um site sem permissão do proprietário ou administrador.
3. Respostas no Play Console: você precisa responder com precisão às perguntas sobre seu app no Play Console e atualizar as respostas para que reflitam corretamente qualquer mudança aplicada a ele. Isso inclui, mas não se limita a, apresentar com precisão as informações necessárias sobre o app nas seções "Público-alvo e conteúdo" e "Segurança dos dados" e no questionário de classificação de conteúdo da Coalizão Internacional de Classificação Indicativa (IARC).
4. Práticas relacionadas a dados: você precisa divulgar a coleta de todas as informações pessoais e sensíveis de crianças, inclusive por APIs e SDKs chamados ou usados no seu app. As informações sensíveis de crianças incluem, mas não se limitam a, informações de autenticação, dados do sensor da câmera e do microfone, dados do dispositivo, ID do Android e dados de uso de publicidade. Também é preciso que o app siga estas práticas relacionadas a dados:
   • Os apps que segmentam somente crianças não podem transmitir o identificador de publicidade do Android (AAID), os números de série do chip e do hardware, o BSSID, o MAC, o SSID, o IMEI e/ou o IMSI.
     • Os apps que segmentam somente crianças não podem solicitar a permissão AD_ID ao segmentar o nível 33 da API do Android ou versões mais recentes.
   • Os apps segmentados para públicos-alvo que incluam crianças e adultos não podem transmitir o AAID, os números de série do chip e do hardware, o BSSID, o MAC, o SSID, o IMEI e/ou o IMSI de crianças ou usuários com idade desconhecida.
   • O número de telefone do dispositivo não pode ser solicitado ao TelephonyManager da API do Android.
   • Os apps segmentados apenas para crianças não podem solicitar a permissão de localização nem coletar, usar e transmitir o local exato.
   • Os apps precisam usar o Gerenciador de dispositivos complementar (CDM, na sigla em inglês) ao pedir para usar o Bluetooth, a menos que o app segmente apenas versões de sistema operacional (SO) não compatíveis com o CDM.
5. APIs e SDKs: você precisa garantir a implementação correta de qualquer API e SDK no app.
   • Os apps que só segmentam crianças não podem conter APIs nem SDKs que não sejam aprovados para uso em serviços primariamente direcionados para crianças.
     • Por exemplo, um serviço de API que usa a tecnologia OAuth para autenticação e autorização e indica nos Termos de Serviço que não é aprovado para uso em serviços feitos para crianças.
   • Os apps que segmentam simultaneamente crianças e públicos-alvo mais velhos não podem implementar APIs nem SDKs que não sejam aprovados para uso em serviços direcionados a crianças, a menos que sejam usados por trás de uma tela neutra de informações de idade ou implementados de uma maneira que não resulte na coleta de dados de crianças. Apps que são direcionados simultaneamente a crianças e públicos mais velhos não podem exigir que os usuários acessem o conteúdo do app usando APIs ou SDKs que não sejam aprovados para uso em serviços feitos para crianças.
6. Realidade aumentada (RA): se o app usar realidade aumentada, será necessário incluir um aviso de segurança imediatamente após a abertura da seção de RA. O aviso precisa ter as seguintes informações:
   • Uma mensagem apropriada sobre a importância da supervisão da família.
   • Um lembrete alertando sobre os perigos físicos no mundo real (por exemplo, sobre o ambiente ao redor dos usuários).
   • O app não pode exigir o uso de dispositivos não recomendados para crianças (por exemplo, Daydream e Oculus).
7. Recursos e aplicativos sociais: se o app permitir que os usuários compartilhem ou troquem informações, vai ser necessário divulgar esses recursos com precisão no questionário de classificação do conteúdo no Play Console.
   • Aplicativos sociais: têm como foco principal permitir que os usuários compartilhem conteúdo em formato livre ou se comuniquem com grandes grupos de pessoas. Todos os aplicativos sociais que incluem crianças no público-alvo precisam exibir um lembrete no próprio app sobre segurança on-line e sobre os riscos reais das interações na Internet antes de permitir que usuários dessa faixa etária troquem mídia ou informações em formato livre. Além disso, é preciso exigir a ação de um adulto antes de permitir que crianças troquem informações pessoais.
   • Recursos sociais: incluem qualquer funcionalidade adicional do app que permita aos usuários compartilhar conteúdo em formato livre ou se comunicar com grandes grupos de pessoas. Todos os apps que incluem crianças no público-alvo e têm recursos sociais precisam exibir um lembrete no próprio app sobre segurança on-line e sobre os riscos reais das interações na Internet antes de permitir que usuários dessa faixa etária troquem mídia ou informações em formato livre. Além disso, é preciso oferecer um método para que os adultos gerenciem os recursos sociais de crianças, incluindo ativar/desativar esses recursos ou selecionar diferentes níveis de funcionalidade, entre outros. Também é necessário exigir a ação de um adulto antes de ativar recursos que permitem que crianças troquem informações pessoais.
   • A "ação de um adulto" é um mecanismo para verificar a idade do usuário sem incentivar as crianças a falsificar essa informação para ter acesso a áreas do app projetadas para adultos. Por exemplo: PIN do adulto, senha, data de nascimento, verificação de e-mail, ID por foto, cartão de crédito ou documento oficial.
   • Aplicativos sociais em que o foco principal é conversar com pessoas desconhecidas não podem ter crianças como público-alvo. Por exemplo: apps do tipo "chat roulette", apps de encontros, salas de chat abertas com foco em crianças etc.
8. Compliance legal: você precisa garantir que o app, inclusive as APIs ou os SDKs chamados ou usados por ele, obedeçam à Lei de Proteção da Privacidade On-line das Crianças (COPPA) dos EUA, ao Regulamento geral de proteção de dados (GDPR) da UE e a qualquer outra legislação ou regulamento aplicável.

Veja alguns exemplos de violações comuns:

• Apps que promovem jogos para crianças na página "Detalhes do app", mas têm conteúdo que só é apropriado para adultos
• Apps que implementam APIs com Termos de Serviço que proíbem o uso em apps feitos para crianças
• Apps que exaltam o uso de bebidas alcoólicas, tabaco ou substâncias controladas
• Apps que incluem jogos de azar reais ou simulados
• Apps que incluem violência, sangue ou conteúdo chocante não apropriado para crianças
• Apps que fornecem serviços de relacionamento pessoal ou aconselhamento sexual e amoroso
• Apps que têm links para sites com conteúdo que viola as Políticas do programa para desenvolvedores do Google Play
• Apps que exibem anúncios destinados a adultos (por exemplo, conteúdo violento, sexual ou de jogos de azar) para crianças

Anúncios e monetização

Se você gera receita com um app destinado a crianças no Google Play, é importante que ele siga os seguintes requisitos da política de anúncios e monetização para famílias.

As políticas abaixo se aplicam a todo tipo de monetização e publicidade, incluindo anúncios, promoções cruzadas (para seus aplicativos e os de terceiros), ofertas de compras no app ou qualquer outro conteúdo comercial (como inserção paga de produto). Toda monetização e publicidade nesses apps precisa obedecer às legislações e regulamentações aplicáveis, inclusive a todas as diretrizes do setor ou de autorregulamentação relevantes.

O Google Play reserva-se o direito de recusar, remover ou suspender apps devido a táticas comerciais excessivamente agressivas.

Requisitos dos anúncios

Se o app exibe anúncios para crianças ou usuários de idade desconhecida, é preciso:

• usar somente SDKs de anúncios com autocertificação de cumprimento das Políticas do Google Play para famílias para exibir anúncios a essas pessoas;
• garantir que os anúncios exibidos para esses usuários não envolvam publicidade com base em interesses (direcionada a usuários específicos com determinadas características de acordo com o comportamento de navegação on-line) nem remarketing (publicidade que segmenta usuários específicos com base em interações anteriores com um app ou site);
• garantir que os anúncios exibidos a esses usuários apresentem conteúdo apropriado para crianças;
• garantir que os anúncios exibidos a esses usuários sigam os requisitos de formato do anúncio para famílias; e
• garantir o cumprimento de todos os padrões do setor e regulamentações legais aplicáveis com relação à publicidade para crianças.

Requisitos de formato dos anúncios

A monetização e a publicidade no app não podem ter conteúdo enganoso nem ser projetadas de maneira que leve a cliques acidentais de usuários menores de idade.

Se as crianças são o único público-alvo do app, os itens abaixo são proibidos. Caso o público-alvo inclua crianças e adultos, esses elementos não são permitidos ao veicular anúncios para menores ou usuários com idade desconhecida:

• Publicidade e monetização invasivas, como as que ocupam a tela inteira ou interferem no uso normal e não oferecem uma maneira clara de dispensar o anúncio (por exemplo, paredes de anúncios)
• Publicidade e monetização que interferem no uso normal do app ou jogo e não podem ser fechadas depois de 5 segundos, inclusive no caso de anúncios premiados e com permissão
• Exceção permitida: monetização e publicidade que duram mais de 5 segundos, mas não interferem no uso normal do app ou jogo (por exemplo, conteúdo de vídeo com anúncios integrados)
• Publicidade e monetização intersticiais exibidas imediatamente após a inicialização do app
• Vários posições de anúncio em uma página, por exemplo: mostrar mais de um banner ou anúncio em vídeo ou usar anúncios de banner que exibem diversas ofertas em um canal
• Monetização e publicidade que não podem ser facilmente diferenciadas do conteúdo do app, como offerwalls e outras experiências de anúncios imersivos
• Uso de táticas chocantes ou que envolvem manipulação emocional para incentivar a visualização de anúncios ou as compras no app
• Anúncios enganosos que forçam o usuário a clicar usando um botão "Dispensar" para acionar outro anúncio ou que aparecem repentinamente em áreas do app onde o usuário geralmente toca para outra função
• Falta de distinção entre o uso de moedas virtuais no jogo e dinheiro real para fazer compras no app

Veja alguns exemplos de violações comuns:

• Monetização e publicidade que se afastam do dedo do usuário quando ele tenta fechar
• Monetização e publicidade que não fornecem ao usuário uma maneira de fechar a oferta após 5 (cinco) segundos, conforme descrito no exemplo abaixo:
  
   
• Monetização e publicidade que ocupam a maior parte da tela do dispositivo sem fornecer ao usuário uma maneira clara de dispensá-lo, conforme descrito no exemplo abaixo:

  

• Anúncios de banner que mostram várias ofertas, conforme mostrado no exemplo abaixo:

• Monetização e publicidade que podem ser confundidas com o conteúdo do app, conforme mostrado no exemplo abaixo:
  

• Botões, anúncios ou outra monetização que promovem outras páginas "Detalhes do app" do Google Play, mas que podem ser confundidos com o conteúdo do app, conforme mostrado no exemplo abaixo:

Veja alguns exemplos de conteúdo impróprio de anúncios que não podem ser exibidos para crianças.

• Conteúdo de mídia impróprio: são anúncios de programas de TV, filmes, álbuns de música ou qualquer outro meio de comunicação que não sejam apropriados para crianças.
• Videogames e software para download impróprios: são anúncios de videogames e software para download que não sejam apropriados para crianças.
• Substâncias controladas ou prejudiciais: são anúncios de bebidas alcoólicas, tabaco, substâncias controladas ou prejudiciais.
• Jogos de azar: são anúncios de simulações de jogos de azar, competições ou promoções de sorteios, mesmo com participação gratuita.
• Conteúdo adulto e sexualmente sugestivo: são anúncios com conteúdo sexual e para maiores.
• Namoro ou relacionamentos: são anúncios de sites de namoro ou de relacionamento para adultos.
• Conteúdo violento: são anúncios com conteúdo violento e imagens inadequadas para crianças.

SDKs de anúncio

Se você veicula anúncios no app, e o público-alvo dele só inclui crianças, use apenas os SDKs de anúncio autocertificados para famílias. Se o público-alvo do app inclui crianças e maiores, implemente medidas de triagem etária, como uma tela neutra de informações de idade. Além disso, os anúncios exibidos para crianças precisam vir exclusivamente de versões desses SDKs.

Saiba mais sobre esses requisitos na política do Programa de SDKs de anúncio autocertificados para famílias e consulte neste artigo a lista atual de versões desses SDKs.

Se você usar a AdMob, consulte a Central de Ajuda da plataforma para mais detalhes sobre os produtos dela.

É sua responsabilidade garantir que o app atenda a todos os requisitos relacionados a anúncios, compras no app e conteúdo comercial. Fale com os provedores dos seus SDKs de anúncio para saber mais sobre as políticas de conteúdo e práticas de publicidade deles.

Política de SDKs de anúncio autocertificados para famílias

O Google Play tem o compromisso de criar uma experiência segura para crianças e famílias. Uma parte importante disso é fazer com que as crianças só vejam anúncios apropriados para a idade, e que os dados delas sejam processados de maneira adequada. Para alcançar esse objetivo, exigimos que os SDKs de anúncio e as plataformas de mediação autocertifiquem que são apropriados para crianças e obedecem às Políticas do programa para desenvolvedores do Google Play e às Políticas para famílias do Google Play, o que inclui os requisitos do Programa de SDKs de anúncio autocertificados para famílias.

O Programa de SDKs de anúncio autocertificados para famílias do Google Play é uma maneira importante para os desenvolvedores identificarem quais desses SDKs de anúncio ou plataformas de mediação confirmaram que são adequados ao uso em apps feitos especialmente para crianças.

Requisitos da política

Caso seu SDK ou plataforma de mediação veicule apps que façam parte do programa para Famílias do Google Play, é preciso obedecer a todas as políticas para desenvolvedores do Google Play, inclusive os requisitos a seguir. O não cumprimento de qualquer requisito da política pode resultar na remoção ou suspensão do Programa de SDKs de anúncio autocertificados para famílias.

É sua responsabilidade garantir que o SDK ou a plataforma de mediação esteja em conformidade. Portanto, confira as Políticas do programa para desenvolvedores do Google Play, as Políticas para famílias do Google Play e os requisitos do Programa de SDKs de anúncio autocertificados para famílias.

1. Conteúdo do anúncio: anúncios disponíveis para crianças precisam ter conteúdo adequado a esse público-alvo.
   • É necessário (i) definir conteúdo e comportamentos de anúncios questionáveis e (ii) proibir esses elementos nos termos ou nas políticas. As definições precisam obedecer às Políticas do programa para desenvolvedores do Google Play.
   • Além disso, você precisa criar um método para classificar seus criativos de anúncios de acordo com grupos adequados à idade. É necessário incluir pelo menos grupos para "Todos" e "Adultos". A metodologia de classificação precisa estar de acordo com a oferecida pelo Google aos SDKs após o preenchimento do formulário de interesse.
   • É preciso garantir que, quando forem usados lances em tempo real para veicular anúncios a crianças, os criativos tenham sido revisados e obedeçam aos requisitos acima.
   • Além disso, é preciso ter um mecanismo para identificar visualmente os criativos provenientes do seu inventário, como incluir uma marca d'água no criativo do anúncio com um logotipo visual da empresa ou outra funcionalidade semelhante.
2. Formato do anúncio: é preciso garantir que todos os anúncios exibidos para usuários menores de idade sigam os requisitos de formato do anúncio para famílias, além de permitir que os desenvolvedores selecionem formatos de anúncio que obedeçam à Política para famílias do Google Play.
   • A publicidade não pode ter conteúdo enganoso nem ser projetada de maneira que leve a cliques acidentais de crianças. É proibido usar anúncios enganosos que forçam o usuário a clicar usando um botão "Dispensar" para acionar outro anúncio ou que aparecem repentinamente em áreas do app onde o usuário geralmente toca para outra função.
   • Não é permitida a publicidade disruptiva, inclusive anúncios que ocupam a tela inteira ou interferem no uso normal e não incluem um meio claro de fechamento (por exemplo, paredes de anúncios).
   • Se a publicidade interferir no uso normal do app ou jogo, inclusive anúncios premiados ou com permissão, o usuário precisa ter a opção de fechar o anúncio após 5 segundos.
   • Não é permitido posicionar vários anúncios em uma página. Por exemplo, não são permitidos anúncios de banner que mostram várias ofertas em uma posição ou exibir mais de um banner ou anúncio em vídeo.
   • A publicidade precisa ser claramente diferenciada do conteúdo do app. É proibido usar Offerwalls e experiências de anúncios imersivos que não sejam claramente identificáveis como publicidade por usuários menores de idade.
   • Os anúncios não devem usar táticas chocantes ou que envolvem a manipulação emocional para incentivar a visualização.
3. IBA/remarketing: é necessário garantir que os anúncios exibidos para usuários menores de idade não envolvam publicidade com base em interesses (direcionada a usuários individuais que tenham determinadas características com base no comportamento de navegação on-line) nem remarketing (direcionada a usuários individuais com base na interação anterior com um app ou site).
4. Práticas relacionadas a dados: você, provedor de SDK, precisa ser transparente na forma como lida com os dados do usuário (por exemplo, dados coletados do usuário ou sobre ele, incluindo informações do dispositivo). É necessário divulgar como os SDKs acessam, coletam, usam e compartilham dados, bem como limitar o uso dessas informações às finalidades divulgadas. Além dessas exigências do Google Play, é preciso seguir os requisitos prescritos pelas legislações de privacidade e proteção de dados aplicáveis. Você precisa divulgar a coleta de todas as informações pessoais e sensíveis de crianças, incluindo, mas não se limitando a, informações de autenticação, dados do sensor da câmera e do microfone, dados do dispositivo, ID do Android e dados de uso de publicidade.
   • É preciso permitir que os editores tenham a opção de pedir o tratamento para direcionamento a crianças para veiculação de anúncios, por solicitação ou por app. Esse tratamento precisa obedecer a todas as legislações e regulamentações aplicáveis de proteção infantil, como a Lei de Proteção da Privacidade On-line das Crianças (COPPA) dos EUA e o Regulamento geral de proteção de dados (GDPR) da UE (links em inglês).
     • O Google Play exige que os SDKs do setor desativem anúncios personalizados, publicidade com base em interesses e remarketing como parte do tratamento para direcionamento a crianças.
   • Você precisa garantir que, quando forem usados lances em tempo real para veicular anúncios a crianças, os indicadores de privacidade sejam propagados para os bidders.
   • Não é permitido transmitir o AAID, número de série do chip, número de série, BSSID, MAC, SSID, IMEI e/ou IMSI de crianças ou usuários com idade desconhecida.
5. No caso de plataformas de mediação, é preciso obedecer aos requisitos abaixo ao veicular anúncios para crianças:
   • Use somente SDKs de anúncios autocertificados para famílias ou implemente as salvaguardas necessárias para garantir que todos os anúncios veiculados por mediação obedeçam a esses requisitos.
   • Transmita as informações necessárias para as plataformas de mediação a fim de indicar a classificação do conteúdo do anúncio e qualquer tratamento para direcionamento a crianças aplicável.
6. Autocertificação e compliance: você precisa enviar ao Google informações suficientes, como as indicadas no formulário de interesse, para confirmar que a política do SDK de anúncio obedece a todos os requisitos de autocertificação, incluindo, mas não se limitando a:
   • Incluir uma versão em inglês dos Termos de Serviço, da Política de Privacidade e do guia de integração do editor do SDK ou da plataforma de mediação
   • Enviar um app de teste com a versão compatível mais recente do SDK de anúncio. O app de teste precisa ser um APK Android completo e executável que use todos os recursos do SDK. Requisitos para apps de teste:
     • Ser enviado como um APK Android completo e executável em um formato de smartphone
     • Usar a versão mais recente do SDK ou uma a ser lançada em breve que esteja em conformidade com as políticas do Google Play
     • Usar todos os recursos do SDK, incluindo chamadas para buscar e exibir anúncios
     • Ter acesso total a todos os inventários de anúncios ativos/exibidos na rede por criativos solicitados pelo app de teste
     • Não ser restrito por geolocalização
     • Se seu inventário for destinado a um público-alvo misto, o app de teste vai precisar diferenciar solicitações de criativos de todo o inventário e aquele adequado para crianças ou todas as idades.
     • Ele não pode ser restrito a anúncios específicos no inventário, a menos que seja controlado pela tela neutra de informações de idade.
7. Você precisa responder em tempo hábil a solicitações de informações subsequentes e ter uma autocertificação de que todos os lançamentos de novas versões estejam em conformidade com as Políticas do programa para desenvolvedores do Google Play mais recentes, inclusive os requisitos da Política para famílias.
8. Conformidade legal: os SDKs de anúncio autocertificados para famílias precisam ser compatíveis com a veiculação de anúncios feita em conformidade com todos os estatutos e regulamentos relacionados a crianças e aplicáveis aos editores.
   • Você precisa garantir que o SDK ou a plataforma de mediação obedeça à Lei de Proteção da Privacidade On-line das Crianças (COPPA) dos EUA, ao Regulamento geral de proteção de dados (GDPR) da UE (links em inglês) e a qualquer outra legislação ou regulamento aplicável.
     
     Observação: a palavra "crianças" pode ter diferentes significados dependendo do local e do contexto. É importante que você consulte uma assessoria jurídica para determinar a que obrigações e/ou restrições de idade o app está sujeito. Você é quem mais sabe como seu conteúdo funciona. Por isso, contamos com sua colaboração em fazer com que os apps do Google Play sejam seguros para todas as famílias.

Consulte a página Programa de SDKs de anúncio autocertificados para famílias para conferir mais detalhes sobre os requisitos do programa.

Restrição

Cobertura da política

Nossas políticas aplicam-se a qualquer conteúdo que o app do desenvolvedor exibe ou a que se vincula, incluindo quaisquer anúncios exibidos aos usuários e quaisquer conteúdos gerados por usuários que o app hospeda ou a que se vincula. Da mesma forma, essas políticas se aplicam a qualquer conteúdo da conta de desenvolvedor que for exibido publicamente no Google Play, incluindo o nome do desenvolvedor e a página de destino do site listado.

Não permitimos apps que possibilitam a instalação de outros apps nos dispositivos. Apps que fornecem acesso a outros apps, jogos ou software sem instalação, incluindo experiências e recursos fornecidos por terceiros, precisam garantir que todo o conteúdo fornecido esteja em conformidade com as políticas do Google Play. Além disso, esse material estará sujeito a análises adicionais de acordo com as políticas.

Os termos definidos usados nessas políticas têm o mesmo significado que aqueles utilizados no Contrato de distribuição do desenvolvedor (DDA). Além de estar em conformidade com essas políticas e a DDA, o conteúdo do app precisa ser classificado de acordo com nossas Diretrizes de classificação do conteúdo.

Não permitimos apps ou conteúdo que prejudicam a confiança do usuário no ecossistema do Google Play. Ao avaliar a inclusão ou remoção de apps do Google Play, consideramos diversos fatores, incluindo, mas não se limitando a um padrão de comportamento prejudicial ou alto risco de abuso. Identificamos o risco de abuso usando vários itens, como reclamações específicas sobre apps e desenvolvedores, relatórios de notícias, histórico de violações, feedback de usuários e o uso de marcas, personagens e outros recursos conhecidos.

Como funciona o Google Play Protect

O Google Play Protect verifica os apps quando você os instala. Ele também faz verificações periódicas no dispositivo. Se encontrar um app potencialmente nocivo, ele poderá realizar as seguintes ações:

• Enviar uma notificação para você. Para remover o app, toque na notificação e depois em "Desinstalar".
• Desativar o app até que ele seja desinstalado.
• Remover o app automaticamente. Na maioria dos casos, se um app nocivo for detectado, você receberá uma notificação informando que ele foi removido.

Como funciona a proteção contra malware

Para proteger você contra softwares e URLs maliciosos de terceiros, além de outros problemas de segurança, o Google pode receber informações sobre:

• conexões de rede do seu dispositivo;
• URLs potencialmente nocivos;
• sistema operacional e apps instalados no dispositivo por meio do Google Play ou de outras fontes.

Você pode receber um alerta do Google sobre um app ou URL potencialmente perigoso. O app ou URL poderá ser removido ou ter a instalação bloqueada pelo Google se for reconhecido como prejudicial para dispositivos, dados ou usuários.

É possível desativar certas proteções nas configurações do dispositivo. No entanto, talvez o Google continue recebendo informações sobre os apps instalados por meio do Google Play. Além disso, os apps instalados no seu dispositivo de outras fontes poderão ser verificados em busca de problemas de segurança sem o envio de informações ao Google.

Como funcionam os alertas de privacidade

O Google Play Protect enviará um alerta caso um app seja removido da Google Play Store por permitir o acesso às suas informações pessoais para que você possa desinstalá-lo.

Processo de restrição

Caso o app ou a conta de desenvolvedor viole uma das nossas políticas, vamos tomar as medidas cabíveis conforme descrito abaixo. Além disso, vamos apresentar informações relevantes sobre a medida a ser tomada por e-mail, junto com instruções sobre como contestar caso você acredite que nossa ação tenha sido um engano.

Talvez a remoção ou as notificações administrativas não contemplem todas as violações de políticas presentes no app ou no catálogo de apps em geral. Os desenvolvedores são responsáveis pela resolução de todos os problemas relativos às políticas e por garantir, com a devida diligência, que o restante do app ou da conta também esteja em total conformidade com as políticas. Não resolver violações da política na conta e em todos os seus apps pode resultar em ações adicionais de fiscalização.

Violações recorrentes ou graves dessas políticas (como malware, fraude e apps que podem causar danos ao usuário ou ao dispositivo) ou do Contrato de distribuição do desenvolvedor (DDA, na sigla em inglês) vão resultar no encerramento de contas de desenvolvedor do Google Play individuais ou relacionadas.

Ações de restrição

Cada aplicação da política pode afetar os apps de uma maneira diferente. Usamos uma combinação de avaliação automática e humana para analisar os apps e o conteúdo deles, com o objetivo de detectar e avaliar conteúdo que viole nossas políticas e seja prejudicial aos usuários e ao ecossistema do Google Play em geral. O uso de modelos automáticos permite detectar mais violações e avaliar possíveis problemas com mais rapidez, o que nos ajuda a manter o Google Play seguro para todos. O conteúdo que viola as políticas é removido pelos nossos modelos automáticos ou, quando é necessária uma avaliação mais detalhada, é sinalizado para análise adicional por operadores e analistas treinados, que conduzem avaliações de conteúdo. Isso ocorre, por exemplo, quando é necessário compreender o contexto do conteúdo. Os resultados dessas análises manuais são usados na criação de dados de treinamento para a melhoria dos nossos modelos de aprendizado de máquina.

Na seção a seguir, há uma descrição de várias ações que a plataforma pode realizar e o impacto delas em um app ou na conta de desenvolvedor do Google Play.

Salvo indicação em contrário em um aviso de restrição, essas ações afetam todas as regiões. Por exemplo, se o app for suspenso, ele vai ficar indisponível em todas as regiões. Além disso, salvo indicação em contrário, essas ações vão permanecer em vigor, a menos que você envie uma contestação e ela seja aceita.

Rejeição

• Um app novo ou uma atualização enviados para revisão não serão disponibilizados no Google Play.
• Se uma atualização de um app for rejeitada, a última versão publicada permanecerá disponível no Google Play.
• Isso não afeta o acesso às instalações do usuário, às estatísticas e às notas do app rejeitado.
• Também não afeta a situação da conta de desenvolvedor do Google Play.

Observação: não tente reenviar um app rejeitado até corrigir todas as violações da política.

Remoção

• O app e as versões anteriores dele vão ser removidos do Google Play e não vão estar mais disponíveis para download.
• Como o app é removido, os usuários não vão poder conferir a página "Detalhes do app". Essas informações vão ser restauradas depois que você enviar uma atualização do app removido em conformidade com a política.
• Talvez os usuários não consigam fazer compras no aplicativo nem utilizar recursos de faturamento em apps até que uma versão em conformidade com a política seja aprovada pelo Google Play.
• As remoções não afetam imediatamente a situação da sua conta de desenvolvedor do Google Play, mas várias remoções podem resultar em suspensão.

Observação: não tente publicar novamente um app removido até corrigir todas as violações da política.

Suspensão

• O app e as versões anteriores dele vão ser removidos do Google Play e não vão estar mais disponíveis para download.
• A suspensão pode ocorrer como resultado de violações graves ou repetidas das políticas, bem como por várias rejeições ou remoções do app.
• Como o app está suspenso, os usuários não vão ter acesso à página "Detalhes do app".
• Não é mais possível usar o APK nem o pacote do app suspenso.
• Os usuários não vão poder fazer compras no app nem usar os recursos do Faturamento do Google Play nele.
• As suspensões contam como avisos que afetam a situação regular da conta de desenvolvedor do Google Play. Quando há vários avisos, isso pode levar ao encerramento de contas de desenvolvedor do Google Play individuais e relacionadas.

Visibilidade limitada

• A detecção do app no Google Play é restrita. O app vai permanecer disponível no Google Play e poderá ser acessado por usuários com um link direto para a página "Detalhes do app".
• Colocar o app em um estado de visibilidade limitada não afeta a situação da sua conta de desenvolvedor do Google Play.
• Colocar o app em um estado de visibilidade limitada não afeta a capacidade dos usuários de conferir a página "Detalhes do app" atual.

Regiões limitadas

• O download do app no Google Play só está disponível em certas regiões.
• Os usuários de outras regiões não encontrarão o app na Play Store.
• As pessoas que instalaram o app anteriormente poderão continuar a usá-lo nos dispositivos, mas não receberão mais atualizações.
• A limitação de região não afeta a situação da sua conta de desenvolvedor do Google Play.

Estado de conta restrita

• Quando a conta de desenvolvedor está em estado restrito, todos os apps no catálogo são removidos do Google Play e não é possível publicar apps novos nem republicar os atuais. Você ainda vai ter acesso ao Play Console.
• Como todos os apps são removidos, os usuários não vão poder conferir a página "Detalhes do app" nem o Perfil do desenvolvedor.
• Os usuários atuais não vão poder fazer compras no app nem usar recursos de faturamento dos seus apps.
• Você ainda pode usar o Play Console para enviar mais dados ao Google Play e corrigir as informações da sua conta.
• Você vai poder republicar seus apps depois de corrigir todas as violações da política.

Encerramento da conta

• Quando a conta de desenvolvedor é encerrada, todos os apps no catálogo são removidos do Google Play e não é possível publicar novos apps. Isso também significa que todas as contas de desenvolvedor do Google Play associadas também são suspensas permanentemente.
• Várias suspensões ou suspensões por violações graves da política também podem resultar no encerramento da conta do Play Console.
• Como os apps na conta encerrada são removidos, os usuários não vão poder conferir a página "Detalhes do app" e o Perfil do desenvolvedor.
• Os usuários atuais não vão poder fazer compras no app nem usar recursos de faturamento dos seus apps.

Observação: todas as novas contas que você tentar abrir também vão ser encerradas (sem reembolso da taxa de registro do desenvolvedor). Portanto, não tente se inscrever em uma nova conta do Play Console quando uma das suas outras contas for encerrada.

Contas inativas

Contas inativas são contas de desenvolvedor que não estão ativas ou foram abandonadas. Essas contas não estão em situação regular conforme exigido pelo Contrato de distribuição do desenvolvedor.

As contas de desenvolvedor do Google Play são destinadas a desenvolvedores ativos que publicam e mantêm apps ativamente. Para evitar abusos, fechamos as contas inativas que não são usadas ou não apresentam atividade significativa (por exemplo, de publicação e atualização de apps, acesso a estatísticas ou gerenciamento de páginas "Detalhes do app", entre outras) regularmente.

O encerramento de contas inativas excluirá sua conta e todos os dados associados a ela. A taxa de registro não é reembolsável e será perdida. Antes de encerrarmos sua conta inativa, notificaremos você usando as informações de contato fornecidas para essa conta.

O encerramento de uma conta inativa não impede você de criar uma nova conta no futuro, caso decida publicar no Google Play. Você não poderá reativar a conta, e os apps ou dados anteriores não estarão disponíveis em uma nova conta.  

Gerenciamento e denúncia de violações da política

Contestar uma ação de restrição

Em caso de erro e se o app não violar as políticas do programa do Google Play e o Contrato de distribuição do desenvolvedor, todos os apps vão ser restabelecidos. Se você tiver analisado as políticas com atenção e acreditar que a ação pode ter sido um engano, siga as instruções fornecidas na notificação por e-mail de restrição ou clique aqui para contestar nossa decisão.

Recursos adicionais

Se você precisar de mais informações sobre uma ação de restrição ou uma nota/comentário de um usuário, consulte alguns dos recursos abaixo ou entre em contato por meio da Central de Ajuda do Google Play. No entanto, não podemos oferecer orientação jurídica ao desenvolvedor. Se você precisar de orientação jurídica, consulte um advogado.

• Verificação de apps
• Como denunciar uma violação de política
• Entrar em contato com o Google Play sobre o encerramento de uma conta ou a remoção de um app
• Avisos cordiais
• Denunciar comentários e apps impróprios
• Meu app foi removido do Google Play
• Para compreender os encerramentos das contas de desenvolvedor do Google Play

Requisitos do Play Console

Para garantir a segurança e proteção do nosso ecossistema de apps, o Google Play exige que todos os desenvolvedores atendam aos requisitos do Play Console, incluindo perfis vinculados à sua conta de desenvolvedor do Play Console. As informações verificadas serão exibidas no Google Play para ajudar a conquistar a confiança dos usuários. Saiba mais sobre as informações que aparecem no Google Play.

O Google Play oferece dois tipos de conta de desenvolvedor: pessoal e de organização. Selecionar o tipo certo de conta de desenvolvedor e concluir as verificações necessárias é fundamental para uma boa experiência de integração. Saiba mais sobre como escolher um tipo de conta de desenvolvedor.

Ao criar a conta do Play Console, os desenvolvedores precisam se inscrever como uma Organização caso forneçam os seguintes serviços:

• Produtos e serviços financeiros, incluindo, mas não se limitando a, serviços bancários, empréstimos, negociação de ações, fundos de investimento, corretoras de criptomoedas e carteiras de software de criptomoedas. Saiba mais sobre a política de serviços financeiros.
• Apps de saúde, como apps de medicina e apps de pesquisa em seres humanos. Saiba mais sobre as categorias de apps de saúde.
• Apps aprovados para uso da classe VpnService. Saiba mais sobre a política de serviço de VPN.
• Apps governamentais, incluindo apps desenvolvidos por um governo ou em nome de um órgão governamental.

Depois de selecionar um tipo de conta, faça o seguinte:

• Envie informações precisas da sua conta de desenvolvedor, incluindo os seguintes detalhes:
  • Nome completo e endereço
  • Número DUNS, caso se registre como uma organização
  • Endereço de e-mail e número de telefone para contato
  • Endereço de e-mail e número de telefone do desenvolvedor exibidos no Google Play, quando aplicável
  • Formas de pagamento, quando aplicável
  • Perfil para pagamentos do Google vinculado à sua conta de desenvolvedor
• Para os desenvolvedores que se registram como uma organização, as informações da conta de desenvolvedor precisam estar atualizadas e condizer com os detalhes armazenados no perfil da Dun & Bradstreet.

Antes de enviar seu app, faça o seguinte:

• Envie com precisão todas as informações e metadados do app.
• Faça upload da Política de Privacidade do seu app e preencha os requisitos da seção "Segurança dos dados".
• Envie uma conta de demonstração ativa, além de informações de login e todos os outros recursos necessários para que o Google Play revise o app (especificamente, credenciais de login, QR code etc.)

Como sempre, garanta que o app ofereça uma experiência de usuário estável, envolvente e responsiva e verifique se todos os elementos dele, incluindo redes de publicidade, serviços de análise e SDKs de terceiros, estão em conformidade com as Políticas do programa para desenvolvedores do Google Play. Caso o público-alvo do app inclua crianças, também é preciso estar em conformidade com a Política para famílias.

É sua responsabilidade ler o Contrato de distribuição do desenvolvedor e todas as Políticas do programa para desenvolvedores para garantir que o app esteja em total conformidade.