Wi-Fi 模块是可更新的,这意味着它可以在正常的 Android 发布周期之外接收功能更新。该模块包含以下组件。
图 1. Wi-Fi 模块组件和架构
Wi-Fi 模块具有以下优点。
最终用户在 Android 设备上获得一致的 Wi-Fi 体验,并通过模块更新修复互操作性问题。
应用程序开发人员减少了平台碎片化。
原始设备制造商可以满足运营商的要求,同时还可以降低个别定制的成本(因为他们不需要以不同的方式对相同的要求进行不同的实施)。
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 manifest存放于此)-
res/
(Android 11 中的新功能,从frameworks/base/core/res/res
中提取的 Wi-Fi 配置) -
AndroidManifest.xml
-
Android.bp
-
-
WifiDialog/
(Android 13 App 中新增的启动服务请求的用户对话框存储在这里。)-
src/
-
com/android/wifi/dialog
(包含启动对话框的活动)
-
-
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 构建的一部分。
-
system/connectivity/wificond
中的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 模块依赖于以下组件。
- 连通性
- 电话
- 原型库
- 杂项系统组件
- WiFi 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
,您必须将叠加 APKS 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 模块的设备可以通过对frameworks/opt/net/wifi/service/Android.bp
进行以下修改,继续在service-wifi
中使用@hide
外部 API(例如,来自framework.jar
)。 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中描述的测试。