Google bloqueia 8,3 bilhões de anúncios irregulares e restringe permissões no Android 17

Mudanças no Google Play reduzem acesso amplo a contatos e localização, enquanto modelos baseados em Gemini passam a bloquear anúncios fraudulentos antes da exibição.

Componente	Google Ads, Google Play, Play Console e permissões de contatos e localização em apps voltados ao Android 17 e versões posteriores.
Vetor	Abuso de anúncios, contas de anunciantes e permissões excessivas em aplicativos que solicitam listas de contatos completas ou localização precisa sem necessidade proporcional.
Impacto	Bloqueio ou remoção de mais de 8,3 bilhões de anúncios em violação de políticas em 2025, suspensão de 24,9 milhões de contas e redução planejada da coleta ampla de contatos e localização por apps.
Prioridade	Revisar manifestos Android, remover READ_CONTACTS quando não houver necessidade funcional contínua, preparar declarações no Play Console e auditar fluxos de transferência de propriedade de apps.
Artefatos	Contact Picker, Android Sharesheet, READ_CONTACTS, botão de localização do Android 17, onlyForLocationButton e declaração de desenvolvedor no Play Console.
Mitigação	Usar seleção granular de contatos, acesso único à localização precisa, indicadores persistentes de uso de localização e transferência nativa de conta no Play Console a partir de 27 de maio de 2026.

Resumo técnico

O Google detalhou duas frentes de controle que afetam diretamente segurança, privacidade e abuso em escala dentro do ecossistema Android e de publicidade. A primeira envolve a filtragem de anúncios e contas de anunciantes: em 2025, mais de 8,3 bilhões de anúncios que violavam políticas foram bloqueados ou removidos globalmente, e 24,9 milhões de contas foram suspensas. Dentro desse conjunto, 602 milhões de anúncios e 4 milhões de contas foram associados a golpes ou atividade relacionada a golpes. A empresa também restringiu mais de 4,8 bilhões de anúncios e tomou ação contra mais de 480 milhões de páginas que tentavam veicular conteúdo enquadrado em categorias proibidas ou restritas, incluindo malware, jogos de azar on-line, promoção de armas, álcool, tabaco e conteúdo sexual explícito.

A segunda frente está no Android 17, ainda descrito como beta no material recebido, com mudanças de política para limitar permissões de contato e localização. O ponto central é reduzir o modelo antigo de permissão ampla, no qual um aplicativo podia solicitar acesso a toda a agenda por meio de READ_CONTACTS, mesmo quando precisava apenas de um telefone ou e-mail específico. O novo fluxo prioriza o Contact Picker ou o Android Sharesheet, permitindo que o usuário escolha contatos específicos e que o app solicite apenas campos necessários. Para localização, o Android 17 introduz um botão destinado a ações temporárias, com acesso único à localização precisa e indicador persistente quando um app não sistêmico consulta a posição do usuário.

Fluxo técnico

No fluxo de contatos, a mudança desloca o controle de uma autorização genérica para uma seleção mediada pelo sistema. Em vez de depender de READ_CONTACTS para ler registros inteiros da agenda, aplicativos aplicáveis devem usar uma interface padronizada, segura e pesquisável para seleção de contatos. Esse desenho reduz a quantidade de dados expostos ao app e limita a coleta ao contato escolhido e aos campos declarados, como número de telefone ou endereço de e-mail. A permissão ampla continua reservada a apps que não funcionam sem acesso completo e contínuo à lista de contatos, mas essa necessidade deverá ser justificada por meio de declaração no Play Console.

Na localização, a política segue lógica semelhante: apps que executam ações discretas e temporárias com localização precisa devem implementar o botão de localização do Android 17 usando a flag onlyForLocationButton no manifesto. Quando o uso exige localização persistente e precisa como função central, o desenvolvedor terá de explicar por que o botão ou a localização aproximada não são suficientes. O formulário de declaração está previsto para ficar disponível antes de outubro de 2026, e verificações de pré-revisão no Play Console devem começar em 27 de outubro de 2026 para identificar problemas de política envolvendo contatos e localização.

A frente de publicidade usa modelos baseados em Gemini para analisar intenção e bloquear conteúdo malicioso ou fraudulento antes da exibição. O ponto técnico relevante é a migração de controles mais dependentes de palavras-chave para modelos capazes de avaliar padrões de intenção, inclusive quando o anúncio tenta contornar detecção. Mais de 99% dos anúncios em violação de política foram identificados por sistemas automatizados antes de serem mostrados a usuários em 2025. No fim do ano, a maioria dos anúncios responsivos de pesquisa criados no Google Ads já era revisada instantaneamente, com bloqueio de conteúdo nocivo no momento de submissão.

Superfície afetada

A superfície de risco envolve três grupos principais. O primeiro é formado por apps Android que ainda declaram READ_CONTACTS no manifesto por conveniência, compatibilidade antiga ou desenho de produto que coleta mais dados do que a função exige. Esses apps terão de demonstrar necessidade funcional se quiserem manter acesso completo e contínuo à agenda em alvos Android 17 ou superiores. Caso contrário, o caminho esperado é remover a permissão e mover a experiência para o seletor de contatos ou para o compartilhamento mediado pelo sistema.

O segundo grupo inclui apps que usam localização precisa para operações pontuais, como localizar um ponto próximo, preencher um endereço, acionar uma ação baseada em presença ou validar uma escolha do usuário. Nesses casos, a política favorece acesso temporário e explícito, com sinalização persistente quando um app não sistêmico acessa a localização. O terceiro grupo envolve contas de desenvolvedor e propriedade de aplicativos no Play Console. A transferência nativa de conta passa a ser o mecanismo recomendado para mudança de titularidade, enquanto transferências informais por compartilhamento de credenciais ou compra e venda de contas em mercados externos ficam associadas a risco de fraude e não são permitidas pela política descrita.

A superfície de publicidade permanece ligada a contas de anunciantes, páginas de destino, formatos de anúncio e conteúdo gerado em escala. O abuso citado inclui golpes, conteúdo malicioso e páginas que tentam veicular categorias proibidas ou restritas. A comparação com 2024 mostra mudança no volume reportado: naquele ano foram suspensas mais de 39,2 milhões de contas de anunciantes, 5,1 bilhões de anúncios ruins foram interrompidos, 9,1 bilhões de anúncios foram restringidos e anúncios foram bloqueados ou restringidos em 1,3 bilhão de páginas.

• Apps Android direcionados ao Android 17 ou posterior que pedem READ_CONTACTS sem necessidade contínua e integral da agenda.
• Apps que usam localização precisa para ações temporárias e precisarão adotar o botão de localização com onlyForLocationButton.
• Contas de desenvolvedor que passam por mudança de propriedade fora do recurso nativo de transferência do Play Console.
• Anunciantes e páginas de destino associados a golpes, malware ou categorias de anúncio proibidas ou restritas.

Hunting e telemetria

Para equipes de engenharia e segurança de produto, a primeira linha de verificação está no manifesto Android e no mapeamento entre permissões declaradas e funcionalidades reais. A presença de READ_CONTACTS deve ser confrontada com fluxos de tela, chamadas de API e necessidade de acesso contínuo. Se a função só precisa de um contato escolhido pelo usuário, a permissão ampla passa a ser um sinal de coleta excessiva e de risco de reprovação em revisão de política. O mesmo vale para localização precisa: fluxos temporários devem ser separados de casos de uso persistente, com evidência clara para qualquer exceção que dependa de declaração formal.

Em ambientes de publicidade e antifraude, a telemetria defensiva deve se concentrar em contas recém-criadas ou alteradas, mudanças bruscas em campanhas, padrões de submissão automatizada, páginas de destino reclassificadas e rejeições por conteúdo nocivo. Como o contexto aponta uso de IA generativa por operadores para criar anúncios enganosos em escala, sinais úteis incluem variações textuais massivas com intenção semelhante, rotação frequente de criativos, mudanças rápidas de destino e tentativas de reapresentação após bloqueio. A análise deve evitar depender apenas de termos exatos, pois o próprio controle descrito prioriza interpretação de intenção e não apenas correspondência de palavra-chave.

• Manifestos com READ_CONTACTS em apps cuja função principal não exige leitura integral e contínua da agenda.
• Uso de localização precisa em ações discretas sem adoção do botão de localização do Android 17.
• Solicitações de transferência de propriedade de app que tentem contornar o fluxo nativo do Play Console por compartilhamento de credenciais.
• Picos de criação ou alteração de anúncios com texto variado, mas mesma intenção fraudulenta ou mesma página de destino.
• Rejeições recorrentes de campanhas associadas a golpes, malware ou conteúdo restrito, especialmente quando há rotação de contas.

Mitigação

A mitigação para apps começa por inventário. Desenvolvedores devem revisar permissões de contatos e localização, associar cada permissão a uma função de produto e remover declarações que não tenham necessidade comprovável. Para contatos, apps direcionados ao Android 17 e posteriores devem preferir Contact Picker ou Android Sharesheet; READ_CONTACTS deve permanecer apenas quando a funcionalidade central depende de acesso completo e contínuo, com justificativa preparada para o Play Console. Para localização, ações temporárias com precisão devem usar o botão de localização e a flag onlyForLocationButton, enquanto usos persistentes precisam ser documentados com o motivo pelo qual localização aproximada ou acesso único não resolvem o caso de uso.

Controles de governança também precisam cobrir propriedade de aplicativos. A partir de 27 de maio de 2026, mudanças de titularidade devem ser conduzidas pelo recurso nativo de transferência de conta no Play Console. Isso reduz exposição decorrente de compartilhamento de login, venda informal de contas ou repasse de credenciais entre entidades. Em paralelo, times que operam campanhas publicitárias devem tratar reprovações por golpe, malware ou conteúdo restrito como sinal de risco operacional, investigando contas, criativos, páginas de destino e alterações recentes antes de tentar nova submissão.

Para validação, a ordem recomendada é revisar manifestos, ajustar fluxos de consentimento, remover permissões amplas sem necessidade, preparar declarações formais quando houver dependência legítima e testar a experiência em Android 17. No lado de anúncios, a resposta defensiva passa por controles de identidade de anunciantes, revisão de páginas de destino, detecção de padrões de geração em massa e acompanhamento de bloqueios antes da exibição. A combinação de política de menor privilégio em apps e classificação de intenção em publicidade reduz dois vetores distintos: coleta excessiva de dados do usuário e distribuição de conteúdo fraudulento ou malicioso por canais de anúncio.

• Remover READ_CONTACTS quando o app puder operar com seleção granular de contatos.
• Implementar Contact Picker ou Android Sharesheet como fluxo principal para acesso a contatos escolhidos pelo usuário.
• Adicionar onlyForLocationButton em apps que usam localização precisa para ações temporárias no Android 17 ou superior.
• Preparar declaração no Play Console para acesso contínuo a contatos ou localização precisa persistente quando houver necessidade funcional comprovável.
• Usar a transferência nativa de conta no Play Console para mudanças de propriedade de apps.
• Monitorar anúncios bloqueados, contas suspensas e páginas de destino reclassificadas como sinais de abuso ou comprometimento operacional.