Por que unha aplicación de Android bloqueada segue mostrando consumo de rede

Bloquea unha aplicación no seu cortalumes VPN de Android, a aplicación deixa de funcionar e a súa fila de consumo segue subindo. A conclusión tentadora é que o bloqueo se filtrou ou que o contador está roto. Ningunha das dúas se segue. Un rexistro de consumo di que se atribuíron bytes a esa identidade nalgún punto de observación; non di nada sobre se un servizo remoto aceptou unha solicitude. Cando sabe que fronteira se mediu e a que identidade se lle cargou, as dúas observacións deixan de contradicirse.

O contador mide bytes, non entrega

Android atribúe o tráfico a un UID e cóntao en ambos os sentidos, e faino nunha fronteira de interface, non no momento en que unha solicitude da aplicación ten éxito.

Un intento de conexión rexeitado segue movendo paquetes: o SYN, o reset ou as retransmisións que lle seguen, máis a consulta DNS que precedeu a ambos. Esos bytes existen aínda que non se entregase nada, e nalgúns camiños cóntanse antes de que ningún filtro decida que facer con eles.

Por iso a fila dunha aplicación bloqueada pode crecer mentres todas as solicitudes fallan. O contador responde «cantos bytes se atribuíron a esta identidade», non «se esta identidade chegou a internet». Un gráfico non pode distinguir un fluxo aceptado dun aperto de mans rexeitado con cortesía, e un total que suma ambos os sentidos tampouco.

A atribución segue o UID, non a icona

A fila é por UID, e un UID pode ser compartido por máis dun paquete, mentres que unha aplicación visible pode ceder o traballo a un compoñente separado que se executa coa súa propia identidade. Unha pestana do navegador debuxada por un proceso WebView compartido, un servizo de sincronización en segundo plano ou un paquete complementario instalado xunto á aplicación principal producen tráfico que a pantalla de consumo pode mostrar cun nome que non esperaba, ou baixo a aplicación que si bloqueou. Un paquete bloqueado e un axudante que transporta as súas solicitudes son dous suxeitos distintos, e a regra só cubría un deles.

Cando as cifras parezan mal, compare o UID en lugar da etiqueta. A API de consumo consúltase por UID, e adb shell dumpsys package <package> | grep userId= imprime o número co que debe comparar, así que dúas entradas co mesmo UID son a mesma identidade desde o punto de vista do contador.

A xanela temporal pode ser anterior á súa regra

Os datos de consumo recóllense en bloques e consultan periodicamente, non se transmiten en vivo. Un total diario pode incluír os minutos previos a activar o bloqueo, unha sincronización en segundo plano da hora anterior ou tráfico que xa estaba en curso. Comparar un total acumulado cunha soa solicitude rexeitada e chamar filtración á diferenza é un erro de medición, non un achado do cortalumes.

Use unha xanela máis curta e un inicio limpo. Anote a marca de tempo ao cambiar a regra, espere un intervalo de recollida e despois mire só os datos posteriores. Se o total segue subindo nunha xanela que comeza despois da regra, ten algo que investigar; se deixa de subir, o crecemento anterior era historia que se mostraba.

O servizo VPN pode non ser o que configurou

Un cortalumes VPN só ve o tráfico que transporta o seu propio servizo. Se outra aplicación VPN se inicia e toma a conexión activa, o seu filtro xa non está na ruta mentres a súa interface segue existindo nos axustes. As listas de omisión por aplicación fan o mesmo a propósito, e un perfil que exclúe unha aplicación non é unha filtración cando a aplicación despois funciona.

IPv4, IPv6 e DNS tamén poden diverxir. Un filtro que xestiona IPv4 pode deixar IPv6 ou un resolvedor DNS privado fóra del, de modo que parte do tráfico da aplicación segue unha ruta que as súas regras nunca describiron. Comprobe que aplicación posúe agora a VPN e que di a lista de exclusións antes de reescribir nada:

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

Probe unha solicitude nova e anote catro feitos

Escolla unha solicitude inocua, execútea unha vez e anote catro feitos: a regra vixente, o UID da aplicación, o estado da rede e a hora. Despois comprobe se o seu filtro rexistrou o fluxo e se o destino ou a pasarela viron a mesma conexión. Un fluxo identificado en ambos os lados é unha proba; un total agregado non o é.

Unha conclusión defendible nomea que se denegou e que observación o confirmou. «O contador subiu» non é un achado, e «todos os contadores de consumo son falsos» tampouco. Un eslogan de capa OSI non resolve isto: a resposta honesta é que o contador e o bloqueo poden ser ambos correctos mentres describen cousas distintas. A referencia NetworkStatsManager de Android documenta como se consultan e se atribúen eses bloques.