eBPF 网络流量工具结合使用内核与用户空间实现来监控设备自上次启动以来的网络使用情况。它提供了额外的功能（如套接字标记、分离前台/后台流量，以及按 UID 划分的防火墙），以根据手机状态阻止应用访问网络。从该工具收集的统计数据存储在称为 eBPF maps的内核数据结构中，并且相应结果由NetworkStatsService等服务用来提供自设备上次启动以来的持久流量统计数据。

示例和来源

用户空间更改主要在 system/netd和framework/base项目中。开发工作在 AOSP 中完成，因此 AOSP 代码将始终保持最新状态。源代码主要位于
system/netd/server/TrafficController*、system/netd/bpfloader和system/netd/libbpf/中。此外，一些必要的框架变更也在framework/base/和system/core中。

实现

从 Android 9 开始，内核版本为 4.9 或更高且最初搭载了 Android P 版本的 Android 设备必须使用基于 eBPF 的网络流量监控记帐模块，而不是 xt_qtaguid。新的基础架构更灵活且更易于维护，并且不需要任何外部内核代码。

旧版流量监控和 eBPF 流量监控之间的主要设计差异如图 1 所示。

图 1.旧版流量监控（左）和 eBPF 流量监控（右）的设计差异

新的 trafficController设计基于cgroup级的 eBPF 过滤器以及内核中的xt_bpfnetfilter 模块。这些 eBPF 过滤器在收发数据包时应用，数据包需要通过这些过滤器。cgroupeBPF 过滤器位于传输层，负责根据套接字 UID 以及用户空间设置对正确的 UID 计算流量。xt_bpfnetfilter 挂接在bw_raw_PREROUTING和bw_mangle_POSTROUTING链上，负责对正确的接口计算流量。

在启动时，用户空间进程 trafficController会创建用于收集数据的 eBPF 映射，并将所有映射作为虚拟文件固定在sys/fs/bpf。然后，特权进程bpfloader将预编译的 eBPF 程序加载到内核中，并将其附加到正确的cgroup。所有流量都对应于同一个根cgroup，因此默认情况下，所有进程都应包含在该cgroup中。

在运行时，trafficController可以通过将数据写入traffic_cookie_tag_map和
traffic_uid_counterSet_map来标记/取消标记套接字。NetworkStatsService可以从traffic_tag_stats_map、traffic_uid_stats_map和traffic_iface_stats_map中读取流量统计数据。除了流量统计数据收集功能之外，trafficController和cgroupeBPF 过滤器还负责根据手机设置屏蔽来自某些 UID 的流量。基于 UID 的网络流量屏蔽功能取代了内核中的xt_owner模块，并且可以通过将数据写入traffic_powersave_uid_map、traffic_standby_uid_map和traffic_dozable_uid_map来配置详细模式。

新实现遵循旧版 xt_qtaguid模块实现，因此TrafficController和NetworkStatsService将使用旧版实现或新实现运行。如果应用使用公共 API，那么无论在后台使用xt_qtaguid还是 eBPF 工具，应该没有任何区别。

如果设备内核基于 Android 通用内核 4.9（
SHA39c856663dcc81739e52b02b77d6af259eb838f6 或更高版本），则无需修改 HAL、驱动程序或内核代码，即可实现新的 eBPF 工具。

要求

1. 内核配置必须开启以下配置：

   验证是否已开启正确配置时，VTS 内核配置测试非常有用。

   1. CONFIG_CGROUP_BPF=y

   2. CONFIG_BPF=y

   3. CONFIG_BPF_SYSCALL=y

   4. CONFIG_NETFILTER_XT_MATCH_BPF=y

   5. CONFIG_INET_UDP_DIAG=y

2. 设备 MEM_LOCK资源限制必须设为 8 MB 或更多。

旧版 xt_qtaguid 弃用过程

新的 eBPF 工具正在逐步取代 xt_qtaguid模块以及它所基于的xt_owner模块。我们将开始从 Android 内核中移除xt_qtaguid模块，并停用不必要的配置。

在 Android 9 版本中，xt_qtaguid模块在所有设备上都处于开启状态，但直接读取xt_qtaguid模块 proc 文件的所有公共 API 都移到了NetworkManagement服务中。根据设备内核版本和初始 API 级别，NetworkManagement服务能够知道 eBPF 工具是否处于开启状态，并选择正确的模块来获取每个应用的网络使用情况统计数据。sepolicy 会阻止 SDK 级别为 28 及以上的应用访问xt_qtaguidproc 文件。

在 Android 9 之后的下一个版本中，我们将完全阻止应用访问这些 xt_qtaguidproc 文件，并开始从新的 Android 通用内核中移除xt_qtaguid模块。移除该模块后，我们将更新相应内核版本的 Android 基础配置，以明确关闭xt_qtaguid模块。当 Android 版本的最低内核版本要求为 4.9 或更高时，我们将彻底弃用xt_qtaguid模块。

在 Android 9 版本中，只有搭载 Android 9 版本的设备才需要具备新的 eBPF 功能。如果设备搭载的内核可以支持 eBPF 工具，我们建议在升级到 Android 9 版本时，将设备更新为采用新的 eBPF 功能。没有强制执行该更新的 CTS 测试。

验证

您应该定期从 Android 通用内核和 Android AOSP 主分支获取补丁程序。请确保您的实现通过适用的 VTS 和 CTS 测试，即 netd_unit_test和libbpf_test。

测试

提供了内核 net_tests，用来确保您开启了必需的功能，并向后移植了必需的内核补丁程序。这些测试已集成到 Android 9 版本 VTS 测试中。system/netd/中有一些单元测试（netd_unit_test和libbpf_test）。netd_integration_test中有一些验证新工具整体行为的测试。

CTS 和 CTS 验证程序

由于这两个流量监控模块在 Android 9 版本中都得到支持，因此没有强制在所有设备上实现新模块的 CTS 测试。不过，对于内核版本高于 4.9 且最初搭载了 Android 9 版本（即，初始 API 级别大于等于 28）的设备，提供了基于 GSI 的 CTS 测试，用于验证是否正确配置了新模块。旧的 CTS 测试（如TrafficStatsTest、NetworkUsageStatsTest和CtsNativeNetTestCases）可用于验证新模块的行为是否与旧的 UID 模块一致。

手动测试

system/netd/中有一些单元测试（netd_unit_test、netd_integration_test和libbpf_test）。此外，还提供了 dumpsys 支持，以便手动检查状态。dumpsys netd命令可显示trafficController模块的基本状态以及是否正确开启了 eBPF。如果 eBPF 处于开启状态，dumpsys netd trafficcontroller命令会显示每个 eBPF 映射的详细内容，包括带标记的套接字信息、每个标记的统计数据、UID 和 iface，以及所有者 UID 匹配项。

测试所在位置

CTS 测试位于以下位置：

• https://android.googlesource.com/platform/cts/+/master/tests/tests/net/src/android/net/cts/TrafficStatsTest.JAVA

• https://android.googlesource.com/platform/cts/+/master/tests/tests/App.usage/src/android/app/usage/cts/NetworkUsageStatsTest.java

• https://android.googlesource.com/platform/system/netd/+/master/tests/bpf_base_test.cpp

VTS 测试位于 
https://android.googlesource.com/kernel/tests/+
/master/net/test/bpf_test.py。

单元测试位于以下位置：

• https://android.googlesource.com/platform/system/netd/+/master/libbpf/BpfNetworkStatsTest.cpp

• https://android.googlesource.com/platform/system/netd/+/master/server/TrafficControllerTest.cpp