Wi-Fi 模块是可更新的,这意味着它可以接收 Android 正常发布周期之外的功能更新。此模块包含以下组件。
图 1. Wi-Fi 模块组件和架构
Wi-Fi 模块具有以下优势。
最终用户可以通过模块更新在各种 Android 设备上获得一致的 Wi-Fi 体验,并修复互操作性问题。
应用开发者可以减少平台碎片化。
OEM 可以满足运营商要求,同时还可以降低各个自定义项的成本(因为他们不需要以不同的方式对相同的要求进行不同的实现)。
Android 12 和 Android 13 的模块边界
packages/modules/Wifi
framework
java/
android/net/wifi
(来自frameworks/base/wifi/java
的文件)
tests/
android/net/wifi
(来自frameworks/base/wifi/tests
的文件)
aidl-export/
api/
Android.bp
service/
java/
com/android/server/wifi
(来自frameworks/opt/net/wifi/service/java
的文件)
tests/
com/android/server/wifi
(来自frameworks/opt/net/wifi/tests
的文件)
proto/
Android.bp
proguard.flags
wifi.rc
OsuLogin/
(来自frameworks/base/packages/OsuLogin
的文件)ServiceResources/
(Android 12 中的新增功能,Overlay APK 清单存储在此处)res/
(Android 11 中的新增功能,从frameworks/base/core/res/res
中提取的 Wi-Fi 配置)AndroidManifest.xml
Android.bp
WifiDialog/
(Android 13 中的新增功能,用于启动服务请求的用户对话框的应用存储在此处。)src/
com/android/wifi/dialog
(包含从中启动对话框的 Activity)
AndroidManifest.xml
Android.bp
前面的目录也包含保留在模块化系统组件之外且位于其当前位置的代码,例如
wificond interface
(软件包android.net.wifi.nl80211
中的类,例如WifiNl80211Manager
)- 示例资源叠加层应用
WifiTrackerLib
libwifi_hal
libwifi_system
libwifi_system_iface
OEM 可以使用示例命令来帮助将其补丁从原始项目目录移动到新项目目录。
从 frameworks/base/wifi 移动补丁
在 root/frameworks/base/wifi 中生成补丁文件
git format-patch -1 commit --stdout > patch-file.txt
将补丁文件应用到 root/packages/modules/Wifi
git am -p2 --directory=framework/ patch-file.txt
从 frameworks/opt/net/wifi 移动补丁
要从 frameworks/opt/net/wifi
移动补丁,需要执行复杂的步骤,因为目录层次结构在迁移期间已更改。
在 frameworks/opt/net/wifi
中,将提交拆分为两个提交,一个用于 service/
,另一个用于 tests/
。
迁移 HEAD 提交
git reset HEAD^
git add service/
git commit # Enter your commit message. Call this commit service-commit
git add tests/
git commit # Enter your commit message. Call this commit test-commit
生成两个提交补丁文件
git format-patch -1 service-commit --stdout > service-patch.txt
git format-patch -1 test-commit --stdout > test-patch.txt
将两个补丁应用到 packages/modules/Wifi
git am service-patch.txt
git am -p1 --directory=service/ test-patch.txt
将两个提交合并为一个提交
git rebase -i
将第二个提交的操作更改为 squash
。
根据需要编辑提交消息。
Android 11 的模块边界
Wi-Fi 服务继续在系统服务进程内运行。Wi-Fi 模块包含 packages/modules/Wifi
中的所有代码,包括以下内容。
- 适用于
WifiService
、WifiP2pService
、WifiAwareService
、WifiScannerService
和WifiRttService
的 SDK 和服务类 OsuLogin
ServiceWifiResources
该模块不包含以下组件,这些组件仍是 OEM AOSP 版本的一部分。
wificond
原生组件,位于system/connectivity/wificond
中wificond
接口(android.net.wifi.nl80211
包中的类,例如WifiNl80211Manager
)android.net.wifi.SoftApConfToXmlMigrationUtil
android.net.wifi.WifiNetworkScoreCache
android.net.wifi.WifiMigration
WifiTrackerLib
libwifi_hal
libwifi_system
libwifi_system_iface
Android 11 不会移动文件,但未来的版本可能会移动。为了减少移植文件位置更改所涉及的工作量,我们建议尽可能多地将更改向上游提交到 AOSP(在将更改移植到 Android 11 或重构专有扩展程序以使用正式的 Android API 或供应商 HAL 扩展程序,从而使其与 AOSP 代码分离之后)。
模块格式
Wi-Fi 模块 (com.android.wifi
) 采用 APEX 格式,适用于运行 Android 11 或更高版本的设备。APEX 文件包含以下组件。
- SDK 库 (
framework-wifi.jar
) - 服务库 (
service-wifi.jar
) - OsuLogin APK (
OsuLoginGoogle.apk
) - 资源 APK (
ServiceWifiResourcesGoogle.apk
) - WFA 证书
模块依赖项
Wi-Fi 模块依赖于以下组件。
- 连接
- 电话
- Proto 库
- 其他系统组件
- Wi-Fi HAL
wificond
bouncycastle
ksoap2
libnanohttpd
此模块仅使用稳定的 @SystemApi
(不使用 @hide
API)与框架交互,并使用 Google 签名而不是平台签名进行签名。
自定义
Wi-Fi 模块不支持直接自定义,但您可以使用运行时资源叠加 (RRO) 或运营商配置自定义配置。
图 2. Wi-Fi 模块自定义
- 对于小型自定义,请在 RRO
config
中启用或停用设置。 - 要获得更多控制,请自定义暴露为
@SystemAPI
的任何运营商配置键的配置值。
使用运行时资源叠加
您可以使用 RRO 通过替换默认配置来自定义 Wi-Fi 模块。如需查看可叠加配置的列表,请参阅 packages/modules/Wifi/service/ServiceWifiResources/res/values/overlayable.xml
。如需了解配置行为详情,请参阅 packages/modules/Wifi/service/ServiceWifiResources/res/values/config.xml
。如需查看示例叠加应用,请参阅 device/google/coral/rro_overlays/WifiOverlay/
。
由于 device/google/coral/rro_overlays/WifiOverlay/AndroidManifest.xml
文件将 targetPackage
属性设置为 com.android.wifi.resources
,并且 Wi-Fi 模块交付的资源 APK 的软件包名称为 com.google.android.wifi.resources
,因此您必须将叠加 APK 的 targetPackage
设置为 com.google.android.wifi.resources
才能成功叠加 Wi-Fi 配置。
迁移配置存储格式
Wi-Fi 模块只能解析 AOSP Wi-Fi 配置存储格式。如果您之前修改过 Wi-Fi 配置存储格式(包括用户保存的网络列表),则在将设备升级到包含 Wi-Fi 模块的任何 Android 版本时,必须将该数据转换为 AOSP 格式。此转换所需的挂钩位于 android.net.wifi.WifiMigration
类中。
在以下方法中实现格式转换。
WifiMigration.convertAndRetrieveSharedConfigStoreFile(<storeFileId>)
由 Wi-Fi 模块调用,以检索已转换为 AOSP 格式的 Wi-Fi 共享存储文件内容。
这些文件以前(在 Android 10 中)存储在设备上的
/data/misc/wifi
文件夹中。
WifiMigration.convertAndRetrieveUserConfigStoreFile(<storeFileId>)
由 Wi-Fi 模块调用,以检索已转换为 AOSP 格式的 Wi-Fi 用户特定存储文件内容。
这些文件以前(在 Android 10 中)存储在设备上的
/data/misc_ce/<userId>/wifi
文件夹中。
访问隐藏的 Wi-Fi API
在 Wi-Fi 模块中用 @hide
注释的符号(类、方法、字段等)不是其公共 API 表面的一部分,并且无法在安装了该模块的设备上访问。不包含 Wi-Fi 模块的设备可以继续使用 @hide
Wi-Fi API,方法是执行以下步骤。
通过将
impl_library_visibility
属性更改为 public,移除对packages/modules/Wifi/framework/Android.bp
中framework-wifi
施加的可见性限制。java_sdk_library { name: "framework-wifi", ... impl_library_visibility: [ "//visibility:public", // Add this rule and remove others. ], ... }
更改构建规则以允许库访问
@hide
Wi-Fi API。例如,以下是java_library
的构建规则。java_library { name: "foo-lib", // no sdk_version attribute defined libs: [ "dependency1", "dependency2", ], }
要允许库访问
foo-lib
,请按如下方式更改构建规则java_library { name: "foo-lib", sdk_version: "core_platform", libs: [ "framework-wifi.impl", "framework", "dependency1", "dependency2", ], }
确保
framework-wifi.impl
出现在libs
列表中的framework
之前。libs
属性中依赖项的顺序非常重要。
访问隐藏的框架 API
Wi-Fi 模块外部用 @hide
注释的符号无法被 Wi-Fi 模块内的代码访问。不包含 Wi-Fi 模块的设备可以继续在 service-wifi
中使用 @hide
外部 API(例如,来自 framework.jar
的 API),方法是对 frameworks/opt/net/wifi/service/Android.bp
进行以下修改。
在
wifi-service-pre-jarjar
和service-wifi
中,将sdk_version
属性更改为core_platform
。在
wifi-service-pre-jarjar
和service-wifi
中,将framework
和android_system_server_stubs_current
添加到libs
属性。验证结果是否与以下代码示例类似。
java_library { name: "wifi-service-pre-jarjar", ... sdk_version: "core_platform", ... libs: [ ... "framework", "android_system_server_stubs_current", ], } ... java_library { name: "service-wifi", ... sdk_version: "core_platform", ... libs: [ ... "framework", "android_system_server_stubs_current", ], }
测试
Android 兼容性测试套件 (CTS) 通过在每个模块版本上运行一套全面的 CTS 测试来验证 Wi-Fi 模块的功能。您还可以运行在测试、调试和调整 Wi-Fi 中描述的测试。