Você já usou o Shizuku pra desinstalar bloatware sem root? Já automatizou tarefas no celular com ADB local sem precisar de um computador? Então se prepara, porque o Google quer acabar com isso.

Uma proposta recente no repositório do Android quer restringir o ADB daemon (ADBD) para aceitar conexões apenas pela interface Wi-Fi, bloqueando completamente o acesso via loopback (127.0.0.1). Na prática, isso mata a possibilidade de rodar ADB no próprio dispositivo, quebrando ferramentas como Shizuku, libadb-android e dezenas de apps de acessibilidade que dependem dessa funcionalidade.

A justificativa? Um CVE crítico de maio de 2026. Mas a comunidade dev não engoliu essa história.

O que é ADB on-device e por que importa

Pra quem não vive no mundo Android, uma explicação rápida. O ADB (Android Debug Bridge) é o canivete suíço do desenvolvimento Android. Originalmente, ele foi criado para conectar o celular a um computador via USB e rodar comandos de debug, instalar apps, capturar logs, enfim, tudo que um dev precisa.

Com o tempo, o Android ganhou suporte a ADB via Wi-Fi e, mais recentemente, ADB wireless (sem fio, integrado ao sistema). E aí surgiu algo interessante: se o daemon do ADB roda no próprio celular, por que não conectar nele mesmo via loopback?

É exatamente isso que ferramentas como o Shizuku fazem. O Shizuku age como um “computador local” no seu celular, conectando-se ao ADBD via 127.0.0.1. Com isso, apps podem acessar APIs restritas do sistema sem precisar de root, sem precisar de PC. Alguns exemplos do que dá pra fazer:

• Desinstalar apps de sistema (bloatware da Samsung, Xiaomi, etc.)
• Controlar permissões de apps de forma granular
• Automatizar tarefas via scripts ADB
• Criar ferramentas de acessibilidade que o Android não oferece nativamente
• Gerenciar configurações do sistema que normalmente exigem root

O ecossistema é enorme. O Shizuku sozinho tem milhões de downloads e é a espinha dorsal de dezenas de apps populares no F-Droid e na Play Store.

CVE-2026-0073: a vulnerabilidade que acendeu o alerta

Vamos ser justos com o Google: a preocupação não veio do nada. Em maio de 2026, foi divulgado o CVE-2026-0073, uma vulnerabilidade classificada como crítica (CVSS 8.8) que permite bypass completo da autenticação mútua do ADB wireless.

O bug é elegante na sua simplicidade. No arquivo auth.cpp, a função adbd_tls_verify_cert usa EVP_PKEY_cmp() para verificar certificados TLS. O problema? O retorno dessa função é tratado como booleano, quando na verdade pode retornar valores negativos em caso de tipos de chave incompatíveis. Um valor negativo é diferente de zero, então passa na checagem como “sucesso”.

// Código simplificado do bug
int result = EVP_PKEY_cmp(peer_key, expected_key);
if (result) {  // BUG: -1 (erro) também é tratado como sucesso
    // Autenticação aceita
}

O impacto real? Um atacante na mesma rede Wi-Fi poderia se conectar ao seu celular via ADB wireless sem nenhuma interação do usuário. Zero-click. Daí teria acesso a logs do sistema, poderia instalar apps, executar comandos como shell. Sério o suficiente pra justificar um patch urgente.

E o patch veio. O Android corrigiu o CVE na atualização de segurança de maio de 2026. Versões afetadas: Android 14, 15, 16 e 16-qpr2 antes do patch level 2026-05-01.

Então até aqui, tudo faz sentido. Bug crítico, patch aplicado, vida que segue. Certo?

Onde a coisa desanda: bloquear loopback é outra história

O problema é que o Google não parou no patch. Um core maintainer do ADB propôs ir além: restringir permanentemente as interfaces de rede em que o ADBD pode escutar, limitando a wlan0 (Wi-Fi) e bloqueando lo (loopback/localhost).

A justificativa oficial, nas palavras de um engenheiro do Google:

“Connection to localhost has also been the source of exploit where apps are using that socket to adbd to escalate their privileges.”

E aqui mora o problema. O CVE-2026-0073 era sobre ADB wireless, não sobre loopback. A vulnerabilidade explorava a autenticação TLS em conexões de rede, algo que não se aplica a conexões localhost da mesma forma. Corrigir um bug de autenticação wireless bloqueando acesso local é como proibir facas de cozinha porque alguém arrombou a porta da frente.

O que seria preciso para explorar ADB loopback

Pra um app malicioso explorar ADB via loopback, o usuário precisaria ter:

1. Opções de desenvolvedor ativadas (tocar 7 vezes no número da build)
2. Depuração USB habilitada (opção dentro de desenvolvedor)
3. ADB over TCP/IP ativo (normalmente precisa de um comando manual)
4. Autorizar a impressão digital RSA (popup de confirmação)

São pelo menos 4 barreiras de consentimento explícito. Não é o tipo de configuração que 99,9% dos usuários de Android vai ter ativa por acidente.

Shizuku e o ecossistema que vai quebrar

O Shizuku, criado pelo desenvolvedor RikkaApps, é provavelmente o projeto mais afetado. Ele permite que apps acessem APIs do sistema (como PackageManager, DevicePolicyManager, UserManager) sem root, usando permissões do ADB.

Na prática, o fluxo funciona assim:

App → Shizuku SDK → Conexão ADB loopback (127.0.0.1) → ADBD → API do sistema

Se o Google bloquear loopback, esse fluxo inteiro morre. E com ele, todos os apps que dependem do Shizuku:

E isso só conta os mais conhecidos. No GitHub, projetos que dependem do Shizuku somam centenas.

Além dos apps de power user, tem uma categoria que preocupa ainda mais: acessibilidade. Usuários com deficiências motoras ou visuais usam ferramentas baseadas em ADB on-device porque as APIs de acessibilidade nativas do Android são limitadas. Bloquear loopback remove opções que, pra essas pessoas, não são luxo. São necessidade.

A tese da comunidade: segurança ou controle?

Aqui é onde a conversa fica interessante. No Hacker News, a thread sobre o assunto explodiu com quase 800 upvotes e centenas de comentários. O sentimento geral? Ceticismo.

O argumento mais repetido: o Google está usando segurança como pretexto para fechar o ecossistema. Afinal, as mesmas ferramentas que permitem desinstalar bloatware também permitem remover os apps do Google que vêm pré-instalados. E apps como o Shizuku permitem controlar permissões de tracking de uma forma que o Android não oferece por padrão.

Um comentário que resume bem:

“Google restringe features sob pretexto de segurança enquanto seus próprios apps têm acesso extensivo e não verificado.”

Eu acho que a realidade é mais nuançada que isso. O CVE-2026-0073 era real e perigoso. Mas a resposta deveria ter sido proporcional: corrigir o bug (feito), melhorar a autenticação (feito), e talvez desabilitar loopback por padrão com uma opção para reativar. Bloquear permanentemente é usar um canhão pra matar formiga.

O padrão se repete: Apple fez o mesmo

Se essa história soa familiar, é porque a Apple seguiu um roteiro parecido com o iOS ao longo dos anos. A cada versão, APIs que davam poder ao usuário foram sendo removidas ou restringidas, sempre com justificativas de segurança e privacidade.

O resultado? Um ecossistema mais seguro, sim. Mas também mais fechado, onde você só pode fazer o que a Apple permite. E olha que até o Finder precisa de permissão especial pra acessar certas pastas no macOS hoje em dia.

O Android sempre foi o contraponto. A plataforma que te dava root, que deixava instalar APKs de fora da loja, que permitia automatizar tudo. Se o Google seguir por esse caminho, a diferença prática entre Android e iOS vai diminuir cada vez mais.

O que a proposta muda tecnicamente

Pra quem gosta de mergulhar no código, a mudança é no daemon ADBD. Hoje, quando o ADB over TCP/IP está ativo, o ADBD escuta em 0.0.0.0:5555 (todas as interfaces). A proposta é mudar isso para escutar apenas em interfaces específicas, usando SO_BINDTODEVICE ou filtrando por nome de interface.

// Antes: aceita conexão de qualquer interface
bind(sock, (struct sockaddr*)&addr, sizeof(addr));  // 0.0.0.0

// Depois (proposta): só aceita de wlan0
setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, "wlan0", strlen("wlan0"));

A diferença parece pequena, mas o impacto é brutal. Conexões vindas de 127.0.0.1 (loopback, interface lo) seriam simplesmente recusadas. Nenhum app rodando no próprio dispositivo conseguiria se conectar ao ADBD.

Existe uma diferença entre bloquear por padrão e bloquear permanentemente. O blog do Kitsumed faz essa distinção corretamente: se o Google oferecer uma opção em Developer Settings pra reativar loopback, o dano é mitigado. Mas se for um bloqueio hard-coded sem escape, aí é outra conversa.

Alternativas que o Google poderia (e deveria) considerar

Em vez de bloquear tudo, existem abordagens mais equilibradas:

1. Loopback desabilitado por padrão, com toggle

Adicionar uma opção em “Developer options” chamada algo como “Allow on-device ADB connections”. Desligada por padrão, protege 99% dos usuários. Quem precisa, ativa conscientemente.

2. Permissão por app

Assim como o Android pergunta “Permitir que esse app acesse a câmera?”, poderia perguntar “Permitir que esse app se conecte ao ADB local?”. Granular e transparente.

3. Sandbox para conexões ADB locais

Limitar o que conexões loopback podem fazer. Permitir operações de leitura e gerenciamento de pacotes, mas bloquear operações mais perigosas como run-as e execução de binários arbitrários.

4. Verificação de integridade do app chamador

Exigir que apps que se conectam via loopback tenham uma assinatura válida e estejam listados num whitelist configurável pelo usuário.

Qualquer uma dessas opções protege contra ataques reais sem destruir um ecossistema inteiro de ferramentas úteis.

Como se proteger enquanto isso

Se você depende do Shizuku ou de ferramentas similares, algumas precauções:

• Atualize o Android para o patch level de maio 2026 ou posterior (isso corrige o CVE-2026-0073)
• Desative ADB wireless quando não estiver usando
• Não conecte em Wi-Fi públicas com ADB ativo
• Monitore o Issue Tracker do Android pra acompanhar se a proposta avança
• Considere alternativas: para algumas tarefas, o Magisk + módulos pode ser uma alternativa mais duradoura (embora exija bootloader desbloqueado)

Se a proposta for implementada, versões futuras do Android (provavelmente Android 17 ou 16-QPR3) virão com a restrição. Dispositivos atuais com versões mais antigas continuarão funcionando normalmente.

O elefante na sala: Google Play Protect

Tem um detalhe que quase ninguém menciona nessa discussão. O Google Play Protect, o antimalware embutido no Android, já tem capacidade de detectar e bloquear apps que tentam explorar ADB de forma maliciosa. Se a preocupação é com apps maliciosos usando loopback para escalar privilégios, por que não melhorar a detecção no Play Protect em vez de matar a funcionalidade inteira?

A resposta cínica é que o Play Protect não funciona tão bem assim. Um estudo da AV-TEST de 2025 mostrou que ele detecta apenas 83% das ameaças, enquanto concorrentes como Bitdefender e Kaspersky ficam acima de 99%. Mas aí a solução deveria ser melhorar o Play Protect, não punir os devs.

Histórico: o Google já fez isso antes

Quem acompanha o ecossistema Android de perto sabe que essa não é a primeira vez. O Google tem um padrão de restringir APIs sob o argumento de segurança:

• Android 9 (2018): bloqueou acesso a APIs ocultas via reflexão. Milhares de apps quebraram.
• Android 10 (2019): restringiu acesso ao armazenamento com Scoped Storage. File managers ficaram limitados.
• Android 12 (2021): removeu a capacidade de apps enumerarem outros apps instalados.
• Android 14 (2023): bloqueou sideload de APKs com target SDK muito antigo.
• Manifest V3 (Chrome): matou bloqueadores de anúncios baseados em webRequest.

Em cada caso, a justificativa foi segurança ou privacidade. Em cada caso, funcionalidades legítimas foram prejudicadas. E em cada caso, o Google ganhou mais controle sobre o que roda na plataforma.

A restrição do ADB on-device se encaixa perfeitamente nesse padrão. O bug era real? Sim. A correção proporcional seria corrigir o bug (feito) e melhorar a autenticação (feito). Bloquear toda uma categoria de funcionalidade é desproporcional, e convenientemente alinhado com os interesses comerciais do Google.

O que vem por aí

A proposta ainda está em discussão no Issue Tracker do Google. Não é uma mudança confirmada. Mas considerando o histórico do Google com decisões unilaterais (lembram do Manifest V3 nas extensões do Chrome?), eu não ficaria surpreso se ela passar sem grandes modificações.

O que podemos fazer? Participar da discussão. Comentar no Issue Tracker. Mostrar casos de uso legítimos. Explicar o impacto em acessibilidade. A comunidade Android sempre foi vocal, e às vezes o Google escuta.

Enquanto isso, se você usa Shizuku, aproveita que ainda funciona. E talvez faça um backup das suas configurações.

Fonte de inspiração: Android May Soon Restrict On-Device ADB por Kitsumed