Google is committed to advancing racial equity for Black communities. See how.

Wi-Fi

The Wi-Fi module is updatable, meaning it can receive updates to functionality 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 fulfull 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

The Wi-Fi service continues to run inside the System Service process. The Wi-Fi module includes most code in frameworks/opt/net/wifi and frameworks/base/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.google.android.wifi.apex) 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 dependences

The Wi-Fi module depends on the following components.

  • Connectivity
  • Telephony
  • Proto libraries
  • Misc system components
  • WiFi 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.

Customizing

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 mainline 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.

Using 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 frameworks/opt/net/wifi/service/res/values/overlayable.xml.For configuration behavior details, refer to frameworks/opt/net/wifi/service/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.

Migrating 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.

Accessing 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 frameworks/base/wifi/Android.bp by deleting the impl_library_visibility attribute.

    java_sdk_library {
        name: "framework-wifi",
        ...
        impl_library_visibility: [  // delete this attribute
            ...
        ],
        ...
    }
    
  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 shown below.

    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.

Accessing 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 functionality by running a comprehensive set of CTS tests on every module release. You can also run the tests described in Testing, Debugging, and Tuning Wi-Fi.