自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
网络共享硬件分流
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
通过将网络共享流量(借助 USB、Wi-Fi)分流到硬件,网络共享分流可让设备节省电量并提高性能。通过在调制解调器和外围设备之间提供直接路径,并绕过应用处理器,可以分流网络共享流量。
规范
从 Android 8.1 开始,设备可以使用网络共享分流将 IPv4、IPv6 或 IPv4+IPv6 转发分流到硬件。
分流功能不需要分流所有数据包。框架能够处理软件中的任何数据包。控制数据包通常是在软件中处理。由于 IPv4 端口在网络共享流量和设备流量之间共享,因此必须在软件中处理 IPv4 会话设置/拆解数据包(例如,SYN/SYN+ACK、FIN),以便内核可以构建流程状态。框架提供了控制平面和状态机,还为硬件提供了有关上游和下游接口/前缀的信息。
对于 IPv4,硬件允许 IPv4 网络地址转换 (NAT) 会话设置数据包到达 CPU。内核会创建 NAT 条目,HAL 实现会观察框架提供的文件描述符中的条目,并在硬件中处理这些流程。这意味着 HAL 实现不需要 CAP_NET_*
,因为 HAL 会从框架中获取打开的 NF_NETLINK_CONNTRACK
套接字。硬件会定期将当前活动流程的 NAT 状态更新发送给框架,框架会刷新相应的内核连接跟踪状态条目。
对于 IPv6,框架会编制一个不得将流量分流到的 IPv6 目标前缀的列表。所有其他网络共享数据包都可以分流。
NetworkStatsService
数据流量使用情况轮询会使框架向硬件请求流量统计信息,以便计算数据流量使用量。框架还会通过 HAL 向硬件传达数据流量使用限制。
硬件要求
如需实现网络共享分流,您的硬件必须能够在调制解调器和 Wi-Fi/USB 之间转发 IP 数据包,而无需通过主处理器发送流量。
实现
如需启用网络共享分流功能,您必须同时实现配置 HAL (IOffloadConfig
) 和控制 HAL (IOffloadControl
)。
配置 HAL:IOffloadConfig
IOffloadConfig
HAL 会启动网络共享分流实现。框架会为 HAL 实现提供预先连接的 NF_NETLINK_CONNTRACK
套接字,以供该实现观察 IPv4 流程。只有转发的流程必须加速。
控制 HAL:IOffloadControl
IOffloadControl
HAL 会控制分流实现。必须实现以下方法:
- 启动/停止分流硬件:使用
initOffload/stopOffload
,并使用 setLocalPrefixes
让本地 IP 地址或其他网络免于分流。
- 设置上游接口、IPv4 地址和 IPv6 网关:使用
setUpstreamParameters
,并使用 addDownstream/removeDownstream
配置下游 IP 地址范围。
- 计算数据流量使用量:使用
getForwardedStats/setDataLimit
。
您的供应商 HAL 还必须通过 ITetheringOffloadCallback
接口发送回调,该接口会通知框架:
- 分流等异步事件被启动和停止 (OffloadCallbackEvent)
- NAT 超时更新,必须定期发送这些更新以表明特定 IPv4 流程包含流量且不得由内核关闭
验证
要验证网络共享分流的实现,请使用手动或自动测试验证网络共享和 WLAN 热点是否按预期方式工作。供应商测试套件 (VTS) 包含针对网络共享分流 HAL 的测试。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[null,null,["最后更新时间 (UTC):2025-03-26。"],[],[],null,["# Tethering hardware offload\n\nTethering offload enables devices to save power and improve performance by\noffloading the tethering traffic (over USB, Wi-Fi) to the hardware. The\ntethering traffic is offloaded by providing a direct path between the modem and\nthe peripherals, bypassing the app processor.\n\nSpecifications\n--------------\n\nStarting in Android 8.1, devices can use tethering offload to\noffload IPv4, IPv6, or IPv4+IPv6 forwarding to the hardware.\n\nThe offload feature doesn't need to offload all packets. The framework is\ncapable of handling any packet in software. Control packets are typically\nprocessed in software. Because IPv4 ports are shared between tethered traffic\nand device traffic, IPv4 session setup/teardown packets (for\nexample, SYN/SYN+ACK, FIN) must be processed in software so the kernel can\nconstruct the flow state. The framework provides the control plane and state\nmachines. It also provides the hardware with information on upstream and\ndownstream interfaces/prefixes.\n\nFor IPv4, the hardware allows IPv4 network address translation (NAT) session\nsetup packets to reach the CPU. The kernel creates NAT entries, and the HAL\nimplementation observes the entries from the framework-provided file descriptors\nand handles these flows in hardware. This means the HAL implementation doesn't\nrequire `CAP_NET_*` because the HAL gets opened `NF_NETLINK_CONNTRACK` sockets\nfrom the framework. Periodically, the hardware sends NAT state updates for\ncurrently active flows to the framework, which refreshes the corresponding\nkernel connection tracking state entries.\n\nFor IPv6, the framework programs a list of IPv6 destination prefixes to which\ntraffic must not be offloaded. All other tethered packets can be offloaded.\n\nFor data usage accounting, `NetworkStatsService` data usage polls causes the\nframework to request traffic stats from hardware. The framework also\ncommunicates data usage limits to the hardware via the HAL.\n\nHardware requirements\n---------------------\n\nTo implement tethering offload, your hardware must be capable of forwarding IP\npackets between the modem and Wi-Fi/USB without sending the traffic through the\nmain processor.\n\nImplementation\n--------------\n\nTo enable the tethering offload feature, you must implement the two following\nboth a config HAL (`IOffloadConfig`) and a control HAL (`IOffloadControl`).\n\n### Config HAL: IOffloadConfig\n\nThe\n[`IOffloadConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/tetheroffload/config/1.0/IOffloadConfig.hal)\nHAL starts the tethering offload implementation. The framework provides the HAL\nimplementation with pre-connected `NF_NETLINK_CONNTRACK` sockets that the\nimplementation can use to observe the IPv4 flows. Only forwarded flows must be\naccelerated.\n\n### Control HAL: IOffloadControl\n\nThe\n[`IOffloadControl`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/tetheroffload/control/1.0/IOffloadControl.hal)\nHAL controls the offload implementation. The following methods must be\nimplemented:\n\n- Start/stop offload hardware: Use `initOffload/stopOffload` and exempt local IP addresses or other networks from offload with `setLocalPrefixes`.\n- Set upstream interface, IPv4 address, and IPv6 gateways: Use `setUpstreamParameters` and configure downstream IP address ranges with `addDownstream/removeDownstream`.\n- Data usage accounting: Use `getForwardedStats/setDataLimit`.\n\nYour vendor HAL must also send callbacks through the `ITetheringOffloadCallback`\ninterface, which informs the framework of:\n\n- Asynchronous events such as offload being started and stopped (OffloadCallbackEvent)\n- NAT timeout updates, which must be sent periodically to indicate that a specific IPv4 flow contains traffic and must not be closed by the kernel\n\nValidation\n----------\n\nTo validate your implementation of tethering offload, use manual or automated\ntesting to verify tethering and Wi-Fi hotspot work as expected. The\n[Vendor Test Suite (VTS)](/docs/core/tests/vts)\ncontains tests for the tethering offload HALs."]]