Wi-Fi

The Wi-Fi module is updatable, meaning it can receive updates to capabilities outside of the normal Android release cycle. This module contains the following components.

Wi-Fi module components

Figure 1. Wi-Fi module components and architecture

The Wi-Fi module provides the following benefits.

  • End users get a consistent Wi-Fi experience across Android devices and fixes to interoperability issues through module updates.

  • App developers get reduced platform fragmentation.

  • OEMs can fulfill carrier requirements while also reducing costs for individual customizations (as they don't need different implementations of the same requirements in different ways).

Module boundary for Android 12 and Android 13

  • packages/modules/Wifi
    • framework
      • java/
        • android/net/wifi (files from frameworks/base/wifi/java)
      • tests/
        • android/net/wifi (files from frameworks/base/wifi/tests)
      • aidl-export/
      • api/
      • Android.bp
    • service/
      • java/
        • com/android/server/wifi (files from frameworks/opt/net/wifi/service/java)
      • tests/
        • com/android/server/wifi (files from frameworks/opt/net/wifi/tests)
      • proto/
      • Android.bp
      • proguard.flags
      • wifi.rc
    • OsuLogin/ (files from frameworks/base/packages/OsuLogin)
    • ServiceResources/ (new in Android 12, Overlay APK manifest is stored here)
      • res/ (new in Android 11, Wi-Fi configs extracted from from frameworks/base/core/res/res)
      • AndroidManifest.xml
      • Android.bp
    • WifiDialog/ (new in Android 13 App to launch user dialogs requested by the service is stored here.)
      • src/
        • com/android/wifi/dialog (Contains the Activity the dialogs are launched from)
      • AndroidManifest.xml
      • Android.bp

The preceding directories also contain code that remains outside the modular system component and in its current location, for example:

  • wificond interface (classes in package android.net.wifi.nl80211, for example, WifiNl80211Manager)
  • Sample Resource Overlay app
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

OEMs can use the sample commands to help move their patches from the original project directories to the new project directory.

Move a patch from frameworks/base/wifi

Generating the patch file in root/frameworks/base/wifi

git format-patch -1 commit --stdout > patch-file.txt

Applying the patch file to root/packages/modules/Wifi

git am -p2 --directory=framework/ patch-file.txt

Move a patch from frameworks/opt/net/wifi

To move the patch from frameworks/opt/net/wifi, complex steps are needed because the directory hierarchy was changed during the migration.

In frameworks/opt/net/wifi, split the commit into two commits, one for service/ and one for tests/.

Migrating the HEAD commit

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

Generating two commit patch files

git format-patch -1 service-commit --stdout > service-patch.txt
git format-patch -1 test-commit --stdout > test-patch.txt

Applying the two patches to packages/modules/Wifi

git am service-patch.txt
git am -p1 --directory=service/ test-patch.txt

Squashing the two commits back into one commit

git rebase -i

Change the second commit's operation to squash.

Edit the commit message as appropriate.

Module boundary for Android 11

The Wi-Fi service continues to run inside the System Service process. The Wi-Fi module includes all code in packages/modules/Wifi including the following.

  • SDK and service classes for WifiService, WifiP2pService, WifiAwareService, WifiScannerService, and WifiRttService
  • OsuLogin
  • ServiceWifiResources

The module excludes the following components, which remain part of the OEM's AOSP build.

  • wificond native component in system/connectivity/wificond
  • wificond interface (classes in package android.net.wifi.nl80211, for example, WifiNl80211Manager)
  • android.net.wifi.SoftApConfToXmlMigrationUtil
  • android.net.wifi.WifiNetworkScoreCache
  • android.net.wifi.WifiMigration
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

Android 11 doesn't move files, but future releases might. To reduce the effort involved in porting file location changes, we recommend upstream as many changes as possible to AOSP (after porting them to Android 11 or refactoring proprietary extensions to use formal Android APIs or vendor HAL extensions to detangle them from AOSP code.

Module format

The Wi-Fi module (com.android.wifi) is in APEX format and is available for devices running Android 11 or higher. The APEX file includes the following components.

  • SDK library (framework-wifi.jar)
  • Service library (service-wifi.jar)
  • OsuLogin APK (OsuLoginGoogle.apk)
  • Resource APK (ServiceWifiResourcesGoogle.apk)
  • WFA certificates

Module dependencies

The Wi-Fi module depends on the following components.

  • Connectivity
  • Telephony
  • Proto libraries
  • Misc system components
  • Wi-Fi HALs
  • wificond
  • bouncycastle
  • ksoap2
  • libnanohttpd

This module interacts with the framework using only stable @SystemApi (no @hide API usage) and is signed with a Google signature instead of a platform signature.

Customization

The Wi-Fi module doesn't support direct customization, but you can customize the config using runtime resource overlays (RROs) or carrier configs.

Wi-Fi customization

Figure 2. Wi-Fi module customization

  • For small customizations, enable or disable settings in the RRO config.
  • For more control, customize config values for any carrier configuration key exposed as @SystemAPI.

Use runtime resource overlays

You can customize the Wi-Fi module by overriding the default configurations using RROs. For a list of overlayable configurations, refer to packages/modules/Wifi/service/ServiceWifiResources/res/values/overlayable.xml. For configuration behavior details, refer to packages/modules/Wifi/service/ServiceWifiResources/res/values/config.xml. For a sample overlay app, refer to device/google/coral/rro_overlays/WifiOverlay/.

Because the device/google/coral/rro_overlays/WifiOverlay/AndroidManifest.xml file sets the targetPackage attribute to com.android.wifi.resources and the resource APK delivered by the Wi-Fi module has package name com.google.android.wifi.resources, you must set the overlay APKS targetPackage to com.google.android.wifi.resources to overlay Wi-Fi configurations successfully.

Migrate configuration storage format

The Wi-Fi module can parse only the AOSP Wi-Fi configuration storage format. If you've previously modified the Wi-Fi configuration storage format (which includes the user's saved network list), you must convert that data to the AOSP format when upgrading a device to any Android release that includes the Wi-Fi module. The hooks needed for this conversion are in the android.net.wifi.WifiMigration class.

Implement the format conversion in the following methods.

  • WifiMigration.convertAndRetrieveSharedConfigStoreFile(<storeFileId>)

    • Invoked by Wi-Fi module to retrieve the Wi-Fi shared store file contents that have been converted to AOSP format.

    • These files were previously (in Android 10) stored in the /data/misc/wifi folder on the device.

  • WifiMigration.convertAndRetrieveUserConfigStoreFile(<storeFileId>)

    • Invoked by Wi-Fi module to retrieve Wi-Fi user-specific store file contents that have been converted to AOSP format.

    • These files were previously (in Android 10) stored in the /data/misc_ce/<userId>/wifi folder on the device.

Access hidden Wi-Fi APIs

Symbols (classes, methods, fields, etc.) annotated with @hide in the Wi-Fi module are not part of its public API surface and cannot be accessed on devices with the module installed. Devices that don't include the Wi-Fi module can continue to use @hide Wi-Fi APIs using the following steps.

  1. Remove the visibility restrictions placed on framework-wifi at packages/modules/Wifi/framework/Android.bp by changing the impl_library_visibility attribute to public.

    java_sdk_library {
    name: "framework-wifi",
    ...
    impl_library_visibility: [
       "//visibility:public", // Add this rule and remove others.
    ],
    ...
}

  2. Change the build rule to allow library access @hide Wi-Fi APIs. For example, the following is a build rule for a java_library.

    java_library {
    name: "foo-lib",

    // no sdk_version attribute defined

    libs: [
        "dependency1",
        "dependency2",
    ],
}

    To allow library access for foo-lib, change the build rule as follows:

    java_library {
    name: "foo-lib",

    sdk_version: "core_platform",

    libs: [
        "framework-wifi.impl",
        "framework",
        "dependency1",
        "dependency2",
    ],
}

  3. Ensure that framework-wifi.impl appears before framework in the list of libs. The order of dependencies in the libs attribute is significant.

Access hidden framework APIs

Symbols annotated with @hide outside the Wi-Fi module can't be accessed by code within the Wi-Fi module. Devices that don't include the Wi-Fi module can continue to use @hide external APIs (for example, from framework.jar) in service-wifi by making the following modifications to frameworks/opt/net/wifi/service/Android.bp.

  1. In both wifi-service-pre-jarjar and service-wifi, change the sdk_version attribute to core_platform.

  2. In both wifi-service-pre-jarjar and service-wifi, add framework and android_system_server_stubs_current to the libs attribute.

  3. Verify the result is similar to the following code sample.

    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",
    ],
}

Testing

The Android Compatibility Test Suite (CTS) verifies the Wi-Fi module's capabilities by running a comprehensive set of CTS tests on every module release. You can also run the tests described in Test, debug, and tune Wi-Fi.