Wi-Fi 模組可更新,因此可以接收一般 Android 發布週期以外的功能更新。這個模組包含下列元件。
圖 1. Wi-Fi 模組元件和架構
Wi-Fi 模組具備下列優點。
透過模組更新,使用者在所有 Android 裝置上都能享有一致的 Wi-Fi 體驗,並修正互通性問題。
應用程式開發人員可減少平台分散的情況。
原始設備製造商可以滿足電信業者需求,同時減少個別自訂項目的成本 (因為他們不需要以不同方式實作相同需求)。
Android 12 和 Android 13 的模組邊界
packages/modules/Wififrameworkjava/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.bpproguard.flagswifi.rc
OsuLogin/(來自「frameworks/base/packages/OsuLogin」的檔案)ServiceResources/(Android 12 新增,存放疊加 APK 資訊清單)res/(Android 11 新功能,從frameworks/base/core/res/res擷取的 Wi-Fi 設定)AndroidManifest.xmlAndroid.bp
WifiDialog/(Android 13 新增項目。應用程式啟動服務要求的使用者對話方塊會儲存在這裡)。src/com/android/wifi/dialog(包含對話方塊啟動的活動)
AndroidManifest.xmlAndroid.bp
上述目錄也包含位於模組化系統元件外部的程式碼,以及目前位置的程式碼,例如:
wificond interface(android.net.wifi.nl80211套件中的類別,例如WifiNl80211Manager)- 範例資源覆蓋應用程式
WifiTrackerLiblibwifi_hallibwifi_systemlibwifi_system_iface
原始設備製造商可以使用範例指令,將修補程式從原始專案目錄移至新專案目錄。
從 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-commitgit add tests/git commit # Enter your commit message. Call this commit test-commit
產生兩個修訂內容修補程式檔案
git format-patch -1 service-commit --stdout > service-patch.txtgit format-patch -1 test-commit --stdout > test-patch.txt
將這兩個修補程式套用至 packages/modules/Wifi
git am service-patch.txtgit 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 和服務類別 OsuLoginServiceWifiResources
模組不包含下列元件,這些元件仍屬於 OEM 的 AOSP 建構版本。
system/connectivity/wificond中的wificond原生元件wificond介面 (android.net.wifi.nl80211套件中的類別,例如WifiNl80211Manager)android.net.wifi.SoftApConfToXmlMigrationUtilandroid.net.wifi.WifiNetworkScoreCacheandroid.net.wifi.WifiMigrationWifiTrackerLiblibwifi_hallibwifi_systemlibwifi_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
wificondbouncycastleksoap2libnanohttpd
這個模組只會使用穩定 @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。
將
framework-wifi的packages/modules/Wifi/framework/Android.bp屬性變更為 public,移除對該屬性的瀏覽權限限制。impl_library_visibilityjava_sdk_library { name: "framework-wifi", ... impl_library_visibility: [ "//visibility:public", // Add this rule and remove others. ], ... }變更建構規則,允許存取程式庫
@hideWi-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出現在framework之前。libslibs屬性中的依附元件順序十分重要。
存取隱藏的架構 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 Compatibility Test Suite (CTS) 會在每個模組版本上執行全套 CTS 測試,驗證 Wi-Fi 模組的功能。您也可以執行「測試、偵錯及調整 Wi-Fi」一文所述的測試。