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 工具。
要求
-
內核配置必須開啟以下配置：
驗證是否已開啟正確配置時，VTS 內核配置測試非常有用。
-
CONFIG_CGROUP_BPF=y -
CONFIG_BPF=y -
CONFIG_BPF_SYSCALL=y -
CONFIG_NETFILTER_XT_MATCH_BPF=y -
CONFIG_INET_UDP_DIAG=y
-
-
設備
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
