3、Android WiFi 系统架构：从应用层到驱动层的分层模型，各层职责与交互流程

Android WiFi 系统的软件栈是一个典型的纵向分层架构，从最上层的 Java 应用框架接口到最底层的内核驱动与固件，每一层都承担着明确的职责，并通过标准化的接口进行通信。理解这一分层模型是进行 HAL 开发、网络问题排查和性能调优的基础。本章将深入剖析各层的核心组件、职责边界以及一次完整 WiFi 连接流程中的数据交互路径。

上图清晰地展示了 Android WiFi 系统的五层结构。值得注意的是，HAL 层（Hardware Abstraction Layer） 是连接 Android 框架与硬件驱动的关键枢纽。在 Android 8.0 之后，HAL 从传统的 libhardware_legacy 迁移至 HIDL（HAL Interface Definition Language），并在 Android 13 上进一步向 AIDL（Android Interface Definition Language）过渡。这种变化不仅影响了接口定义方式，也改变了 Vendor 代码的编译和加载方式。下面我们将逐层深入分析。

3.1 应用框架层与 WiFi 服务层：策略与状态机的核心

核心原理：从用户意图到系统策略

应用框架层（Java Framework）是用户和系统交互的入口。WifiManager 是 App 最常接触的类，它通过 Binder IPC 调用系统进程中的 WifiService。WifiService 内部维护着一个复杂的 状态机（WifiStateMachine），该状态机负责处理扫描结果、连接状态、漫游决策、IP 地址获取（通过 IpClient）等核心逻辑。这一层不关心硬件具体如何实现，只关心“做什么”（策略），而“怎么做”（机制）则交由下层处理。

判断方法：如何区分框架层与 HAL 层问题

当遇到 WiFi 无法开启或扫描不到网络时，首先需要判断问题发生在哪一层。一个实用的方法是查看 logcat 中 WifiStateMachine 和 WifiVendorHal 的日志。如果状态机日志显示正在等待 HAL 响应但超时，则问题大概率在 HAL 或驱动层；如果状态机根本没有启动扫描流程，则问题可能在框架层的策略配置（如省电模式、飞行模式状态）。

案例拆解：扫描请求的发起与分发

假设用户点击了“重新扫描”按钮。流程如下：

1. WifiManager.startScan() 被调用，通过 Binder 传递到 WifiService。
2. WifiService 检查权限（需要 CHANGE_WIFI_STATE 权限），然后向 WifiStateMachine 发送 CMD_START_SCAN 消息。
3. 状态机根据当前的扫描策略（如是否允许后台扫描、扫描频段）决定是否执行，并调用 WifiNative.scan()。
4. WifiNative 通过 JNI 调用到 C++ 层的 WifiVendorHal。

这一过程中，任何一步的权限拒绝或状态机状态不正确都会导致扫描失败。例如，如果 WifiStateMachine 处于 DISCONNECTED 但 Supplicant 尚未准备好，扫描请求会被延迟。

常见误区：混淆“框架层”与“系统应用”

很多开发者将 Settings 应用（系统设置）视为框架层。实际上，Settings 只是一个拥有系统权限的普通应用，它同样通过 WifiManager 与框架层交互。框架层是指 system_server 进程中的 WifiService 及相关类。区分这一点有助于理解：即使 Settings 应用崩溃，框架层的 WifiService 依然存在，WiFi 连接可能仍然保持。

3.2 HAL 层：硬件抽象与 Vendor 适配

核心原理：HIDL/AIDL 接口与 Vendor 实现

HAL 层是 Android 系统与 Vendor 代码的分界线。Google 定义了 android.hardware.wifi 包，其中包含 IWifi、IWifiStaIface（Station 模式）、IWifiApIface（SoftAP 模式）等接口。Vendor 必须实现这些接口，并将其编译为独立的共享库（如 wifi.default.so）。系统服务通过 hwservicemanager 获取这些 HAL 服务实例。这种设计使得系统框架可以不依赖具体的芯片方案（如 Qualcomm、MTK、Realtek）。

操作流程：HAL 层的初始化与能力协商

在系统启动时，WifiService 会调用 IWifi.getWifiHalDeviceCapabilities() 来查询硬件能力（如支持的频段、信道数、最大连接数）。随后，通过 IWifi.start() 启动 HAL 服务。一个典型的启动序列如下：

// 伪代码示意
WifiVendorHal.initialize();
// 1. 获取 IWifi 服务
sp<IWifi> wifi = IWifi::getService();
// 2. 查询能力
WifiHalCapabilities caps = wifi->getCapabilities();
// 3. 启动 HAL
wifi->start();
// 4. 创建 Sta 接口
sp<IWifiStaIface> sta_iface = wifi->createStaIface();
// 5. 设置事件回调
sta_iface->registerEventCallback(callback);

实战场景：HAL 层事件回调机制

HAL 层不仅接收来自上层的命令，还需要主动上报异步事件。例如，当驱动检测到断线时，HAL 通过 WifiStaIfaceEventCallback 的 onDisconnection() 方法通知框架层。这个回调是跨进程的（HAL 进程 → system_server 进程）。如果回调实现有误或进程间通信（IPC）超时，会导致框架层无法及时更新 UI 状态。

3.3 内核驱动层与固件：数据通路与硬件控制

核心原理：cfg80211 与 wlan.ko 的分工

内核驱动层是操作系统与硬件之间的桥梁。Android WiFi 通常使用 cfg80211 作为内核无线配置 API，它向上对用户空间提供 nl80211 接口，向下调用 Vendor 提供的 wlan.ko 驱动模块。wlan.ko 负责具体的硬件操作，如通过 SDIO/PCIe 总线读写固件寄存器、处理中断、管理 DMA 缓冲区等。固件（Firmware）则运行在 WiFi SoC 内部，负责实时性要求极高的任务，如 802.11 帧的封装与解析、速率自适应、信道状态评估（CCA）等。

判断方法：通过内核日志定位驱动问题

当 HAL 层工作正常但无法建立连接时，需要查看内核日志（dmesg 或 adb shell cat /proc/kmsg）。常见的关键字包括：

• cfg80211: Calling CRDA to update world regulatory domain —— 表示正在更新监管域。
• wlan: [E] ... —— Vendor 驱动的错误日志。
• firmware: failed to load —— 固件加载失败，通常与 WLAN_FW_PATH 配置错误有关。

案例拆解：一次连接失败的内核层排查

假设设备能扫描到 AP，但连接时一直提示“身份验证错误”。通过 dmesg 发现如下日志：

[ 1234.5678] wlan: [E :HDD] wlan_hdd_cfg80211_connect: Connection failed, reason = 0x1
[ 1234.5679] wlan: [E :SME] SME connection failed, status = 0x3

分析：reason = 0x1 通常表示 802.11 认证失败（Authentication）。但上层配置的密码是正确的。进一步检查发现，驱动在连接前未正确设置 WEP 密钥（尽管使用的是 WPA2）。原因是 HAL 层在调用 nl80211_connect 时，未将 NL80211_ATTR_KEY 正确传递。最终定位为 HAL 层的一个 key_mgmt 参数解析 bug，而非驱动问题。

常见误区：忽略固件版本与驱动版本的匹配

很多“疑难杂症”源于固件与驱动版本不匹配。例如，驱动代码已更新支持 802.11ax，但固件仍是旧版本，导致协商失败。Android 的 vendor 分区中通常包含多个固件文件（如 wlan/prima/WCNSS_qcom_cfg.ini），系统根据硬件 ID 选择加载。在集成新驱动时，务必同步更新固件并验证其哈希值。

3.4 分层交互流程：一次完整的连接建立过程

核心原理：控制面与数据面的分离

一次完整的 WiFi 连接涉及控制面（Control Plane）和数据面（Data Plane）。控制面负责管理连接状态，数据面负责传输 IP 数据包。在 Android 中，控制面从 App 到固件逐层下发命令；数据面则从网络协议栈直接通过内核驱动发送到固件，不再经过 HAL 层。理解这一点对性能调优至关重要——数据路径上的瓶颈（如 TCP 吞吐量低）不应在 HAL 层寻找原因。

操作流程：连接建立的时序图

1. 扫描阶段：App 发起扫描 → WifiService 下发扫描命令 → HAL 调用 nl80211_trigger_scan → 驱动配置硬件扫描参数 → 固件执行扫描并上报结果。
2. 选择网络：WifiService 根据扫描结果和用户配置选择目标 AP，并生成连接配置（WifiConfiguration）。
3. 认证与关联：HAL 下发 nl80211_connect → 驱动与固件执行 802.11 认证（Authentication）和关联（Association）流程。
4. IP 配置：关联成功后，框架层的 IpClient 启动 DHCP 或静态 IP 配置。此时数据面已可用。
5. 网络验证：框架层通过 NetworkMonitor 检测网络连通性（如访问 connectivitycheck.gstatic.com），成功后广播 NETWORK_CAPABILITY_VALIDATED。

实战场景：漫游时的分层协作

当设备从一个 AP 漫游到另一个 AP（同一 SSID）时，HAL 层会收到 roam() 命令。驱动会执行快速切换，但框架层需要同步更新 BSSID 和网络状态。如果漫游失败，驱动会触发 onRoamingFailure 回调，框架层随后决定是否重新扫描或保持原连接。这一过程涉及所有层的紧密配合，任何一层的延迟都可能导致漫游超时。

总结复盘：分层架构的调试意义

掌握分层模型后，调试思路应遵循“先上层后下层，先控制面后数据面”的原则。首先通过 dumpsys wifi 确认框架层状态，然后通过 logcat 查看 HAL 日志，最后用 dmesg 检查内核。避免一开始就陷入驱动代码的细节。同时，要善用 adb shell cmd wifi 命令（如 cmd wifi force-country-code）来辅助测试，这比反复修改 App 代码更高效。