DataUsageController (un composant de l'application Paramètres) collecte des données à partir de NetworkStatsService (1) qui fait partie du framework Android, c'est-à-dire system_server et dépend de (2) TrafficController (un composant du service natif netd) qui utilise à son tour libqtaguid pour taguer les sockets réseau sur une base par application/UID. Auparavant, le module kernel qtaguid était utilisé pour suivre les sockets tagués (en lisant "/proc/net/xt_qtaguid/stats" (3)) qui est remplacé par le framework eBPF désormais. Désormais, l'utilisation des données sera disponible dans un système de fichiers virtuel ("/sys/fs/bpf/traffic_uid_stats_map" (4)).
Les restrictions de politique réseau (Données/Économiseur de batterie et Données d'arrière-plan (5)) et Limitation/Alerte de données sont principalement mises en œuvre par NetworkPolicyManager et NetworkManagementService. En arrière-plan, netd insère/supprime des règles iptables (6) pour imposer des restrictions dans l'espace du noyau.
Les modules qtaguid (7) et quota2 font partie uniquement du noyau Android (8) tandis que owner fait partie du noyau Linux principal.
LIÉ: Comment visualiser le trafic réseau demandé par une application spécifique ?
RÉFÉRENCES:
1. Celui auquel nous pouvons accéder avec dumpsys netstats
2. À travers NetworkStatsManager / TrafficStats / SocketTagger, JNI NetworkManagementSocketTagger, libcutils (qtaguid), NetdClient, le serveur FwmarkServer de Netd et éventuellement d'autres
5. Peut être lu / défini par dumpsys netpolicy et cmd netpolicy
6. En utilisant les modules owner et quota2
7. Basé sur le module owner et dépend du module socket
0 votes
Ainsi, vos "< settings -> data >" ne sont pas suivis correctement?
0 votes
@rogerdpack Oui