Varför en blockerad Android-app fortfarande visar nätverksanvändning

Du blockerar en app i din Android-VPN-brandvägg, appen slutar fungera och dess användningsrad fortsätter att stiga. Den frestande slutsatsen är att blockeringen läckte, eller att räknaren är trasig. Ingen av dem följer. En användningspost säger att byte tilldelades den identiteten vid någon observationspunkt; den säger ingenting om huruvida en fjärrtjänst accepterade en begäran. När du vet vilken gräns som mättes och vilken identitet den belastades på, slutar de två observationerna att motsäga varandra.

Räknaren mäter byte, inte leverans

Android tilldelar trafik till ett UID och räknar den i båda riktningarna, och det görs vid en gränssnittsgräns snarare än i det ögonblick en apps begäran lyckas.

Ett avvisat anslutningsförsök flyttar ändå paket: SYN, återställningen eller de efterföljande omsändningarna, plus DNS-frågan som föregick båda. De byten finns även när ingenting levererades, och på vissa vägar räknas de innan något filter bestämmer vad som ska göras med dem.

Därför kan raden för en blockerad app växa medan varje begäran misslyckas. Räknaren svarar på ”hur många byte tilldelades denna identitet”, inte ”nådde denna identitet internet”. Ett diagram kan inte skilja ett accepterat flöde från ett artigt avvisat handslag, och en summa som adderar båda riktningarna kan inte heller.

Tilldelningen följer UID:n, inte ikonen

Raden är per UID, och ett UID kan delas av mer än ett paket, medan en synlig app kan lämna arbete till en separat komponent som körs under sin egen identitet. En webbläsarflik som ritas av en delad WebView-process, en bakgrundssynkroniseringstjänst eller ett följepaket installerat bredvid huvudappen producerar alla trafik som användningsskärmen kan visa under ett namn du inte väntade dig, eller under appen du faktiskt blockerade. Ett blockerat paket och en hjälpare som bär dess begäranden är två olika subjekt, och regeln täckte bara ett av dem.

När siffrorna ser fel ut, jämför UID i stället för etiketten. Användnings-API:t frågas per UID, och adb shell dumpsys package <package> | grep userId= skriver ut talet du ska jämföra med, så två poster med samma UID är samma identitet sett från räknaren.

Tidsfönstret kan vara äldre än din regel

Användningsdata samlas i hinkar och pollas, inte strömmas live. En dygnssumma kan omfatta minuterna innan du aktiverade blockeringen, en bakgrundssynkronisering från timmen före eller trafik som redan var på väg. Att jämföra en kumulativ summa med en enda avvisad begäran och kalla skillnaden en läcka är ett mätfel, inte ett brandväggsfynd.

Använd ett kortare fönster och en ren start. Notera tidsstämpeln när du ändrar regeln, vänta ett insamlingsintervall och titta sedan bara på data efter det. Om summan fortsätter att stiga i ett fönster som börjar efter regeln har du något att undersöka; om den slutar stiga var den tidigare tillväxten visad historik.

VPN-tjänsten är kanske inte den du konfigurerade

En VPN-brandvägg ser bara trafik som dess egen tjänst bär. Om en annan VPN-app startar och tar över den aktiva anslutningen är ditt filter inte längre i vägen medan dess gränssnitt fortfarande finns i inställningarna. Listor för kringgående per app gör samma sak med avsikt, och en profil som utesluter en app är inte en läcka när appen sedan fungerar.

IPv4, IPv6 och DNS kan också gå isär. Ett filter som hanterar IPv4 kan lämna IPv6 eller en privat DNS-resolver utanför, så en del av appens trafik följer en väg som dina regler aldrig beskrev. Kontrollera vilken app som för närvarande äger VPN:en och vad uteslutningslistan säger innan du skriver om något:

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

Testa en färsk begäran och notera fyra fakta

Välj en ofarlig begäran, utför den en gång och skriv ner fyra fakta: regeln som gäller, appens UID, nätverkstillståndet och tiden. Kontrollera sedan om ditt filter loggade flödet, och om målet eller gatewayen såg samma anslutning. Ett flöde identifierat på båda sidor är bevis; en samlad summa är det inte.

En försvarbar slutsats namnger vad som nekades och vilken observation som bekräftade det. ”Räknaren steg” är inte ett fynd, och ”alla användningsräknare är falska” är det inte heller. En OSI-lagerslogan avgör inte detta: det ärliga svaret är att räknaren och blockeringen båda kan vara korrekta medan de beskriver olika saker. Androids NetworkStatsManager-referens dokumenterar hur dessa hinkar frågas och tilldelas.