你打开 WiFi 列表，下拉刷新——startScan() 几乎立即被调用，数十个 Java 函数和 C++ 函数被依次执行，最终一条 NL80211_CMD_TRIGGER_SCAN 命令被发往内核。这不是一个简单的「扫一下」——这是一次四层精心编排的协作：Framework 的 WifiScanningServiceImpl 是战术指挥中心，接收各方扫描请求、合并同类项、排队分派；ScanRequestProxy 是节流阀，防止操作员无限制地按发射按钮烧坏设备；wificond 是翻译官，把指挥中心的 Java 指令翻译成天线能执行的 nl80211 属性；内核 cfg80211 是天线控制器，验证频率可用性后把真正的 Probe Request 发射任务交给驱动和固件。

在 Supplicant 启动篇 中，我们讲完了 wpa_supplicant 的 eloop 事件循环、AIDL 接口层、核心数据结构。本篇跳到另一个主线——WiFi 打开后，系统怎么执行一次扫描？我们聚焦扫描怎么被触发、参数怎么构建、怎么从 Java 世界一路下发到内核。Supplicant 内部的扫描引擎（radio work、BSS 缓存、PNO）留给中篇，驱动执行和 WiFi 6E/7 留给下篇。

驱动加载完成、芯片就绪后，wpa_supplicant 是怎么启动的？eloop 事件循环是怎么工作的？它的核心数据结构、状态机、AIDL 接口层又是怎么设计的？

上篇回顾：在 Framework 与 HAL 篇中，我们追踪了从用户点击开关到 HAL 就绪的完整链路——ActiveModeWarden 调度、WifiController 状态机、HalDeviceManager 启动、厂商私有 HAL 加载。本篇继续往下走：HAL 就绪后，Supplicant 怎么启动？

本章导读

Supplicant 是餐厅的前台接待——就位后通过对讲机（eloop 事件循环）随时响应厨房（内核）和客人（Java Framework）的消息。接待台上的工作手册记录了所有接口、网络、密钥的状态。

从 insmod 到芯片就绪，中间经历了什么？QCOM 和 MTK 两条主流平台路径各自怎么解决同一个问题？

本章导读

驱动加载就像一家餐厅的「开张准备」—— insmod 是拿到营业执照（内核注册），PCIe 枚举是接通水电煤气（硬件通道），固件下载是把菜谱装进厨房设备（把代码灌进芯片 MCU），WMI 握手是厨师长和服务员对一遍菜单确认能做什么菜（能力协商）。

你点了一下 "WiFi" 开关，屏幕上的图标转了两圈，WiFi 列表就出现了。这半秒钟里，Android 系统做了多少事？从 Java 框架的权限检查，到状态机的层层调度，到 HAL 进程的拉取、再到内核 netlink 通道的建立——本文从点击开关开始，一路追踪到 HAL 就绪那一刻，把整条链路的代码打开来看。

本章导读

WiFi 打开的过程，就像给一栋大楼供电。 你按下墙上的开关（WifiManager），电流不会直接到电器——它要先经过配电箱的断路器检查线路是否安全（WifiServiceImpl 权限校验），再由总调度室决定启用哪条供电线路（ActiveModeWarden + WifiController 状态机），然后逐级合上楼层配电柜的闸（ConcreteClientModeManager → ClientModeImpl），最后接通大楼与电网之间的变压器（HAL → nl80211 → kernel）。每一层都有自己的 "保险丝" 和 "合闸顺序"，跳过一个环节整栋楼都不会有电。

当你点击手机上的 WiFi 热点名称，一个连接请求从 Java 层的 WifiManager.connect() 出发（注：connect () 已从公开 API 移除、现为 @SystemApi @hide，本文用其展示调用链完整性），经过 Framework 状态机、AIDL HAL、C 守护进程、Netlink 内核接口，最终变成一帧 802.11 Auth 空中帧。

这条路径跨越百万行级代码、5 层架构、2 大芯片平台。本文为你画出这张全景地图——告诉你每一层 "是什么"、"为什么这么设计"、以及该按什么顺序读代码。

本章导读

如果把 WiFi 系统比作一家大型医院——App 是患者（提出需求），Framework 是门诊部（分诊、调度），Supplicant 是主治医师（做出诊断和治疗决策），HAL 是医疗器械标准（不管哪个品牌的 CT 机，接口都一样），Driver 是具体的医疗设备（高通的 CT 机和联发科的 CT 机内部构造不同，但都遵循 HAL 标准），Firmware 是设备内部的嵌入式控制系统（你看不到源码，但设备靠它运转）。患者不需要知道 CT 机是哪个品牌的——这正是分层架构的意义。

"光速是已知的。所以只要量准时间，时间就能变成距离——Wi-Fi 也能当尺子用。"

本章导读

前三章讲的都是 "怎么把数据传过去"。这一章讲一件听起来不太像 Wi-Fi 本职的事：用 Wi-Fi 测距离。

你打开手机地图，在商场里它能给你定位到 "你在 3 楼 A 区星巴克门口"——GPS 在室内基本失灵，靠的就是 Wi-Fi 测距。原理朴素得惊人：两台设备互相发一帧、各自掐表记录收发时刻，算出信号往返用了多少时间（RTT，Round-Trip Time），再乘以光速、除以二，就得到距离。

"不需要联网，不需要 GPS。只要彼此靠得够近，设备就能自己'感知'到对方提供了什么。"

本章导读

前两章的 Wi-Fi Direct 和 Miracast，本质上还是 "先建立一对一连接，再传数据"。但有一类需求不一样：你想知道"我周围有谁、在提供什么服务"——附近哪台打印机能用、附近哪个人在玩同一款游戏、附近哪家店在推送优惠——而且这一切不依赖 AP、不依赖蜂窝网、不依赖云端。

这就是 Wi-Fi Aware 要解决的问题。它的技术规范叫 NAN（Neighbor Awareness Networking，邻居感知网络）。核心理念是：让一群互不相识的设备，自发地 "同步" 出一个共同的时间窗口，在这个窗口里互相广播和搜索服务——发现彼此后，再按需建立直接的数据通道。

"你不需要一根 HDMI 线。你需要的，是让两块屏幕'说同一种语言'。"

本章导读

手机上的视频，想丢到客厅大电视上看；笔记本的 PPT，想甩到会议室投影仪上放。最朴素的办法是插一根 HDMI 线——但线总是不够长、接口总是不匹配。Miracast 干的就是 "把 HDMI 线变成无线" 这件事。

Miracast 是 Wi-Fi 联盟的认证品牌，对应的技术规范叫 WFD（Wi-Fi Display）。它的定位非常清晰：在两台设备之间建立一条 "无线 HDMI"，把音视频从一台设备（Source，发送端）实时串流到另一台（Sink，显示端）。

"我们明明是同一家公司的同事，发份文件却要先送到前台、再由前台转给你。既然工位就在隔壁，何不拉条桌对桌的内线？"

本章导读

上一章的 Wi-Fi Direct，讲的是 "没有 AP 的直连 "——两台陌生设备临时组队，其中一台扮演 AP。但还有一类很常见的场景：两台设备本来就连在同一个 AP 上（比如同一间办公室、同一个家庭 Wi-Fi 里的笔记本和无线投影、手机和智能电视）。

这时它俩要互传数据，按传统 BSS 的规矩得经 AP 中转两跳：设备 A →（上行）AP →（下行）设备 B。哪怕 A、B 近在咫尺、AP 在另一个房间，数据也得先绕一圈。这显然浪费——既占了 AP 的空口时间，又凭空多了一跳延迟。

"不需要旅行社，两个陌生人也能在路上结伴同行——临时推举一个领队，说走就走。"

本章导读

在传统 Wi-Fi 里，所有设备都要先连上一个 AP（路由器），才能互相通信——就像所有人都必须先到火车站、由车站统一调度才能出发。但很多场景并不需要这个 "车站"：手机直接传文件给另一台手机、笔记本直接连打印机、相机直接投屏到电视。

Wi-Fi Direct（Wi-Fi 联盟的认证品牌名，底层技术规范叫 Wi-Fi Peer-to-Peer，简称 P2P）就是为这种 "设备直连" 设计的。它最巧妙的地方在于：不需要真正的 AP，而是让其中一台设备临时 "扮演" AP——这台设备叫 P2P Group Owner（GO，组拥有者），其他设备作为 P2P Client（客户端）连上它。