O Google Quer Saber Quem Você É Antes de Deixar Você Instalar Qualquer App

Imagina o seguinte cenário: você desenvolve um app open source no fim de semana, sobe o APK no GitHub, e alguém tenta instalar no Android. A partir de setembro de 2026, o celular dessa pessoa vai mostrar uma tela de aviso agressiva, com múltiplos passos de confirmação, e possivelmente bloquear a instalação por completo. O motivo? Você não se cadastrou no Google, não enviou seu RG e não pagou US$ 25.

Esse é o Android Developer Verification (ADV), o novo programa do Google que exige que todo desenvolvedor Android se identifique formalmente antes de distribuir qualquer aplicativo, dentro ou fora da Play Store. E o F-Droid, repositório open source com 15 anos de história, chamou o programa pelo que ele acredita ser: malware disfarçado de proteção.

Como funciona o Android Developer Verification

O ADV opera como um processo em segundo plano chamado “Android Developer Verifier”. Ele roda com privilégios de root, vem embutido no Play Protect e é distribuído automaticamente para todos os dispositivos Android certificados (basicamente qualquer celular com Google Mobile Services). Segundo o F-Droid, ele “não pode ser bloqueado, desabilitado ou removido”.

Na prática, o sistema funciona assim:

Desenvolvedores que já publicam na Play Store provavelmente já atendem parte desses requisitos, já que a Google exige números D-U-N-S e verificações de publisher há algum tempo. O problema é para todo o resto do ecossistema Android.

O cronograma que ninguém pediu

O rollout do ADV segue um calendário agressivo:

Março de 2026: política anunciada, registro aberto para desenvolvedores.

Setembro de 2026: enforcement começa em quatro países: Brasil, Indonésia, Singapura e Tailândia. Esses mercados foram escolhidos por terem “pressão elevada de fraude e malware”, segundo o Google.

2027: verificação se torna obrigatória globalmente para qualquer app instalado de fontes terceiras, incluindo sideloading direto de APK.

Sim, você leu certo. O Brasil é um dos primeiros países onde isso entra em vigor. Se você é dev Android no Brasil, isso te afeta diretamente em menos de três meses.

Por que o F-Droid chamou de malware

O post do F-Droid publicado em 1 de julho de 2026 não economizou nas palavras. O repositório argumenta que o ADV se encaixa na definição de malware por vários motivos:

Primeiro: ele roda com privilégios de root sem consentimento explícito do usuário. Você não instalou, você não pediu, e não consegue remover. Isso é literalmente o que rootkits fazem.

Segundo: a definição de “malware” usada pelo Google é propositalmente vaga. Nas palavras do F-Droid: “malware significa o que nós dissermos que significa”. Essa autoridade indefinida poderia teoricamente ser usada para restringir software legítimo, como bloqueadores de anúncio que afetam a receita do Google.

Terceiro: o sistema coleta dados pessoais sensíveis (documento de identidade, endereço físico) de milhões de desenvolvedores, criando um honeypot massivo de informações. Um vazamento desse banco de dados seria catastrófico.

A estimativa é que 4 bilhões de dispositivos Android sejam afetados pelo programa.

O impacto real no ecossistema open source

Aqui é onde a coisa fica séria. O F-Droid existe há 15 anos com um modelo fundamentalmente diferente da Play Store. O repositório pega código-fonte público, audita para conformidade open source, compila internamente e distribui assinado com a chave criptográfica do próprio F-Droid.

Esse modelo de “transparência pelo código” funcionou por uma década e meia. Mas o Google não reconhece essa abordagem como equivalente à verificação de identidade.

O problema é estrutural:

• Muitos contribuidores do F-Droid são pseudônimos por princípio. Desenvolvedores de software de privacidade, ferramentas anti-censura e apps voltados para ativistas frequentemente não podem (ou não devem) revelar sua identidade real.

• O F-Droid não vai exigir que mantenedores independentes se registrem no Google. Também não vai pré-registrar package names em nome dos desenvolvedores.

• A taxa de US$ 25 pode parecer pouco, mas para desenvolvedores voluntários em países com moeda fraca (Brasil incluso), é uma barreira real. Multiplique isso por centenas de apps mantidos por hobby.

Além do F-Droid, outras lojas alternativas como Aptoide e Aurora Store enfrentam o mesmo problema. O artigo do DEV Community resume bem: “muitos desenvolvedores independentes simplesmente não vão se registrar, seja por preocupação com privacidade, fricção burocrática, ou simplesmente por não ficarem sabendo da exigência”.

O argumento de segurança do Google (e seus furos)

O Google apresenta dados convincentes para justificar o ADV. Segundo a empresa, apps baixados por sideloading contêm malware a taxas 50 vezes maiores que apps da Play Store. A ideia é que, ao exigir identidade real, o custo de distribuir malware sobe significativamente, já que criminosos não podem mais criar contas anônimas descartáveis.

Faz sentido na teoria. Na prática, a história conta outra coisa.

Famílias de malware como Joker, Sharkbot e Xenomorph já burlaram as verificações oficiais da Play Store repetidamente. O Joker sozinho já foi encontrado em mais de 1.700 apps dentro da loja oficial do Google. Se a verificação de identidade não impediu malware na própria Play Store, por que impediria fora dela?

O argumento regulatório também aparece: as IT Rules da Índia e o Digital Services Act da União Europeia exigem rastreabilidade de desenvolvedores. Mas adaptar-se a regulações é diferente de impor um sistema que roda com root e não pode ser removido.

// O que o Play Protect faz nos bastidores (simplificado)
if (!developer.isVerified()) {
    showAggressiveWarning();      // Tela de aviso multi-step
    if (region.isEnforced()) {
        blockInstallation();       // Bloqueia completamente
    }
}
// Nota: o usuário NÃO pode desativar isso

Mais de 70 organizações disseram “não”

A reação da comunidade tech foi imediata. Mais de 70 organizações assinaram uma carta aberta contra o ADV, incluindo a Electronic Frontier Foundation (EFF) e a Free Software Foundation (FSF), duas das organizações mais influentes na defesa de software livre e direitos digitais.

Os argumentos centrais da carta:

1. Liberdade de distribuição: o Android sempre se diferenciou do iOS pela possibilidade de instalar apps de qualquer fonte. O ADV efetivamente cria um sistema de permissão centralizado que se aproxima do modelo fechado da Apple.

1. Privacidade do desenvolvedor: exigir documento de identidade para publicar software é equivalente a exigir identidade para publicar um livro. Software é expressão, e expressão anônima é um direito fundamental.

1. Concentração de poder: o Google se torna o gatekeeper único de quem pode e quem não pode distribuir software para 4 bilhões de dispositivos. Isso é um poder sem precedentes sobre o ecossistema mobile.

1. Precedente perigoso: se funcionar no Android, outros sistemas operacionais podem adotar modelos similares. A web aberta como conhecemos depende da possibilidade de distribuir software sem intermediários.

Sideloading: a história de uma liberdade sob ataque

Pra entender o peso do ADV, vale lembrar como o sideloading funciona (e funcionava) no Android.

Desde as primeiras versões do sistema, o Android permitia instalar APKs de qualquer fonte. Bastava ativar “fontes desconhecidas” nas configurações. Era uma checkbox simples, sem drama. Esse recurso sempre foi um dos principais diferenciais em relação ao iOS, onde a Apple controla 100% do que entra no dispositivo.

Com o Android 8 (Oreo), o Google mudou o modelo. Em vez de uma permissão global, cada app precisava de autorização individual para instalar APKs. Seu navegador queria instalar um APK? Precisava de permissão específica. O gerenciador de arquivos? Outra permissão. Foi uma mudança razoável que dava mais controle granular ao usuário.

Com o Android 12 veio o Play Protect, que começou a escanear APKs instalados por sideloading em busca de malware. De novo, razoável. Escanear é diferente de bloquear.

Agora, com o ADV, o Google dá o passo final: não basta mais o usuário querer instalar. O desenvolvedor precisa ter autorização prévia do Google. É uma inversão completa da filosofia original.

A tendência é clara: cada versão reduz um pouco mais a liberdade do usuário. O ADV não é um evento isolado. É a culminação de uma década de estreitamento gradual.

Comparação com o modelo iOS: mais parecidos do que nunca

Durante anos, o argumento “Android é aberto, iOS é fechado” justificou a escolha de milhões de desenvolvedores e usuários. Com o ADV, essa diferença diminui drasticamente.

A Apple passou anos sendo criticada por seu jardim murado. Ironicamente, a pressão regulatória na Europa (Digital Markets Act) forçou a Apple a permitir sideloading no iOS 17.4 na UE, com certas restrições. Enquanto a Apple abre (forçada), o Google fecha (voluntariamente).

A comparação fica ainda mais estranha quando você percebe que o modelo da Apple para sideloading na UE é, em vários aspectos, menos restritivo que o ADV do Google. A Apple exige uma “notarização” automatizada que verifica malware, mas não exige documento de identidade com foto para distribuir um app. O Google exige KYC completo.

# Comparação simplificada
Apple (iOS 17.4+ na UE):
  - Notarização automatizada (scan de malware)
  - Sem exigência de documento pessoal
  - Taxa: US$ 0 para distribuição direta

Google (ADV 2026+):
  - Verificação KYC completa
  - Documento de identidade obrigatório
  - Taxa: ~US$ 25
  - Processo rodando com root que não pode ser removido

O que muda na prática para desenvolvedores brasileiros

O Brasil estar na primeira leva do rollout não é coincidência. O país tem um dos maiores mercados Android do mundo e uma taxa alta de instalações por sideloading. Pra quem desenvolve no Brasil, a lista de mudanças é concreta:

Se você publica na Play Store: provavelmente já tem verificação suficiente. Mas confira se seus dados estão atualizados no Google Play Console.

Se você distribui APKs pelo GitHub, site próprio ou F-Droid: a partir de setembro, seus usuários no Brasil vão ver avisos agressivos ao tentar instalar. Se você não se registrar, a instalação pode ser bloqueada completamente em dispositivos certificados.

Se você mantém apps corporativos internos (MDM/enterprise): o impacto depende de como sua solução de MDM interage com o Play Protect. Vale verificar com o fornecedor.

Se você é usuário que instala apps fora da Play Store: prepare-se para mais fricção. Aquelas telas de “instalar de fontes desconhecidas” vão ficar mais insistentes, com múltiplos passos de confirmação.

A ironia do “proteção contra malware”

Existe uma ironia fundamental no ADV que vale destacar. O Google está dizendo: “para proteger você contra software malicioso, vamos instalar um processo com privilégios de root que você não pediu, não pode remover e que decide unilateralmente o que você pode ou não instalar no seu próprio dispositivo”.

Se um desenvolvedor independente fizesse exatamente isso, qualquer antivírus do mercado classificaria como malware. Mas quando o Google faz, chama de “proteção”.

O F-Droid tem um ponto válido quando pergunta: qual é a diferença técnica entre um rootkit que controla instalações de software e o Android Developer Verifier? A resposta, aparentemente, é a marca no logo.

Não é que verificação de identidade seja inerentemente ruim. É que a implementação escolhida pelo Google prioriza controle sobre segurança real. Um sistema de verificação voluntário, que oferecesse um selo de “desenvolvedor verificado” sem bloquear desenvolvedores não verificados, atingiria o objetivo de segurança sem destruir a liberdade que torna o Android diferente do iOS.

O que fazer agora

Se você é desenvolvedor Android e pretende continuar distribuindo apps fora da Play Store:

1. Fique de olho no Android Developer Console para o processo de registro quando ele abrir
2. Avalie se o registro faz sentido para o seu caso (apps pessoais, protótipos, ferramentas internas podem não justificar)
3. Considere alternativas como Progressive Web Apps (PWAs) para distribuição sem depender do ecossistema de apps nativos
4. Acompanhe o F-Droid e a EFF para updates sobre possíveis contestações legais

Se você é usuário: agora é a hora de apoiar organizações como o F-Droid, a EFF e a FSF que estão lutando para manter o Android aberto. E talvez repensar o quanto você depende de um ecossistema controlado por uma única empresa.

O Android nasceu como a alternativa aberta. Com o ADV, ele dá mais um passo em direção ao jardim murado que sempre criticou no iOS. A pergunta que fica: quando o Android deixar de ser aberto, o que sobra?

Fonte de inspiração: Android Developer Verification: Threat masquerading as Protection (F-Droid)