2、WiFi 基础概念：802.11 协议族、频段、信道、SSID/BSSID、安全认证方式（WPA2/WPA3）等核心术语

在深入 Android WiFi HAL 与网络连接机制之前，必须先建立一套统一的术语体系。802.11 协议族定义了物理层与 MAC 层的空中接口规范，频段与信道决定了射频资源的划分方式，SSID/BSSID 是网络身份标识的两种粒度，而安全认证方式则直接关系到连接流程中密钥协商与加密数据的处理逻辑。Android 的 WiFi 框架（从 wpa_supplicant 到 WifiNative，再到 HAL 层）本质上就是围绕这些概念进行状态管理与命令交互。本章将逐一拆解这些核心术语，并说明它们如何映射到 Android 系统源码与 HAL 接口中。

2.1 802.11 协议族：从 802.11n 到 802.11be

核心原理

802.11 是 IEEE 制定的无线局域网标准族。每一代协议主要在物理层（PHY）和 MAC 层引入新技术，以提升吞吐量、降低时延或增强可靠性。Android 系统在启动时通过 HAL 查询芯片能力，其中就包括对 802.11 协议版本的支持情况。例如，IWifiChip::getSupportedIeee80211Modes() 返回的 Ieee80211Mode 枚举中，IEEE80211_MODE_11AX 对应 WiFi 6，IEEE80211_MODE_11BE 对应 WiFi 7。理解协议族有助于判断设备的最大理论速率、支持的调制方式（如 OFDMA、MU-MIMO）以及功耗特性。

判断方法

在 Android 开发中，可以通过 WifiInfo::getWifiStandard() 获取当前连接使用的协议标准。该 API 返回 SCAN_RESULT_WIFI_STANDARD_11AX 等常量。在 HAL 层，驱动通过 wifi_chip_info_t 结构体中的 ieee80211_modes 字段上报能力。若需要确认某个 AP 是否支持 WiFi 6，可以查看扫描结果中的 IE（Information Element）字段，其中包含 HE Capabilities（802.11ax）或 EHT Capabilities（802.11be）。

案例拆解：WiFi 6 协商失败问题

某款手机连接 WiFi 6 路由器时，状态栏显示“已连接”但速率仅为 300 Mbps（预期 1200 Mbps）。通过抓取 wpa_supplicant 日志发现，驱动上报的 HE Capabilities 中 HE MAC Capabilities 字段的 HE SM Power Save 位被错误置位，导致 AP 认为 STA 不支持 OFDMA 接收。最终通过更新驱动固件修复。此案例说明，协议族支持不仅取决于芯片硬件，还依赖驱动对能力集的正确上报。

常见误区

• 误以为“支持 WiFi 6”就等于“支持 6 GHz 频段”。实际上 WiFi 6E 才新增 6 GHz，WiFi 6 仍只在 2.4/5 GHz 工作。
• 忽略协议协商的回退机制。即使双方都支持 802.11ax，如果信道干扰严重，也可能回退到 802.11ac 甚至 802.11n。

2.2 频段与信道：射频资源的地图

核心原理

WiFi 使用的 ISM 频段包括 2.4 GHz（2400-2483.5 MHz）、5 GHz（5150-5850 MHz）以及 6 GHz（5925-7125 MHz，WiFi 6E/7）。每个频段被划分为多个信道，信道号对应中心频率。2.4 GHz 频段仅有 3 个非重叠信道（1、6、11），而 5 GHz 频段拥有更多非重叠信道，且支持更宽的信道绑定（如 80 MHz、160 MHz）。Android HAL 通过 IWifiChip::getSupportedBands() 和 getSupportedChannels() 向框架层报告可用频段与信道列表。信道选择直接影响扫描效率与连接稳定性。

判断方法

在 Android 中，WifiScanner 的 ScanResult 包含 frequency 字段，单位为 MHz。通过频率可以反推信道号：2.4 GHz 频段信道 1 中心频率为 2412 MHz，信道 6 为 2437 MHz，信道 11 为 2462 MHz；5 GHz 频段信道 36 中心频率为 5180 MHz，信道 149 为 5745 MHz。HAL 层驱动在扫描时会填充每个 BSS 的 channel 信息，框架层据此进行频段偏好排序。

案例拆解：5 GHz 信道扫描不完整

某设备在 5 GHz 频段扫描时，始终无法发现信道 149 以上的 AP。通过 adb shell dumpsys wifi 查看扫描结果，发现所有 BSS 的信道均集中在 36-64 之间。进一步检查 HAL 日志，发现驱动上报的 supported_channels 列表被截断，原因是固件配置中 regulatory domain 被设置为 US，但实际天线设计不支持 5.8 GHz 频段。修改驱动中的 country code 为 CN 后，信道 149-165 恢复正常扫描。此案例表明，频段支持不仅由芯片决定，还受制于法规域（Regulatory Domain）和天线硬件。

常见误区

• 认为 5 GHz 信道越多越好。实际上，DFS（Dynamic Frequency Selection）信道（如 52-64、100-140）需要雷达检测，若检测到雷达信号，AP 会在 30 秒内切换信道，导致连接中断。
• 忽略 2.4 GHz 频段的同频干扰。在密集环境中，即使使用信道 1、6、11，相邻 AP 的邻道干扰仍可能影响吞吐量。

2.3 SSID 与 BSSID：网络身份的双重标识

核心原理

SSID（Service Set Identifier）是用户可见的网络名称，最多 32 字节，用于区分不同的无线网络。BSSID（Basic Service Set Identifier）是 AP 的 MAC 地址，用于唯一标识一个 BSS（基本服务集）。一个 SSID 可以对应多个 BSSID（例如多 AP 组网），而一个 BSSID 只能属于一个 SSID。在 Android HAL 中，IWifiApIface::setSsid() 用于配置 SoftAP 的 SSID，getBssid() 用于获取当前 AP 的 MAC 地址。框架层通过 ScanResult.SSID 和 ScanResult.BSSID 区分网络。

判断方法

当用户选择一个 SSID 进行连接时，Android 会优先选择信号最强的 BSSID。如果开启了“自动加入”功能，系统会保存该 SSID 下的所有 BSSID 信息。在 HAL 层，wifi_scan_result 结构体包含 ssid、bssid、rssi 和 frequency 字段。框架层通过 WifiNetworkSpecifier 可以指定 SSID 或 BSSID 进行精确连接。

案例拆解：多 BSSID 环境下的漫游问题

某企业部署了多个 AP 使用相同 SSID，但 Android 设备在移动时无法自动切换到信号更优的 BSSID。通过分析 wpa_supplicant 日志，发现 roam_consortium_selection 参数未启用，且驱动未上报 BSS Transition Management 能力。解决方案是启用 802.11k/v 协议支持，并在 HAL 层实现 setBssidBlacklist 和 setBssidWhitelist 接口。此案例说明，SSID/BSSID 的管理不仅涉及标识，还涉及漫游决策逻辑。

常见误区

• 混淆 SSID 与 BSSID 的用途。SSID 用于用户识别，BSSID 用于网络管理。在开发调试时，应使用 BSSID 而非 SSID 来定位特定 AP。
• 忽略 BSSID 的随机化。Android 10 及以上版本默认启用 MAC 随机化，扫描时上报的 BSSID 可能与实际 MAC 不同，影响基于 MAC 的认证系统。

2.4 安全认证方式：WPA2 与 WPA3 的演进

核心原理

安全认证决定了连接过程中的身份验证与数据加密方式。WPA2-Personal（PSK）使用预共享密钥（Pre-Shared Key）进行认证，加密协议为 CCMP（AES）。WPA3-Personal 引入 SAE（Simultaneous Authentication of Equals）握手，替代了 WPA2 的 4 次握手，能够抵御离线字典攻击。在 Android HAL 中，wifi_ap_config 结构体的 auth_type 字段定义了认证类型，WPA3_SAE 对应 8。框架层通过 WifiConfiguration.allowedKeyManagement 设置密钥管理协议。

判断方法

在 Android 中，可以通过 ScanResult.capabilities 字段判断 AP 支持的安全类型。例如，[WPA2-PSK-CCMP] 表示支持 WPA2-Personal，[RSN-SAE-CCMP] 表示支持 WPA3-SAE。在 HAL 层，驱动通过 wifi_security_type_t 枚举上报安全能力。当设备连接 WPA3 网络时，wpa_supplicant 会执行 SAE 握手，该过程在 wpa_supplicant 的 SAE 模块中完成，HAL 层负责传递 EAPOL 帧。

案例拆解：WPA3 连接时 PMF 协商失败

某 Android 设备连接 WPA3 网络时，提示“网络连接失败”。抓取日志发现 wpa_supplicant 报错：PMF required but not supported by AP。原因是 AP 配置了 WPA3 但未启用 PMF（Protected Management Frames）。Android 11 及以上版本默认要求 WPA3 必须启用 PMF。解决方案是修改 AP 配置，开启 PMF 支持。此案例说明，WPA3 不仅改变握手方式，还强制要求管理帧保护，HAL 层需要正确传递 PMF 能力标志。

常见误区

• 认为 WPA3 一定比 WPA2 安全。如果 AP 配置了 WPA3 但使用弱密码（如 8 位纯数字），SAE 握手仍可能被在线猜测攻击。
• 忽略 WPA2/WPA3 混合模式。许多 AP 默认开启混合模式，此时 Android 可能优先选择 WPA2 以兼容旧设备，导致实际未使用 WPA3。
• 在 HAL 层开发中，未正确处理 WPA3_SAE 的 sae_pwe 参数。该参数控制 SAE 的密码元素生成方式，若 AP 与 STA 配置不一致，会导致握手失败。