Google pondera limitar ADB no Android

A Google está a discutir uma alteração pouco sexy mas com efeitos bem reais: mudar a forma como o Android deixa falar com o próprio Android. Em concreto, restringir o daemon do Android Debug Bridge, o adbd, para só ouvir em interfaces externas, como Wi-Fi ou USB, e cortar o acesso em 127.0.0.1, o clássico localhost. Para quem vive de ROMs, scripts e ajustes finos, isto não é detalhe de bastidor, é mexer na chave de fendas principal.

O cenário vem documentado por um developer Android, Kitsumed, que destrinçou uma proposta no Issue Tracker público da Google. A ideia: adbd deixa de aceitar ligações em loopback local e passa a estar preso à interface Wi-Fi, tipo wlan0, ou a USB. Na prática, aquilo que hoje chamamos “on-device ADB” deixa de funcionar. Apps como o Termux perdem a capacidade de abrir um terminal no telemóvel e falar diretamente com o sistema com privilégios elevados. E frameworks como o Shizuku, que dependem de ADB temporário para dar permissões especiais a outras apps sem root permanente, ficam debaixo de fogo.

O motivo oficial é a segurança. A discussão arranca de uma falha concreta, a CVE-2026-0073, que permitia a um atacante em qualquer rede ligada, tipo Wi-Fi público, contornar a autenticação do ADB sem fios. A vulnerabilidade já foi corrigida nos patches de segurança de maio de 2026, mas a equipa de plataforma olha para o quadro maior: cada socket de debug exposto é mais uma superfície de ataque. Se o adbd estiver limitado a uma interface de Wi-Fi de confiança ou a um cabo USB, fecha-se parte dessa porta. Do ponto de vista corporativo, faz sentido. Do ponto de vista de quem usa o telemóvel como máquina Linux de bolso, é um murro no estômago.

Há aqui um detalhe que a Google nunca assume frontalmente: on-device ADB é hoje o truque limpo para fugir a algumas limitações sem estragar o selo de segurança. Ferramentas rootless permitem automatizar, desinstalar lixo de fábrica, mexer em UI e permissões, tudo isto sem desencadear todos os alarmes de Play Integrity e companhia. Ao cortar o loopback local, a Google não está só a mitigar abusos teóricos, está também a apertar mais um parafuso naquilo que o utilizador consegue controlar sem pedir autorização ao fabricante. Vindo da mesma casa que anda a redefinir limites do Android com cada geração de Pixel, o padrão começa a ser difícil de ignorar.

Na thread pública, o engenheiro da Google identificado como maintainer do ADB fala num balanço entre risco e funcionalidade e diz que vai “avaliar” depois do feedback. Alguns developers já sugeriram uma solução óbvia: meter isto atrás de um toggle avançado nas Opções de Programador, opt-in, bem escondido, com avisos grandes em letras gordas. É o tipo de compromisso que protege 99% dos utilizadores e não castiga o 1% que sabe exatamente o que está a fazer. Se a Google aceitar, mantém-se a porta entreaberta. Se insistir em fechar o localhost por decreto, teremos mais um caso em que a segurança serve de argumento para tratar power users como problema.

Por agora nada é definitivo, a discussão está em aberto e é pública. Quem depende de Termux, Shizuku e companhia tem interesse em aparecer ali com argumentos técnicos e casos de uso sólidos, não com indignação vazia. A história do Android está cheia de APIs e truques “temporários” que se tornaram base para comunidades inteiras. Cortar este canal seria mais um passo rumo a um Android que funciona impecavelmente para a maioria, mas cada vez menos hackável para quem gosta de ter o telemóvel verdadeiramente na mão.

Fonte: Android Authority