Por que um aplicativo Android bloqueado ainda mostra consumo de rede

Você bloqueia um aplicativo no firewall VPN do Android, o aplicativo para de funcionar e sua linha de consumo continua subindo. A conclusão tentadora é que o bloqueio vazou, ou que o contador está quebrado. Nenhuma das duas se segue. Um registro de consumo diz que bytes foram atribuídos àquela identidade em algum ponto de observação; ele não diz nada sobre se um serviço remoto aceitou uma requisição. Quando você sabe qual fronteira foi medida e a qual identidade ela foi debitada, as duas observações param de se contradizer.

O contador mede bytes, não entrega

O Android atribui tráfego a um UID e o conta nos dois sentidos, e faz isso numa fronteira de interface, não no momento em que a requisição de um aplicativo tem sucesso.

Uma tentativa de conexão recusada ainda move pacotes: o SYN, o reset ou as retransmissões que seguem, além da consulta DNS que precedeu ambos. Esses bytes existem mesmo quando nada foi entregue, e em alguns caminhos são contados antes que qualquer filtro decida o que fazer com eles.

É por isso que a linha de um aplicativo bloqueado pode crescer enquanto toda requisição falha. O contador responde «quantos bytes foram atribuídos a esta identidade», não «esta identidade chegou à internet». Um gráfico não consegue distinguir um fluxo aceito de um aperto de mão recusado com educação, e um total que soma os dois sentidos também não.

A atribuição segue o UID, não o ícone

A linha é por UID, e um UID pode ser compartilhado por mais de um pacote, enquanto um aplicativo visível pode entregar trabalho a um componente separado que roda sob a própria identidade. Uma aba de navegador desenhada por um processo WebView compartilhado, um serviço de sincronização em segundo plano ou um pacote companheiro instalado ao lado do aplicativo principal produzem tráfego que a tela de consumo pode mostrar sob um nome que você não esperava, ou sob o aplicativo que você bloqueou. Um pacote bloqueado e um auxiliar que carrega suas requisições são dois sujeitos diferentes, e a regra cobria apenas um deles.

Quando os números parecerem errados, compare o UID em vez do rótulo. A API de consumo é consultada por UID, e adb shell dumpsys package <package> | grep userId= imprime o número com que comparar, então duas entradas com o mesmo UID são a mesma identidade do ponto de vista do contador.

A janela de tempo pode ser anterior à sua regra

Os dados de consumo são coletados em blocos e consultados periodicamente, não transmitidos ao vivo. Um total diário pode incluir os minutos anteriores à ativação do bloqueio, uma sincronização em segundo plano da hora anterior ou tráfego que já estava em curso. Comparar um total acumulado com uma única requisição recusada e chamar a diferença de vazamento é um erro de medição, não uma descoberta do firewall.

Use uma janela mais curta e um início limpo. Anote o carimbo de tempo ao mudar a regra, espere um intervalo de coleta e depois olhe apenas os dados posteriores. Se o total continua subindo numa janela que começa depois da regra, você tem algo a investigar; se para de subir, o crescimento anterior era histórico sendo exibido.

O serviço VPN pode não ser o que você configurou

Um firewall VPN só vê o tráfego que o próprio serviço carrega. Se outro aplicativo VPN inicia e assume a conexão ativa, seu filtro não está mais no caminho enquanto a interface dele ainda existe nas configurações. As listas de exceção por aplicativo fazem o mesmo de propósito, e um perfil que exclui um aplicativo não é vazamento quando o aplicativo depois funciona.

IPv4, IPv6 e DNS também podem divergir. Um filtro que trata IPv4 pode deixar IPv6 ou um resolvedor DNS privado fora dele, de modo que parte do tráfego do aplicativo segue um caminho que suas regras nunca descreveram. Verifique qual aplicativo possui a VPN no momento e o que diz a lista de exclusões antes de reescrever qualquer coisa:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

Teste uma requisição nova e registre quatro fatos

Escolha uma requisição inofensiva, faça-a uma vez e anote quatro fatos: a regra em vigor, o UID do aplicativo, o estado da rede e a hora. Depois verifique se o seu filtro registrou o fluxo, e se o destino ou o gateway viram a mesma conexão. Um fluxo identificado dos dois lados é evidência; um total agregado não é.

Uma conclusão defensável nomeia o que foi negado e qual observação confirmou isso. «O contador subiu» não é uma descoberta, e «todos os contadores de consumo são falsos» também não. Um slogan de camada OSI não resolve isso: a resposta honesta é que o contador e o bloqueio podem ambos estar corretos enquanto descrevem coisas diferentes. A referência NetworkStatsManager do Android documenta como esses blocos são consultados e atribuídos.