【转载】Android WLAN (好文)
转载： https://blog.csdn.net/h784707460/article/details/87873830
目录
一、 概览
应用框架
WLAN 服务
WLAN HAL
二、 WLAN HAL
供应商 HAL
客户端 HAL
Hostapd HAL
WLAN 多接口并发
三、 Wi-Fi Infrastructure Feature
打开网络通知
自动开启 WLAN
自动连接到开放网络
外部网络评分服务提供方
WLAN 网络标记
四、 STA/AP并发
示例和来源
实现
验证
五、 随机分配MAC地址
实现
验证
六、 Passpoint R1
下载机制
文件组成
示例配置文件 OMA-DM XML
身份验证建议
失败原因
解决方法
七、 运营商WLAN
实现
制造商
运营商
自定义
八、 WLAN感知
示例和来源
实现
随机分配 MAC 地址
验证
单元测试
集成测试 (ACTS)
兼容性测试套件 (CTS)
CTS 验证程序测试
九、 WLAN往返时间（RTT）
WLAN RTT (IEEE 802.11mc)
示例和来源
实现
随机分配 MAC 地址
验证
单元测试
集成 (ACTS) 测试
CTS
校准
十、 测试、调试和调整WLAN
测试
单元测试
Android 通讯测试套件
CTS 测试
针对调试的增强型日志记录选项
实现
集成测试 (ACTS)
手动测试
配置调整
Based and From Google：https://source.android.com/devices/tech/connect/wifi-overview
一、 概览
Android 提供默认 Android 框架实现，其中包括对各种 WLAN 协议和模式的支持，这些协议和模式包括：
- WLAN 基础架构 (STA)
- 网络共享模式或仅限本地模式下的 WLAN 热点 (Soft AP)
- WLAN 直连（点对点/P2P）
- WLAN 感知 (NAN)
- WLAN RTT (IEEE 802.11mc FTM)
使用 WLAN 服务的应用通过 Binder 直接与各种 WLAN 服务进行通信。WLAN 服务在系统服务中运行，并通过 HIDL 与 HAL 进行通信。下图显示了 Android WLAN 堆栈的常规结构。
图 1.1 Android WLAN 架构
代码路径：
Apps/wifiSettings：packages/apps/Settings/src/com/android/settings/wifi/
android.net.wifi/wifimanager etc: frameworks/base/wifi/java/android/net/wifi/
com.android.server.wifi/WifiService: frameworks/opt/net/wifi/
wificond: system/connectivity/wificond/
Vendor HAL: hardware/interfaces/wifi/1.X/
Supplicant HAL: hardware/interfaces/wifi/supplicant/
Hostapd HAL: hardware/interfaces/wifi/hostapd/
VENDOR IMPLEMENTATION & DRIVER:
vendor/qcom/opensource/wlan/
kernel/net/wireless/
应用框架
应用代码位于应用框架级别，它使用各种 android.net.wifi API 与 WLAN 框架和硬件进行交互。此代码在内部通过 Binder IPC 机制调用 WLAN 进程。
WLAN 服务
WLAN 服务在系统服务中运行，这类服务位于 frameworks/opt/net/wifi 中。WLAN 服务通过 HIDL 与 WLAN HAL 进行通信。
WLAN 服务有很多种：
- WLAN 服务：用于控制 WLAN 基础架构模式（包括 STA 和 AP）的主要机制。
- WLAN 点对点服务：管理 WLAN 直连模式。
- WLAN 感知服务：管理 WLAN 感知模式。
- WLAN RTT 服务：管理 IEEE 802.11mc FTM 功能。
此外，WLAN 框架还包括一个独立的进程 wificond，此进程位于 system/connectivity/wificond 中。wificond 进程通过标准 nl80211 命令与 WLAN 驱动程序进行通信。
WLAN HAL
WLAN 框架具有三个 WLAN HAL 表面，分别由三个不同的 HIDL 软件包表示：供应商 HAL、客户端 HAL 和 Hostapd HAL。
要详细了解各种 HAL 的实现，请参阅 WLAN HAL。
二、 WLAN HAL
WLAN 框架具有三个 WLAN HAL 表面，分别由三个不同的 HIDL 软件包表示：
- 供应商 HAL：Android 专用命令的 HAL 表面。HIDL 文件位于
hardware/interfaces/wifi/1.x中。 - 客户端 HAL：wpa_supplicant 的 HAL 表面。HIDL 文件位于
hardware/interfaces/supplicant/1.x中。 - Hostapd HAL：hostapd 的 HAL 表面。HIDL 文件位于
hardware/interfaces/hostapd/1.x中。
供应商 HAL
供应商 HAL 提供 Android 专用命令。供应商 HAL 对于基础架构 Station (STA) 和 Soft AP (SAP) 模式的正常运行而言是可选的（不是必需的）。不过，对于 WLAN感知 和 WLAN RTT 服务而言，供应商 HAL 是必要 HAL。
在 HIDL 之前（即 Android 8.0 版本之前），Android 使用的是现在称为“旧版 HAL”的 HAL 机制。Android 源代码目前使用在旧版 HAL 之上运行的 shim 来提供 HIDL 默认实现。
旧版 HAL 标头位于 hardware/libhardware_legacy/include/hardware_legacy/ 中。基于旧版 HAL 的实现位于 hardware/interfaces/wifi/1.2/default 中。
客户端 HAL
客户端 HAL 为 wpa_supplicant 守护进程提供 HIDL 接口。
wpa_supplicant 源代码位于 external/wpa_supplicant_8/wpa_supplicant 中。提供 HIDL 接口的 wpa_supplicant 代码位于 hidl 子目录中。
Hostapd HAL
Hostapd HAL 为 hostapd 守护进程提供 HIDL 接口。
hostapd 源代码位于 external/wpa_supplicant_8/hostapd 中。提供 HIDL 接口的 hostapd 代码位于 hidl 子目录中。
WLAN 多接口并发
不同的 Android 设备可以并行支持不同的 WLAN 接口组合。受支持的组合在 HAL 中定义，并提供给框架。规范格式在 android/hardware/interfaces/wifi/1.0/IWifiChip.hal 中定义。例如，一台设备可以支持一个 STA 和一个 NAN（WLAN 感知）类型或点对点（WLAN 直连）类型的接口（但不能同时支持这两种接口）。这可以表示为：
[{STA} <= 1, {NAN,P2P} <= 1]
并发规范格式非常灵活，且是通用格式。它可以表示框架尚不支持的组合。参考 HAL 具有适合多种组合的配置，这些配置可通过编译标记进行启用。有关配置说明，请参阅：
- WLAN STA/AP 并发
- WLAN 感知
三、 Wi-Fi Infrastructure Feature
WLAN 基础架构功能
Android WLAN 框架可帮助用户连接到优质 WLAN 网络（在有可用 WLAN 网络且需要连接到这类网络的情况下）。Android 可通过多种方式来实现这一点：
- 打开网络通知：在有可用的优质开放 WLAN 网络时通知用户
- 自动开启 WLAN：当用户靠近之前保存的某个网络时，重新启用 WLAN
- 连接到开放网络：自动将用户连接到优质开放 WLAN 网络
- 标记：显示与可用网络的质量相关的信息
上述功能均通过 AOSP 代码实现，您无需明确启用或配置这些功能。
打开网络通知
只要出现以下情况，“打开网络通知”功能便会向用户发出通知：
- WLAN 已启用
- 设备未连接到 WLAN 网络
- 有开放且 RSSI 足够高（与内部 WLAN 选择算法使用的 RSSI 阈值相同）的 WLAN 网络时
用户可在设置应用中通过以下路径启用或停用该功能：
设置 > 网络和互联网 > WLAN > WLAN 偏好设置 > 打开网络通知
图 3.1 打开网络通知功能
自动开启 WLAN
用户可能会出于各种原因（例如，连接到不稳定的网络时）停用 WLAN，但在回家后可能忘记重新启用 WLAN，从而导致体验不佳（例如，无法控制家居自动化设备）。“自动开启 WLAN”功能解决了这一问题：只要设备靠近已保存（即用户过去明确连接过）且 RSSI 足够高的 WLAN 网络，便会自动重新启用 WLAN。
用户可在设置应用中通过以下路径启用或停用该功能：
设置 > 网络和互联网 > WLAN > WLAN 偏好设置 > 自动开启 WLAN
图 3.2 “自动开启 WLAN”功能
必须启用“WLAN 扫描”（针对位置信息）才能使该功能正常运行。如果未启用“WLAN 扫描”功能，则系统会提示用户允许启用此功能。之所以需要启用“WLAN 扫描”功能，是因为系统要根据扫描结果来判断设备是否位于符合重新启用 WLAN 连接条件的 WLAN 网络附近。
该功能可避免在用户停用 WLAN 后立即重新启用，即使设备检测到品质过硬的已保存 WLAN 网络也是如此。例如，如果用户在办公室并已连接到办公室的 WLAN（已保存的网络），然后停用 WLAN，则该功能将不会重新启用 WLAN，直到用户位于具有其他已保存网络（符合重新启用条件）的其他环境为止。
自动连接到开放网络
“连接到开放网络”功能在 Android 8.0 及更高版本中提供，可自动将设备连接到可用的优质网络。相关条件如下：
- WLAN 已启用
- 设备未连接到 WLAN 网络
- 有开放且优质（根据外部网络评分服务提供方的报告判断）的 WLAN 网络（请参见下一节）。
用户可在设置应用中通过以下路径启用或停用该功能：
设置 > 网络和互联网 > WLAN > WLAN 偏好设置 > 连接到开放网络
图 3.3 “连接到开放网络”功能和“网络评分服务提供方”菜单
如果未选择外部网络评分服务提供方，“连接到开放网络”功能便会停用。用户可以使用“网络评分服务提供方”菜单选择任何可用的网络评分服务提供方。
外部网络评分服务提供方
为了帮助用户确定优质 WLAN 网络需要符合哪些因素条件，Android 支持可提供开放 WLAN 网络质量相关信息的外部网络评分服务提供方（也称为“网络评分器”）。例如，网络评分器可能会使用历史效果数据（如“此 AP 过去的效果非常好，值得立即一试”）来判断特定 WLAN 网络的质量是否良好。
用户可通过以下路径访问可用的网络评分服务提供方列表： 设置 > 网络和互联网 > WLAN > WLAN 偏好设置 > 高级 > 网络评分服务提供方菜单。用户可以从中选择一个服务方，也可以不选择。如果没有可用的服务方或没有进行选择，“连接到开放网络”功能便会停用。
您无需提供外部网络评分服务提供方。要创建提供方，请执行以下操作：
- 实现
NetworkScoreManager中记录的 API。 - 外部网络评分服务提供方必须是特权应用。
- 通过更新产品叠加层配置文件（位于
frameworks/base/core/res/res/values/config.xml中）中的config_defaultNetworkRecommendationProviderPackage键，将您的系统配置为使用自定义实现。
如果您不想包含默认的网络评分服务提供方功能，则可以选择不设置默认提供方属性，然后在 AOSP 中隐藏网络评分服务提供方屏幕。
WLAN 网络标记
WLAN 选择器还会根据网络评分服务提供方提供的信息，添加与可用 WLAN 网络的质量相关的信息，从而帮助用户手动选择 WLAN 网络。对于具有可用信息（由外部网络评分服务提供方提供）的网络，其名称下方会显示相应的速度信息。
图 3.4 包含网络质量相关信息的 WLAN 网络
由于该功能需要用到外部网络评分服务提供方，因此如果没有可用的提供方或未选择提供方，该功能便无法使用，而且不会显示速度/质量信息。
四、 STA/AP并发
WLAN STA/AP 并发
Android 9 引入了可让设备同时在 STA 和 AP 模式下运行的功能。对于支持双频并发 (DBS) 的设备，此功能让一些新功能得以实现，例如在用户想要启用热点 (softAP) 时不会中断 STA WLAN。
示例和来源
默认的 AOSP Android 框架代码支持 WLAN STA/AP 并发。WLAN HAL 中介绍的参考 HAL 实现也支持 WLAN STA/AP 并发。下文“实现”部分中介绍的 WIFI_HIDL_FEATURE_DUAL_INTERFACE 编译时标记会启用接口并发规范（指示 STA 和 AP 的并发支持）。
实现
要在设备上实现 WLAN STA/AP 并发，请执行以下操作：
-
开启编译时标记以在 HAL 中启用对这两个接口的支持。该标记位于
device/中。/ /BoardConfig-common.mk - WIFI_HIDL_FEATURE_DUAL_INTERFACE := true
-
显示两个网络接口：
- wlan0 和 wlan1
注意：为了避免出现性能问题，请仅在采用支持多个独立硬件 MAC（无线链路）的 WLAN 芯片的设备上使用此功能。
验证
要验证该功能是否按预期正常运行，请同时执行集成测试 (ACTS) 和手动测试。
ACTS 文件 WifiStaApConcurrencyTest.py（位于 tools/test/connectivity/acts/tests/google/wifi 中）包含一组可以启动不同 STA 和 AP 组合的测试。
要手动验证此功能，请从界面中单独开启和关闭 STA 和 AP 接口。
如果 AP 和 STA 位于同一子网上，则被测设备 (DUT) 上可能会出现路由问题。为避免冲突，请尝试将 AP 移动到其他子网。
如果 STA 和 AP 位于同一频段但却在不同的频道上，则一些 WLAN 芯片供应商会将无线置于分时共享模式。这种做法会导致性能急剧下降。为了解决此问题，芯片可以使用 Channel Switch Avoidance (CSA) 以便：
- 将 AP 移动到 STA 所在的频道
- 将 AP 移动到非 STA 所在的频段
五、 随机分配MAC地址
隐私：随机选择 MAC 地址
从 Android 8.0 开始，Android 设备在未连接到网络的情况下探测新网络时会使用随机 MAC 地址。
在 Android 9 中，您可以启用开发者选项（默认处于停用状态），使设备在连接到 WLAN 网络时使用随机选择的 MAC 地址。系统会对每个 SSID 使用随机选择的 MAC 地址。
随机选择 MAC 地址可防止监听器使用 MAC 地址来生成设备活动的历史记录，从而加强对用户隐私的保护。
此外，随机选择 MAC 地址也是 WLAN感知 和 WLAN RTT 操作的一部分。
实现
要在设备上实现随机选择 MAC 地址，请执行以下操作：
-
与 WLAN 芯片供应商合作实现
IWifiStaIface.setMacAddress()HAL 方法。- AOSP 参考实现会关闭接口、更改 MAC 地址并备份接口。这种参考实现行为可能不适用于某些芯片供应商。
-
在“设置”
config.xml中，将config_wifi_support_connected_mac_randomization设置为 true（该步骤可在设备自定义叠层中完成）。- 此标记用于控制参考“设置”实现的开发者选项中是否显示“连接时随机选择 MAC 网址”切换开关。如果设置为 true，则显示该切换开关；如果设置为 false，则不显示该切换开关。
-
使用验证中所述的方法测试实现。
系统界面必须：
- 在开发者菜单中有一项可启用或停用该功能的设置。
- 如果启用了随机选择 MAC 地址功能，则在系统显示 WLAN 接口 MAC 地址时显示生成的随机 MAC 地址。
使用设置界面的参考实现来实现新提示。
验证
要验证该功能是否如期正常运行，请同时运行集成测试 (ACTS) 和手动测试。
要运行集成测试，请使用位于 tools/test/connectivity/acts/tests/google/wifi 中的 ACTS 文件 WifiConnectedMacRandomizationTest.py，验证设备是否使用随机选择的 MAC 地址，以及是否正确存储为每个网络随机选择的 MAC 地址。
要运行手动测试，请执行以下操作：
- 开启该功能并验证设备是否能够连接到 WLAN 网络。
- 验证 WLAN 设置中显示的 MAC 地址是否与设备正在使用的 MAC 地址（通过 ifconfig 确定）相符。
- 执行数据包捕获来验证设备是否使用随机选择的 MAC 地址（而非出厂 MAC 地址）。
- 检查设备是否会在连接到同一网络时使用同一 MAC 地址，验证设备是否存储了基于网络随机选择的 MAC 地址。
- 验证忘记网络并重新连接到同一 SSID 后是否会生成新的随机 MAC 地址。
在连接到网络时，您可能会遇到长达 3 秒的延迟，这是因为只要设置了新的 MAC 地址，系统就会清除扫描结果。在连接到网络并验证互联网连接时，也可能会出现其他延迟。
如果 WLAN 驱动程序或固件未正确同步 MAC 地址状态与主机内核，则互联网连接检查将会失败。如果出现这种情况，请咨询您的芯片合作伙伴，确保驱动程序或固件已根据新的 MAC 地址进行了相应更新。
六、 Passpoint R1
自从 Android 6.0 支持从网络下载包含配置文件和凭据信息的特殊文件来配置 Passpoint R1（第 1 版）凭据，Android 就一直支持 Passpoint R1。客户端会自动启动用于 WLAN 信息的特殊安装程序，并允许用户先查看各部分信息，然后再决定接受或拒绝内容。
文件中包含的配置文件信息用于与从已启用 Passpoint R1 的接入点检索到的数据进行匹配，并且系统会自动将凭据应用于任何匹配的网络。
Android 参考实现支持 EAP-TTLS、EAP-TLS、EAP-SIM、EAP-AKA 和 EAP-AKA'。
下载机制
wifi-config 文件必须托管在网络服务器上，而且应使用 TLS (HTTPS) 进行保护，因为其中可能包含明文密码或私钥数据。内容由经过封装的多部分 MIME 文本（以 UTF-8 表示）组成，并按照 RFC-2045 第 6.8 节所述以 base64 编码形式进行编码。
客户端使用以下 HTTP 标头字段在设备上自动启动 WLAN 安装程序：
Content-Type必须设置为application/x-wifi-configContent-Transfer-Encoding必须设置为base64- 不得设置
Content-Disposition
用于检索文件的 HTTP 方法必须为 GET。只要浏览器中的 HTTP GET 收到包含以上 MIME 标头的响应，系统就会启动安装应用。必须通过点按按钮（不支持指向下载网址的自动重定向）等 HTML 元素来触发下载。此行为仅适用于 Google Chrome；其他网络浏览器不一定会提供类似功能。
文件组成
以 base64 编码的内容必须由 Content-Type 为 multipart/mixed 的 MIME 多部分内容组成。以下部分构成了多部分内容的各个部分：
| 部分 | 内容类型（较少引用） | 是否必需 | 说明 |
|---|---|---|---|
| 配置文件 | application/x-passpoint-profile |
始终必需 | 采用 OMA-DM SyncML 格式的负载，包含用于 HomeSP 和 Credential 且采用 Passpoint R1 PerProviderSubscription 格式的 MO。 |
| 信任证书 | application/x-x509-ca-cert |
可选（针对 EAP-TLS 和 EAP-TTLS） | 一个以 base64 编码的 X.509v3 证书负载。 |
| EAP-TLS 密钥 | application/x-pkcs12 |
必需（针对 EAP-TLS） | 以 base64 编码的 PKCS #12 ASN.1 结构，包含一个客户端证书链，其中至少具有客户端证书和关联私钥。PKCS 12 容器以及私钥和证书必须都是明文，没有密码。 |
“配置文件”部分必须以 base64 编码、UTF-8 编码的 XML 文本形式进行传输，这些文本会指定 Passpoint R2 技术规范版本 1.0.0 第 9.1 节中 HomeSP 和 Credential 子树的部分。
注意：Android 中用于 Passpoint R1 的配置文件 XML 格式借用了 Passpoint R2 格式，但不一定符合 R2 标准。这是一种设计上的选择，并非 Passpoint R1 的要求。
顶级节点必须是 MgmtTree，而直接子节点必须是 PerProviderSubscription。下面的附录中显示了一个示例 XML 文件。
以下子树节点在 HomeSP 下使用：
FriendlyName：必须设置；用作显示文本FQDN：必需RoamingConsortiumOI
以下子树节点在 Credential 下使用：
Realm：必须为非空字符串-
UsernamePassword：对于具有以下节点集的 EAP-TTLS 是必需的：UsernamePasswordEAPMethod/EAPType：必须设置为21EAPMethod/InnerMethod：必须设置为PAP、CHAP、MS-CHAP或MS-CHAP-V2中的一个
-
DigitalCertificate：对于 EAP-TLS 是必需的。必须设置以下节点：CertificateType设置为x509v3CertSHA256Fingerprint设置为 EAP-TLS 密钥 MIME 部分中客户端证书的正确 SHA-256 摘要。
-
SIM：对于 EAP-SIM、EAP-AKA 和 EAP-AKA' 是必需的。EAPType字段必须设置为适当的 EAP 类型，而IMSI必须与进行配置时设备中已安装的 SIM 卡之一的 IMSI 相匹配。IMSI 字符串可以完全由十进制数字组成以强制执行完全对等匹配，也可以包含零个或更多个十进制数字，后跟星号 (*) 以将 IMSI 匹配要求放宽为仅匹配前缀。例如，IMSI 字符串 123* 将匹配 IMSI 以 123 开头的任何 SIM 卡。
示例配置文件 OMA-DM XML
-
<MgmtTree xmlns="syncml:dmddf1.2">
-
<VerDTD>1.2
VerDTD>
-
<Node>
-
<NodeName>PerProviderSubscription
NodeName>
-
<RTProperties>
-
<Type>
-
<DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0
DDFName>
-
Type>
-
RTProperties>
-
<Node>
-
<NodeName>i001
NodeName>
-
<Node>
-
<NodeName>HomeSP
NodeName>
-
<Node>
-
<NodeName>FriendlyName
NodeName>
-
<Value>Century House
Value>
-
Node>
-
<Node>
-
<NodeName>FQDN
NodeName>
-
<Value>mi6.co.uk
Value>
-
Node>
-
<Node>
-
<NodeName>RoamingConsortiumOI
NodeName>
-
<Value>112233,445566
Value>
-
Node>
-
Node>
-
<Node>
-
<NodeName>Credential
NodeName>
-
<Node>
-
<NodeName>Realm
NodeName>
-
<Value>shaken.stirred.com
Value>
-
Node>
-
<Node>
-
<NodeName>UsernamePassword
NodeName>
-
<Node>
-
<NodeName>Username
NodeName>
-
<Value>james
Value>
-
Node>
-
<Node>
-
<NodeName>Password
NodeName>
-
<Value>Ym9uZDAwNw==
Value>
-
Node>
-
<Node>
-
<NodeName>EAPMethod
NodeName>
-
<Node>
-
<NodeName>EAPType
NodeName>
-
<Value>21
Value>
-
Node>
-
<Node>
-
<NodeName>InnerMethod
NodeName>
-
<Value>MS-CHAP-V2
Value>
-
Node>
-
Node>
-
Node>
-
Node>
-
Node>
-
Node>
-
MgmtTree>
身份验证建议
搭载 Android 8.0 或更高版本且装有 Passpoint R1 EAP-SIM、EAP-AKA 或 EAP-AKA 配置文件的设备将无法自动连接到 Passpoint 网络。此问题会减少 WLAN 分流，从而对用户、运营商和服务造成影响。
| 细分 | 影响 | 影响大小 |
|---|---|---|
| 运营商和 Passpoint 服务提供商 | 增加移动网络的负载。 | 使用 Passpoint R1 的任何运营商。 |
| 用户 | 错过了自动连接到运营商 WLAN 接入点 (AP) 的机会，从而增加流量费用。 | 在支持 Passpoint R1 的运营商网络上运行设备的任何用户。 |
失败原因
Passpoint 会指定一种机制，将广告 (ANQP) 服务提供商与设备上安装的配置文件进行匹配。以下针对 EAP-SIM、EAP-AKA 和 EAP-AKA 的匹配规则是侧重于 EAP-SIM/AKA/AKA 失败的部分规则：
-
If the FQDN (Fully Qualified Domain
Name) matches
-
then the service
is a Home Service Provider.
-
Else:
If the PLMN ID (
3GPP Network) matches
-
then the service
is a Roaming Service Provider.
第二个条件在 Android 8.0 中进行了修改：
-
Else:
If the PLMN ID (
3GPP Network) matches
AND the NAI Realm matches
-
then the service
is a Roaming Service Provider.
此修改后的条件意味着系统检测不到任何与以前正常工作的服务提供商匹配的项目，因此 Passpoint 设备未自动连接。
解决方法
要解决修改后的匹配条件存在的问题，运营商和服务提供商需要将 NAI Realm 添加到由 Passpoint AP 发布的信息中。
推荐的解决方案是让网络服务提供商实施网络端解决方法，这种方法部署速度最快。设备端解决方法依赖于原始设备制造商 (OEM) 从 Android 开源项目 (AOSP) 获取变更列表 (CL)，然后更新在实际应用中的设备。
针对运营商和 Passpoint 服务提供商的网络修复
网络端解决方法需要重新配置网络以添加 NAI Realm ANQP 元素（如下文所述）。Passpoint 规范不需要 NAI Realm ANQP 元素，但添加此属性符合 Passpoint 规范，因此符合规范的客户端实现应该不会发生中断。
- 添加
NAI RealmANQP 元素。 - 设置
NAI Realm子字段以匹配设备上安装所配置文件的Realm。
针对原始设备制造商 (OEM) 的设备/AOSP 修复
要实现设备端解决方法，原始设备制造商 (OEM) 需要选择补丁程序 CL aosp/718508。此补丁程序可以在以下系统版本上应用：
- Android 8.x
- Android 9
挑选补丁程序后，原始设备制造商 (OEM) 需要更新在实际应用中的设备。
七、 运营商WLAN
运营商 WLAN 是 Android 9 中引入的一项功能，该功能可让设备自动连接到运营商实现的 WLAN 网络。在高度拥塞或信号覆盖范围较小的区域（如体育场或地铁站），运营商 WLAN 可用于改善用户的连接体验和分载流量。
实现
要实现运营商 WLAN，设备制造商和运营商必须执行以下操作。
制造商
在运营商配置管理器中，为每个运营商配置以下参数：
-
KEY_CARRIER_WIFI_STRING_ARRAY：一个字符串数组，其中各字符串条目是以 Base64 编码的 WLAN SSID 和 EAP 类型（中间由逗号隔开，EAP 类型是一个整数）（请参阅 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml）。例如，以下配置针对使用 EAP-AKA 的 SOME_SSID_NAME 和使用 EAP-SIM 的 Some_Other_SSID：- config {
- key: "carrier_wifi_string_array"
- text_array {
- item: "U09NRV9TU0lEX05BTUUK,23"
- item: "U29tZV9PdGhlcl9TU0lECg==,18"
- }
- }
IMSI_KEY_AVAILABILITY_INT：标识用于 IMSI 加密的密钥是适用于 WLAN（设置位 1）还是 EPDG（设置位 0），或两者都适用（同时设置位 0 和位 1）。例如，以下配置指示 IMSI 加密适用于 WLAN，但不适用于 EPDG：-
-
config {
-
key: "imsi_key_availability_int"
-
int_value: 2
-
}
-
IMSI_KEY_DOWNLOAD_URL_STRING：从中下载 proto（包含用于 IMSI 加密的运营商公钥）的网址。例如，以下配置提供了特定的网址：-
-
config {
-
key: "imsi_key_download_url_string"
-
text_value: "https://www.some_company_name.com:5555/some_directory_name/"
-
}
-
运营商
要实现运营商 WLAN，运营商必须支持加密的 IMSI 并提供一个公钥。
支持加密的 IMSI
更改 WLAN 网络配置以确保可处理加密的 IMSI。EAP-SIM 中使用的身份格式为：
Prefix | [IMSI || Encrypted IMSI] | @realm | {, Key Identifier AVP}
其中“|”（单竖线）表示串联，“||”（双竖线）表示专有值，“{}”（大括号）表示可选值，领域是根据 3GGP 规范 (TS23.003) 从指定 MNC/MCC 派生的 3GPP 网络域名。
Prefix 值包括：
- “
\0”：加密身份 - “
0”：EAP-AKA 身份 - “
1”：EAP-SIM 身份 - “
6”：EAP-AKA' 身份
Encrypted IMSI 的格式为：
Base64{RSA_Public_Key_Encryption{eapPrefix | IMSI}}
其中“|”表示串联。
eapPrefix 值包括：
- “
0”- EAP-AKA 身份 - “
1”- EAP-SIM 身份 - “
6”- EAP-AKA' 身份
提供公钥
提供托管运营商证书的公开网址，其中：
- 公钥（和到期日期）可从证书中提取
- 信息采用如下所示的 JSON 格式：
-
{
-
"carrier-keys" : [ {
-
"key-identifier" :
"CertificateSerialNumber=5xxe06d4",
-
"certificate" :
"-----BEGIN CERTIFICATE-----\r\nTIIDRTCCAi2gAwIBAgIEVR4G1DANBgkqhkiG9w0BAQsFADBTMQswCQYDVQQGEwJVUzELMAkGA1UE\r\nCBMCTkExCzAJBgNVBAcTAk5BMQswCQYDVQQKEwJOQTELMAkGA1UECxMCTkExEDAOBgNVBAMTB1Rl\r\nc3RiT6N1/w==\r\n-----END CERTIFICATE-----",
-
"key-type" :
"WLAN"
-
} ]
-
}
自定义
运营商 WLAN 默认处于关闭状态（除非在运营商配置管理器中针对每个运营商对其进行配置）。如果该功能处于开启状态，则设备会自动尝试连接到网络。在初次尝试时，系统会发送一条通知。
八、 WLAN感知
通过 Android 8.0 中新增的 WLAN 感知功能，支持设备可以直接使用 WLAN 感知协议发现其他设备、与其他设备进行互连，以及将覆盖范围扩展到其他设备（Android 9 中新增的功能），而无需连接到互联网或移动网络。此功能是基于 WLAN 联盟 (WFA) WLAN 感知规范（2.0 版）构建的，它支持在断开网络的情况下，在可信设备与应用之间轻松共享高吞吐量数据。
示例和来源
要使用此功能，设备制造商应采用在 Android 开源项目 (AOSP) 中提供的 WLAN 硬件接口设计语言 (HIDL)。HIDL 取代了之前使用的硬件抽象层 (HAL) 结构，以便通过指定收集到接口和软件包的类型和方法调用来简化实现流程。
借助 WLAN HIDL 使用 WLAN 感知功能：hardware/interfaces/wifi/1.2。WLAN 感知 HAL 表面非常大；hardware/interfaces/wifi/1.2/README-NAN.md 文件描述了框架当前使用的子集。
您可以参考旧版 WLAN HAL 来了解它与新 HIDL 接口之间的关系：hardware/libhardware_legacy/+/master/include/hardware_legacy/wifi_nan.h。
实现
设备制造商需要提供框架和 HAL/固件支持：
- 框架：
- AOSP 代码
- 启用感知功能：需要功能标记和 HIDL 编译标记
- WLAN 感知 (NAN) HAL 支持（意味着固件支持）
为实现此功能，设备制造商需采用 WLAN HIDL，另外还要启用两个功能标记：
-
在位于
device/的/ BoardConfig.mk或 BoardConfig-common.mk 中，添加以下标记：WIFI_HIDL_FEATURE_AWARE := true
- 在位于
device/的/ device.mk中，修改PRODUCT_COPY_FILES环境变量，以便纳入对 WLAN 感知功能的支持： -
-
PRODUCT_COPY_FILES +=
-
frameworks/ native/ data/etc/android.hardware.wifi.aware.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.aware.xml
-
WLAN 感知功能包括使用 IEEE 802.11mc 协议（又称为往返时间 (RTT)）将覆盖范围扩展到对等设备。WLAN 感知的这一子功能取决于支持 WLAN RTT 功能的设备，即它要求设备支持 WLAN 感知和 WLAN RTT。有关详情，请参阅 WLAN RTT。
除此以外，实现此功能所需的所有内容都会包含在 AOSP 中。
随机分配 MAC 地址
Android 要求随机分配 WLAN 感知发现 (NMI) 和数据接口 (NDP) 的 MAC 地址，而且随机分配的 MAC 地址不应与设备的真实 MAC 地址相同。MAC 地址必须满足以下条件：
- 每当启用或重新启用 WLAN 感知时进行随机分配。
-
WLAN 感知功能启用后，必须按照由
NanConfigRequest.macAddressRandomizationIntervalSecHIDL 参数配置的有规律的间隔随机分配 MAC 地址。框架将时间间隔默认配置为 30 分钟。注意：根据 WLAN 感知规范，配置 NDP 后，随机分配可能会被暂停。
验证
Android 提供了一组单元测试、集成测试 (ACTS)、兼容性测试套件 (CTS) 测试和 CTS 验证程序测试，以验证 WLAN 感知功能。您也可以使用供应商测试套件 (VTS) 来测试 WLAN 感知功能。
单元测试
WLAN 感知软件包测试：
服务测试：
-
% ./frameworks/opt/net/wifi/tests/wifitests/runtests.sh -e
package
-
com.android.server.wifi.aware
Manager 测试：
% ./frameworks/base/wifi/tests/runtests.sh -e package android.net.wifi.aware
集成测试 (ACTS)
acts/sl4a 测试套件（在 tools/test/connectivity/acts/tests/google/wifi/aware/README.md 中有相应说明）提供了功能测试、性能测试和压力测试。
兼容性测试套件 (CTS)
使用 CTS 测试来验证 WLAN 感知功能。CTS 会检测何时启用了这项功能，并会自动包含相关测试。
可以使用以下方法触发 CTS 测试：
% atest SingleDeviceTest
CTS 验证程序测试
CTS 验证程序测试使用以下两种设备验证 WLAN 感知行为：测试设备和已知良好的设备。要运行测试，请打开 CTS 验证程序并转到“WLAN 感知测试”部分。
九、 WLAN往返时间（RTT）
WLAN RTT (IEEE 802.11mc)
Android 9 中的 WLAN 往返时间 (RTT) 功能允许设备测量与其他支持设备的距离：无论它们是接入点 (AP) 还是 WLAN 感知对等设备（如果设备支持 WLAN 感知）。此功能基于 IEEE 802.11mc 协议，使应用能够使用准确性更高的定位功能和增强的感知功能。
示例和来源
要使用此功能，请采用在 Android 开源项目 (AOSP) 中提供的 WLAN 硬件接口设计语言 (HIDL)。在 Android 8.0 中，HIDL 取代了之前使用的硬件抽象层 (HAL) 结构，以便通过指定收集到接口和软件包的类型和方法调用来简化实现流程。
借助 WLAN HIDL 使用 WLAN RTT 功能：hardware/interfaces/wifi/1.0 或更高版本。
您可以参考旧版 WLAN HAL 来了解它与新 HIDL 接口之间的关系：hardware/libhardware_legacy/+/master/include/hardware_legacy/rtt.h。
实现
要实现 WLAN RTT，您必须提供框架和 HAL/固件支持：
-
框架：
- AOSP 代码
- 启用 WLAN RTT：需要功能标记
-
WLAN RTT (IEEE 802.11mc) HAL 支持（意味着固件支持）
要实现此功能，请采用 WLAN HIDL，另外还要启用功能标记：
-
在位于
device/的/ device.mk中，修改PRODUCT_COPY_FILES环境变量，以便支持 WLAN RTT 功能：PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.rtt.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.rtt.xml
除此以外，实现此功能所需的所有内容都会包含在 AOSP 中。
随机分配 MAC 地址
为加强隐私保护，在 WLAN RTT 事务期间使用的 MAC 地址必须是随机分配的地址，即不得与 WLAN 接口的原生 MAC 地址一致。不过，有一种例外情况：如果某个设备与 AP 相关联，则此设备可能会使用与其相关联的 MAC 地址来处理与此 AP 或其他 AP 之间的任何 RTT 事务。
验证
这项功能有适用的 Android 兼容性测试套件 (CTS) 测试。CTS 会检测何时启用了这项功能，并会自动包含相关测试。您也可以使用供应商测试套件 (VTS) 和 acts/sl4a（用于执行扩展程序集成测试的测试套件）来测试此功能。
单元测试
使用以下测试执行 WLAN RTT 软件包测试：
服务测试：
-
% ./frameworks/opt/net/wifi/tests/wifitests/runtests.sh -e
package
-
com.android.server.wifi.rtt
Manager 测试：
% ./frameworks/base/wifi/tests/runtests.sh -e package android.net.wifi.rtt
集成 (ACTS) 测试
acts/sl4a 测试套件（在 /tools/test/connectivity/acts/tests/google/wifi/rtt/README.md 中有相应说明）提供了功能测试、性能测试和压力测试。
CTS
这项功能有适用的 Android 兼容性测试套件 (CTS) 测试。CTS 会检测何时启用了这项功能，并会自动包含相关测试。支持 WLAN RTT (IEEE 802.11mc) 的接入点必须位于被测设备的覆盖范围内。
您可以使用以下命令触发 CTS 测试：
% atest WifiRttTest
校准
为了确保 WLAN RTT 能够正常运行，802.11mc 协议中返回的距离的精确度应在关键绩效指标 (KPI) 范围内（理想情况下）。对于所列带宽出现的 90% 的 CDF 错误，针对距离估算值建议的 KPI 具有以下容差：
- 80MHz：2 米
- 40MHz：4 米
- 20MHz：8 米
为确保正确实现功能，您必须进行校准测试。
您可以通过以下方式来实现这项测试：通过不断增加距离，比较地面真实距离和 RTT 估算距离。如果真实距离和 RTT 估算距离基本一致，则您应该针对已知已进行 RTT 校准的设备验证解决方案。距离校准应在下列条件下进行测试：
- 大型开放实验室或没有大量金属物体（金属物体可能会导致多路径异常高发）的走廊。
- 视线 (LOS) 路线/路径至少要延长 25 米。
- 从路线一端到另一端以每次增加 0.5 米的方式标记。
- 选择一个位于路线一端的位置来安装支持 RTT 的接入点（位于地面以上 20 厘米处）；一个可移动支架（也位于地面上方 20 厘米处），用于沿路线移动 Android 手机（或接受测试的其他 Android 移动设备），可移动支架应与每隔 0.5 米出现的标记对齐。注意：这项重复性任务可由小型机器人来完成，也可以由人工操作员来完成。
- 每个标记处应记录 50 个距离结果，同时应记录相应标记距离接入点的距离。应在每个标记位置处计算统计信息（例如距离均值和方差）。
您可以根据第 5 步中的结果绘制一个图表，其中 X 轴为地面真实距离，Y 轴为估算距离，以及一条估算出的最合适的回归路线。理想的设备校准会产生一条梯度为 1.0 的线，且 Y 轴的偏差为 0.0 米。如果这些值的偏差落在相应带宽的 KPI 范围内，则这些偏差是可接受的。如果结果超过 KPI 范围，则应该重新校准设备功能，以使结果符合 KPI 规范。
十、 测试、调试和调整WLAN
本文将介绍如何使用 ASOP 中提供的工具测试、调试和调整 WLAN 实现。
测试
为了测试 WLAN 框架，AOSP 提供了一系列单元测试、集成测试 (ACTS) 和 CTS 测试。
单元测试
AOSP 包括针对默认 WLAN 框架的功能测试和单元测试：这两项测试均适用于 WLAN Manager（应用端代码）和 WLAN 服务。
WLAN Manager 测试：
- 位于
frameworks/base/wifi/tests中 -
使用以下 shell 可执行文件运行（有关更多执行选项，请参阅文件）：
% ./frameworks/base/wifi/tests/runtest.sh
WLAN 服务测试：
- 位于
frameworks/opt/net/wifi/tests/wifitest中 -
使用以下 shell 可执行文件运行（有关更多执行选项，请参阅文件）：
% ./frameworks/opt/net/wifi/tests/wifitests/runtest.sh
Android 通讯测试套件
Android 通讯测试套件 (ACTS) 用于执行对连接堆栈（例如 WLAN、蓝牙和移动网络服务）的自动测试。该测试工具需要 adb 和 Python，您可以在以下位置找到它：tools/test/connectivity/acts。
您可以在以下位置找到针对 WLAN 的 ACTS 测试：tools/test/connectivity/acts/tests/google/wifi，而且同一目录下还包含以下示例测试配置：example_config.json。
CTS 测试
兼容性测试套件 (CTS) 包括针对 WLAN 框架的测试。这些测试位于以下位置：cts/tests/tests/net/src/android/net/wifi。WLAN CTS 测试要求在测试开始运行时将受测设备与接入点相关联。
针对调试的增强型日志记录选项
Android 9 改进了 WLAN 日志记录功能，以便更轻松地调试 WLAN 问题。在 Android 9 中，驱动程序/固件环形缓冲区可以始终处于开启状态。在检测到错误状态时，可能会自动触发错误报告（仅限 userdebug 和 eng 版本）。如果您使用的是最新 WLAN HAL（1.2 版），则固件调试缓冲区存储在 HAL 中而不是框架内，以节省 IPC 费用。
实现
有关参考实现，请参阅供应商 HAL 中的默认实现。
您可以通过将资源 config_wifi_enable_wifi_firmware_debugging 设置为 false 来停用固件日志记录。
集成测试 (ACTS)
您可以在以下位置找到集成测试：/tools/test/connectivity/acts/tests/google/wifi/WifiDiagnosticsTest.py。
对于 userdebug 版本，已验证的固件转储会保留在闪存中相应的 tombstone 目录下。在创建错误报告时，Dumpstate 就是从此目录中收集的。
手动测试
运行以下手动测试，以验证 tombstone 目录中的旧文件是否已被删除。
- 开启 WLAN。
- 连接到网络。
- 生成错误报告。
- 检查 bugreport zip 文件并验证
/lshal-debug/[email protected]__IWifi_default.txt中是否包含已归档的固件日志。
配置调整
为了控制设备在与网络建立关联和取消关联时采用的信号强度，WLAN 框架使用了“entry”和“exit”RSSI 阈值。
系统会将“entry”和“exit”阈值存储为可过载的配置参数，并使用以下名称（其中 bad 参数是指“exit”RSSI 阈值）：
config_wifi_framework_wifi_score_bad_rssi_threshold_5GHzconfig_wifi_framework_wifi_score_entry_rssi_threshold_5GHzconfig_wifi_framework_wifi_score_bad_rssi_threshold_24GHzconfig_wifi_framework_wifi_score_entry_rssi_threshold_24GHz
系统会将这些参数存储在
注意：bad 配置参数（适用于 2.4GHz 和 5GHz 的频段）已在 Android 8.1 之前的版本中引入。entry 配置参数已在 Android 8.1 中引入，其默认值等于对应的 bad 参数。这些默认值会导致出现 Android 8.1 之前的版本中的行为，即系统在选择网络时不使用迟滞功能。要充分利用 Android 8.1 中引入的迟滞功能，请使用上文中指定的叠加层文件将 entry 参数设为 3dB 或比 bad 参数更高的值。
您可以使用 adb 命令来配置设备，从而测试新的阈值（或者，您也可以使用新的叠加层来创建编译，但使用 adb 命令可以加快测试周期）。
-
% adb shell settings put global wifi_score_params \
-
[rssi2|rssi5]=
<bad>:
<entry>:
<low>:
<good>
例如，以下命令可以配置新的阈值参数（此示例命令中使用的值是 AOSP 代码库中配置的默认值）：
-
% adb shell settings put global wifi_score_params \
-
rssi2=-
85
:-
85
:-
73
:-
60,rssi5=-
82
:-
82
:-
70
:-
57
要恢复内置的参数值（即移除替换），请使用以下 abd 命令：
% adb shell settings delete global wifi_score_params