自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
網路共用硬體卸載
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
裝置可透過硬體卸載共用網路流量 (透過 USB、Wi-Fi),進而節省電力並提升效能。透過在數據機和周邊裝置之間提供直接路徑,可略過應用程式處理器,藉此卸載 Tethering 流量。
規格
自 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:設定 HAL (IOffloadConfig
) 和控制 HAL (IOffloadControl
)。
設定 HAL:IOffloadConfig
IOffloadConfig
HAL 會啟動 Tethering Offload 實作。此架構會為 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 流量包含流量,且不得由核心關閉
驗證
如要驗證網際網路共用功能的實作方式,請使用手動或自動化測試,確認網際網路共用和 Wi-Fi 無線基地台運作正常。供應商測試套件 (VTS) 包含用於測試 Tethering Offload HAL 的測試。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],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."]]