- O F-Droid critica que a Android Developer Verification (ADV) já foi distribuída para dispositivos com Android 8 ou superior e pode se tornar um mecanismo de controle central que impede a execução de apps de desenvolvedores não aprovados pelo Google
- O Google usa como justificativa conter a disseminação de malware, mas o F-Droid avalia que a ADV se limita mais a aumentar o custo de recadastro de desenvolvedores reincidentes do que a bloquear a distribuição inicial
- O registro de desenvolvedor exige criação de conta, pagamento de taxa, envio de dados pessoais e documento de identidade emitido pelo governo, registro de identificadores de apps e chaves de assinatura, além da aceitação dos Termos do Android Developer Console
- A principal preocupação é que, se os termos não trouxerem uma definição clara de malware, o Google possa ampliar os alvos de bloqueio por motivos comerciais ou pressão governamental
- A medida começa a valer em 30 de setembro de 2026 por Brazil, Indonesia, Singapore e Thailand, e os impactos reais sobre o app F-Droid, os apps instalados, os dados dos apps e a telemetria de verificação do Google ainda são incertos
Por que o F-Droid comparou a ADV a malware
- O F-Droid entende que o Android Developer Verifier (ADV) está instalado em dispositivos com Android 8 ou superior e aguarda ativação remota
- A ADV já teria sido distribuída para até 4 bilhões de celulares e tablets Android, com estimativa de que cerca de metade da população mundial possa ser afetada
- Esse serviço de sistema roda em segundo plano, e o F-Droid afirma que não pode bloqueá-lo, desativá-lo nem removê-lo
- O Play Protect é um serviço que detecta e responde a malware comum em dispositivos Android Certified, mas o F-Droid critica que a ADV seja propagada e instalada por meio do Play Protect
- Após a ativação, o objetivo da ADV seria impedir a execução de software de desenvolvedores que não tenham aprovação centralizada do Google
Contestação da justificativa de combate a malware
- O F-Droid levantou pela primeira vez suas preocupações sobre a Android Developer Verification em setembro de 2025, em F-Droid and Google’s Developer Registration Decree
- A exigência do Google de um registro centralizado de desenvolvedores é apresentada como medida para impedir a disseminação de malware, mas o F-Droid entende que esse sistema não impede a distribuição inicial por agentes maliciosos
- O efeito real estaria mais próximo de atrasar o comportamento de infratores reincidentes já identificados quando eles tentarem continuar distribuindo malware com uma nova chave de assinatura, pois precisarão criar ou comprar uma nova conta
- Também haveria alternativas menos coercitivas
- O Play Protect poderia examinar com mais rigor apps recém-instalados com permissões elevadas ou apps obtidos por caminhos suspeitos
- Também seria possível adotar um modelo de verificadores federados, em que o usuário escolhe diretamente quais verificadores e autoridades quer confiar, como em DCM: A Developers Certification Model for Mobile Ecosystems
- O F-Droid critica que o Google esteja redesenhando o ecossistema Android com base em um vetor de ameaça restrito e tentando se tornar o único gatekeeper que decide quais apps podem existir
Processo de registro de desenvolvedor e riscos dos termos
- Ao contrário da recomendação do F-Droid, se um desenvolvedor se registrar no Google como desenvolvedor “verified”, terá de passar pelo seguinte processo
- Criar uma conta e pagar uma taxa
- Enviar informações pessoais detalhadas
- Fazer upload de um documento de identidade emitido pelo governo
- Registrar identificadores e chaves de assinatura dos apps que distribui atualmente e dos que distribuirá no futuro
- O maior ponto de controvérsia é a obrigação de aceitar os Android Developer Console Terms of Service
- A cláusula 6.5 dos termos afirma que, se o desenvolvedor violar os termos ou distribuir malware ou uma harmful application, o Google poderá encerrar o acesso ao ADC
- O F-Droid aponta que o documento não traz, em nenhum lugar, uma definição oficial, critérios ou diretrizes para “malware”
- Sem definição, “malware” passa a ser o software que o Google chamar assim, e o escopo pode variar conforme motivações comerciais ou forte pressão governamental
O que o caso dos ad blockers mostra sobre o escopo dos bloqueios
- O F-Droid alerta que é perigoso deixar termos controversos serem definidos por uma parte com interesses diferentes
- Como exemplo representativo, cita os ad blockers, ferramentas pessoais de filtragem de conteúdo
- Ad blockers já foram proibidos na Play Store há muito tempo
- Em alguns casos, já foram classificados como malware
- O F-Droid teme que o Google possa designar todo software de bloqueio de anúncios como malware, impedir sua instalação em dispositivos Android Certified no mundo todo e classificar seus desenvolvedores como criadores de malware
- Essa possibilidade estaria alinhada aos incentivos do negócio de tecnologia de publicidade do Google e à redação dos termos do Android Developer Console
Alegação de adesão e movimentos de oposição
- O Google afirmou recentemente que mais de 99% dos apps de desenvolvedores da Play foram registrados, mas o F-Droid rebate que isso não pode ser visto como prova de ampla aceitação da ADV
- Segundo o F-Droid, esses desenvolvedores estavam vinculados a contratos existentes da Play Store e, por isso, foram incluídos automaticamente sem consentimento prévio suficiente
- Os movimentos contra a ADV também continuam
- Centenas de milhares de pessoas assinaram a petição contra a ADV
- A Open Letter do keepandroidopen.org foi assinada por mais de 70 organizações do mundo todo, incluindo EFF, FSF, FSFE, ACLU e Forbrukerrådet
- Segundo o F-Droid, um vídeo de mesa-redonda com desenvolvedores que tentava defender o programa recebeu dislikes de 90% dos espectadores
- O F-Droid diz que legisladores e órgãos reguladores, até agora, não responderam à reação contrária
- Para o F-Droid, seu modelo de segurança baseado em transparência open source entra em conflito fundamental com o modelo de confiança das lojas de apps comerciais fechadas
Incertezas restantes antes da aplicação em 30 de setembro
- Ainda não se sabe exatamente quais modos de falha a ativação da ADV apresentará em 30 de setembro de 2026
- Segundo o cronograma público do Google, os primeiros alvos da aplicação serão Brazil, Indonesia, Singapore e Thailand
- Esses quatro países somam 580 milhões de habitantes
- O rollout global está previsto para “2027 ou depois”
- Usuários nas regiões afetadas ainda têm perguntas sem resposta
- Não se sabe o que acontecerá ao tentar instalar ou executar o app F-Droid
- É incerto se apps instalados por meio do F-Droid serão desativados ou removidos
- Não se sabe se será possível continuar recuperando dados dentro de um app do qual se depende, caso ele desapareça de repente
- Não se sabe quais informações de telemetria serão incluídas quando toda instalação e execução de software for reportada para verificação pelo Google
- O F-Droid enviou perguntas relacionadas e afirmou que fornecerá orientações e suporte adicionais aos usuários afetados nas semanas e meses antes da aplicação do bloqueio
2 comentários
Na verdade, dizer que está tudo bem porque existem sistemas operacionais alternativos não faz sentido... Para instalar outro SO em um Galaxy, por exemplo, é preciso desativar o chip de segurança de hardware, e aí provavelmente não será possível usar apps de pagamento, bancos etc.
Comentários do Hacker News
Isso não resolve o problema agora, mas vale saber que existem várias opções de Linux OS para mobile caso não consigam frear essa tendência
O SailfishOS é baseado em Linux e a comunidade parece ser bem acolhedora, mas a pilha de UI é de código fechado. É o único que oficialmente consegue rodar apps Android por emulação, já existe há bastante tempo, é leve e parece ser o mais estável e com menos bugs desta lista
O Ubuntu Touch é totalmente open source e guiado pela comunidade, usa pacotes snap por segurança e talvez consiga rodar apps Android. Quando usei pela última vez, ele também era bem estável
O PureOS é totalmente open source e focado em privacidade. Pelo que sei, entre os lançados junto com o Librem 5, é o único que consegue evitar blobs binários proprietários na integração com o hardware. Parece menos estável que o SailfishOS ou o Ubuntu Touch, e para usá-lo é preciso comprar um Librem 5 já antigo e bem caro
O PostmarketOS é totalmente open source, leve e focado em reviver celulares antigos, tem uma quantidade enorme de aparelhos testados e é baseado em Alpine
O Mobian é a versão móvel do Debian e, nesta lista, é relativamente novo. Também existem outros Linux OS para mobile, mas, pelo que sei, estes são os principais. Posso estar impreciso porque testei alguns deles há muito tempo, e os dois últimos eu nunca usei de fato
Os apps executados por cima dela não ficam mais isolados do kernel Linux, e sim menos. Se você se importa com privacidade e segurança, esses OS são muito menos privados e muito menos seguros que o Android Open Source Project. Eles não têm um sandbox de apps completo e funcional nem um modelo de permissões adequado, não têm mitigação moderna de vulnerabilidades e não contam com recursos sérios de criptografia baseada em hardware necessários para impedir extração de dados
Diferente de um OS baseado em AOSP rodando em um hardware decente, que pode ser uma alternativa ao iPhone, estes não são uma alternativa séria do ponto de vista de privacidade e segurança. Este alerta está sendo adicionado aos OS com Google Mobile Services e não afeta negativamente outros OS baseados em Android Open Source Project
Linux não significa necessariamente GNU/Linux ou systemd/Linux, nem quer dizer usar glibc, systemd, GNU coreutils, Bash, GNOME etc. OS baseados em Android, incluindo AOSP e GrapheneOS, também são distribuições Linux. O Alpine não usa glibc, e o SailfishOS também tem sua própria combinação de software aberto e fechado. Usar uma pilha de espaço de usuário típica de Linux de desktop não determina se algo é Linux ou não, e nem no desktop a configuração de uso é consistente
Pessoalmente, não uso apps Android no Librem 5, mas há Waydroid no repositório do PureOS. O Waydroid é uma abordagem baseada em contêiner que inicializa um sistema Android completo em sistemas GNU/Linux comuns com ambiente desktop baseado em Wayland
O PureOS também oferece convergência via Phosh. Aqui, convergência significa usar o mesmo app tanto no celular quanto em telas maiores, com a GUI se ajustando ao tamanho de tela disponível
O Phosh busca oferecer um ambiente gráfico robusto e fácil de usar, adequado para uso diário, em dispositivos móveis rodando Linux mainline. Ele foi iniciado originalmente por desenvolvedores da Purism para o Librem 5, mas hoje é usado em vários tipos de dispositivos, como smartphones, tablets e conversíveis, e já apareceu até em notebooks
UI/UX custa caro, e a maioria dos projetos livres e open source dificilmente consegue fazer isso direito sem grande investimento corporativo ou apoio de startups. Por exemplo, designers de UX da Red Hat contribuíram muito para o GNOME, e há casos de startups como Zed, Element e Bluesky
Projetos sem esse tipo de suporte, pelo menos na visão da Geração Z, costumam ser difíceis de usar
Os usuários do Android deveriam migrar para o Graphene
Alguém precisa criar uma fundação de sistema operacional móvel baseado em Linux. O domínio do Google vai contra os interesses de muitas grandes empresas e, se você abordar empresas como a Meta, elas talvez até doem muito dinheiro por interesse estratégico
Quando o Google sentir que já garantiu estabilidade e compatibilidade suficientes com o alocador de memória reforçado e a tagged memory, e conseguir fazer a Qualcomm dar suporte em toda a sua linha de produtos, vai dificultar cada vez mais o uso do Graphene até torná-lo inviável
É um texto antigo, mas, segundo [1], o Android do Google e os membros da Open Handset Alliance estão contratualmente proibidos de fabricar dispositivos que o Google não aprove
Para competir, também seria preciso criar um Google Play Services compatível e encontrar fabricantes que o suportem. A Samsung operou por um tempo seus próprios apps e loja com o Tizen [2], possivelmente para ganhar poder de negociação ou viabilizar uma migração teórica. Mas depois abandonou esse esforço
[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
Muita gente comum, especialmente fora dos EUA, não consegue bancar isso. Além disso, comprar um celular do Google é sustentar o Google, então pessoalmente eu preferiria evitar
Eliminar a necessidade de drivers proprietários em espaço de usuário para componentes como GPUs Mali modernas também é algo viável com o AOSP, e fazer isso beneficiaria o maior número possível de pessoas. Com muitas empresas e outras entidades unindo forças, isso é possível no AOSP
Isso também pode acontecer por intervenção governamental devido às violações antitruste do Google, mas, se for mal conduzido, pode acabar sendo tratado de uma forma que prejudique o open source
Eu entendo a frustração. Também sou alguém que usa bastante o fdroid em vários dispositivos. Mas este texto parece infantil por causa de expressões como vírus, cavalo de Troia e “empresa de malware”
Textos assim dão a muita gente, talvez até ao próprio Google, o pretexto para descartar o que o fdroid diz como “reclamação infantil que não precisa ser levada a sério”. Por exemplo, um veículo respeitável não publicaria este texto
Além disso, https://keepandroidopen.org/ é um exemplo bem mais bem feito
Não há garantia nenhuma de que isso não será usado para fins fora da segurança. E também é verdade que isso nem ajuda tanto assim na segurança
Se você perguntar à busca do Google, a IA explica malware como software projetado para acesso não autorizado, interferência, extorsão financeira ou tomada de controle do dispositivo. Ainda assim, se você acha que esse termo não se aplica, basta imaginar alguém criando um app com a mesma funcionalidade. O Google o removeria imediatamente chamando-o de malware. Porque claramente seria visto como malware
Eu uso Android porque posso instalar no meu celular o que eu quiser, e isso nem deveria ser motivo de debate. O celular é meu, ou não é. Não quero a proteção do Google. Ainda menos se eu não puder recusá-la
Em computação, um cavalo de Troia é um tipo de malware que se disfarça de programa legítimo para enganar o usuário sobre sua real intenção [1]
O Google é um cavalo de Troia de ponta a ponta. Qual é a verdadeira intenção de quase todos os produtos do Google? Coleta de dados
Todos os produtos são spyware de alguma forma. A empresa até subsidia fabricantes para que embarquem seu spyware e transformou até TVs em cavalos de Troia
[1] https://en.wikipedia.org/wiki/Trojan_horse_(computing)
Para considerar alguns pontos: sideloading é usado por menos de 1–2% dos usuários de Android no mundo, algo como no máximo 50 milhões de pessoas. O Google basicamente deixou isso aberto impondo apenas um atraso de 24 horas, então, na verdade, até foi generoso. Poderia ter ficado pior, mas, por enquanto, dentro do eterno hobby de fuçar nas opções de desenvolvedor, não é nada demais. Pessoalmente, sou grato ao Google
O GMS oferece uma conveniência enorme para desenvolvedores de apps que precisam de controle forte, inclusive governos. Dá para proteger aplicativos contra usuários de qualquer perfil. Se somarmos a isso a possibilidade de backdoors ocultos que apoiem vigilância e o lobby direto do Google na UE, fica muito difícil seguir sem GMS, mesmo que a UE hoje tenha uma inclinação antiamericana, e na Europa ele provavelmente seria a última coisa a ser substituída
Há vários níveis de “desGooglelização”. O espectro vai desde instalar um sistema operacional totalmente aberto, com ou sem microG, até simplesmente não fazer login numa conta do Google no Android padrão. Mas quem está na ponta mais livre desse espectro jamais terá os mesmos direitos de quem está na ponta da prisão
Verificação de desenvolvedor não existe para impedir bloqueio de anúncios. Há um jeito simples e gratuito de bloquear o que você quiser no nível de DNS. Basta selecionar Private DNS e inserir uma URL apropriada para bloquear anúncios, rastreadores e pornografia, como a do controld.com. Então é preciso buscar outro pretexto. Por exemplo, algo como controle forte do usuário para continuar na cama com governos, ou para chegar à vigilância definitiva do usuário com a futura verificação de identidade infantil
Todo o resto também são apenas outras formas de advocacia em favor do Google. Sinceramente, é profundamente desanimador, ainda mais vendo esse tipo de reação justamente no “Hacker” News
No combate a malware, verificação de procedência é uma arma poderosa, mas preservar a capacidade de instalar e executar software anônimo é essencial para resistir a regimes autoritários e sistemas corruptos
Se aceitarmos que apenas software assinado e autorizado possa ser instalado e executado no celular do usuário, a democracia e a liberdade acabam. Tanto no Ocidente quanto no Oriente, e inclusive em cenários de enfrentamento contra governantes de IA
Em muito do hardware e do software dos quais dependemos, não podemos fazer modificações arbitrárias. Não podemos examinar o projeto, reproduzi-lo e, às vezes, nem repará-lo
Às vezes nem sabemos se essas coisas foram projetadas contra os nossos interesses e, mesmo quando sabemos, pode ser que não possamos fazer nada. Somos forçados a escolher entre preço e privacidade, entre interoperabilidade com monopólios ou sistemas oficiais e liberdade
É ruim que o Android dê mais um passo nessa direção. Mas não vamos nos enganar. Estamos há décadas com o pescoço afundado em servidão cyberpunk. Mesmo que vençamos esta batalha do Android, será apenas uma pequena vitória
Não digo isso por derrotismo, mas para não esquecermos a luta maior. Como esse Golias feudal vai terminar? Quando será que o bastante será realmente bastante?
Enquanto isso, em Luxembourg, o Google perdeu a ação contra a multa de US$ 4,7 bilhões do Android na UE
https://www.msn.com/en-us/money/other/google-loses-fight-aga...
Ainda fico um pouco confuso sobre por que a UE não toma medidas quanto a isso. Isso é claramente extrapolação de poder por um monopolista e deveria ter sido barrado desde o início
https://www.eu-digital-markets-act.com/Digital_Markets_Act_A...
Durante décadas aceitamos que fornecedores de sistema operacional pudessem fazer esse tipo de coisa. Acho que isso foi um erro. Quero dizer, depender do Google como único fornecedor viável. Não dá para criar uma lei que puna o Google por ter permanecido aberto até agora
Claro, como muitos outros hackers do HN, também sou a favor de obrigar a Apple a se abrir, mas os grupos de poder que hoje governam a UE, assim como muitos eleitores, parecem gostar bastante de atestação remota de DRM, para um projeto de identidade digital que em breve será exigido para tudo que não seja apropriado para bebês e não possa ser acessado pela dark web
Usuários do HN, especialmente os americanos, têm uma ingenuidade de ver a UE como um bastião da liberdade. Não é nem de longe isso. A UE só quer se tornar um enorme Estado babá, só que de uma forma mais palatável, em que você pode fazer qualquer coisa desde que seja aprovada