Pourquoi une application Android bloquée affiche encore de la consommation réseau

Vous bloquez une application dans votre pare-feu VPN Android, l’application cesse de fonctionner, et sa ligne de consommation continue de grimper. La conclusion tentante est que le blocage a fui, ou que le compteur est cassé. Ni l’une ni l’autre ne s’ensuit. Un relevé de consommation dit que des octets ont été attribués à cette identité à un certain point d’observation ; il ne dit rien sur le fait qu’un service distant ait accepté une requête. Une fois que vous savez quelle frontière a été mesurée et à quelle identité elle a été imputée, les deux observations cessent de se contredire.

Le compteur mesure des octets, pas une livraison

Android attribue le trafic à un UID et le compte dans les deux sens, et il le fait à une frontière d’interface plutôt qu’au moment où la requête d’une application réussit.

Une tentative de connexion refusée déplace quand même des paquets : le SYN, le reset ou les retransmissions qui suivent, plus la requête DNS qui a précédé les deux. Ces octets existent même si rien n’a été livré, et sur certains chemins ils sont comptés avant qu’un filtre décide quoi en faire.

C’est pourquoi la ligne d’une application bloquée peut croître alors que chaque requête échoue. Le compteur répond à « combien d’octets ont été attribués à cette identité », pas à « cette identité a-t-elle atteint internet ». Un graphique ne peut pas distinguer un flux accepté d’une poignée de main refusée poliment, et un total qui additionne les deux sens ne le peut pas davantage.

L’attribution suit l’UID, pas l’icône

La ligne est par UID, et un UID peut être partagé par plusieurs paquets, tandis qu’une application visible peut confier le travail à un composant séparé qui tourne sous sa propre identité. Un onglet de navigateur rendu par un processus WebView partagé, un service de synchronisation en arrière-plan ou un paquet compagnon installé à côté de l’application principale produisent tous du trafic que l’écran de consommation peut afficher sous un nom que vous n’attendiez pas, ou sous l’application que vous avez bien bloquée. Un paquet bloqué et un assistant qui porte ses requêtes sont deux sujets différents, et la règle n’en couvrait qu’un seul.

Quand les chiffres semblent faux, comparez l’UID plutôt que l’étiquette. L’API de consommation s’interroge par UID, et adb shell dumpsys package <package> | grep userId= imprime le nombre auquel comparer, de sorte que deux entrées ayant le même UID sont la même identité du point de vue du compteur.

La fenêtre temporelle peut précéder votre règle

Les données de consommation sont collectées par tranches et interrogées périodiquement, pas diffusées en direct. Un total journalier peut inclure les minutes précédant l’activation du blocage, une synchronisation en arrière-plan de l’heure précédente ou du trafic déjà en cours. Comparer un total cumulé à une seule requête refusée et appeler la différence une fuite est une erreur de mesure, pas une découverte du pare-feu.

Utilisez une fenêtre plus courte et un départ propre. Notez l’horodatage au moment où vous changez la règle, attendez un intervalle de collecte, puis ne regardez que les données postérieures. Si le total continue de monter sur une fenêtre qui commence après la règle, vous avez quelque chose à examiner ; s’il cesse de monter, la croissance antérieure était de l’historique affiché.

Le service VPN n’est peut-être pas celui que vous avez configuré

Un pare-feu VPN ne voit que le trafic que son propre service transporte. Si une autre application VPN démarre et prend la connexion active, votre filtre n’est plus sur le chemin alors que son interface existe toujours dans les réglages. Les listes de contournement par application font la même chose délibérément, et un profil qui exclut une application n’est pas une fuite lorsque l’application fonctionne ensuite.

IPv4, IPv6 et DNS peuvent aussi diverger. Un filtre qui gère IPv4 peut laisser IPv6 ou un résolveur DNS privé en dehors, si bien qu’une partie du trafic de l’application suit un chemin que vos règles n’ont jamais décrit. Vérifiez quelle application possède actuellement le VPN et ce que dit la liste d’exclusions avant de réécrire quoi que ce soit :

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

Testez une requête fraîche et notez quatre faits

Choisissez une requête inoffensive, exécutez-la une fois et notez quatre faits : la règle en vigueur, l’UID de l’application, l’état du réseau et l’heure. Vérifiez ensuite si votre filtre a journalisé le flux, et si la destination ou la passerelle a vu la même connexion. Un flux identifié des deux côtés est une preuve ; un total agrégé n’en est pas une.

Une conclusion défendable nomme ce qui a été refusé et quelle observation l’a confirmé. « Le compteur a monté » n’est pas une découverte, et « tous les compteurs de consommation sont faux » n’en est pas une non plus. Un slogan de couche OSI ne tranche pas cela : la réponse honnête est que le compteur et le blocage peuvent tous deux être corrects tout en décrivant des choses différentes. La référence NetworkStatsManager d’Android documente comment ces tranches sont interrogées et attribuées.