com.android.wifi.resources.overlay Copy

A Runtime Resource Overlay (RRO) for the Wi-Fi module's resources package, not an app in its own right. AOSP builds that resources package as ServiceWifiResources, whose manifest declares the package name com.android.wifi.resources, and it holds the configuration values the Wi-Fi service reads at runtime. Because the values are kept in a resources APK, a device maker can change Wi-Fi behaviour for its hardware by shipping a small overlay that redefines them instead of modifying the Wi-Fi code. This package is one of those overlays: it carries no code, has no launcher entry in any of the observations recorded here, and is a few kilobytes in size, between about 12 KB and 17 KB, with the version name 1.0 throughout. The naming follows an AOSP convention rather than being a package Google ships. AOSP's own sample overlay lives at device/google/coral/rro_overlays/WifiOverlay and declares the package name com.android.wifi.resources.pixel, setting android:targetPackage to com.android.wifi.resources, android:targetName to WifiCustomization and android:isStatic to true. The Wi-Fi module's overlayable.xml points readers at that sample directly, noting that the values "can be overridden by OEM's by using an RRO overlay app". A package named com.android.wifi.resources.overlay is the same pattern with a generic suffix in place of a device name. WifiCustomization is the overlayable set involved, and its policy allows overlays from the odm, product, system or vendor partitions. The values it exposes are the hardware-shaped ones: which bands the device supports (config_wifi24ghzSupport, config_wifi5ghzSupport, config_wifi6ghzSupport, config_wifi60ghzSupport), whether 802.11ax and 802.11be support is overridden, whether WEP and WPA-Personal are treated as deprecated, fast BSS transition, the Wi-Fi Direct device type, background scan support, whether the country code reverts when cellular is lost, and the logger ring buffer sizes. One limit is worth stating plainly, because it changes how much this entry can tell you. This site records a package's own name, not the targetPackage inside its manifest, so which resources package a given device's copy of this overlay actually targets cannot be read from here. That distinction matters on Wi-Fi more than most places: AOSP warns that where the Wi-Fi module delivers its resources APK under the Google name, "you must set the overlay APKS targetPackage to com.google.android.wifi.resources to overlay Wi-Fi configurations successfully". The AOSP-named com.android.wifi.resources, the Google-named com.google.android.wifi.resources and Samsung's com.samsung.android.wifi.resources are each documented separately on this site. A second observation is recorded here without an explanation: the only permission this package declares is POST_NOTIFICATIONS, which a code-free overlay has no obvious use for. The Google-named tethering overlay reports the same single permission, so it looks like a property of how these overlay APKs are built or recorded rather than anything specific to Wi-Fi, but no source consulted accounts for it. Provenance fits an overlay compiled into each device image rather than something delivered centrally. In our sample it is signed by 13 distinct signing keys, every one of them classified as an OEM key that also signs the framework on its own devices, across Motorola, TCL, Newland, ANT DAO Technology, OUKITEL, vivo, Xiaomi, NUU and OPPO. It appears on 42 devices spanning 21 makes, weighted towards budget and ODM-built hardware (TCL, Lenovo, Motorola, OUKITEL, Infinix, Honor, Blackview, Cubot and others) rather than towards Samsung or Pixel. Version note: the Wi-Fi module (com.android.wifi) is in APEX format and is available for devices running Android 11 or higher, so this overlay belongs to the Android 11 and later module layout rather than to older builds where Wi-Fi configuration sat in the framework. That matches the field data, which records it from API 30 through API 36, targeting API 31 to 35. No change in the overlay's role across those releases could be sourced, and the flat 1.0 version name gives no signal either way. For Android Enterprise, EMM and kiosk use it has no role in enrolment or policy and nothing a user interacts with. What it does is tell the Wi-Fi stack what this particular radio supports, so disabling or removing it does not lock Wi-Fi down: it drops the device back to whatever the unoverlaid resources say, which is a route to a device that misreports its own band or standard support. Leave it in place and use your EMM's Wi-Fi configuration and restriction policies to control what users can do with Wi-Fi.

• Wi-Fi - Android Open Source Project →
• Change the value of an app's resources at runtime (RROs) - Android Open Source Project →
• ServiceWifiResources AndroidManifest.xml (packages/modules/Wifi) - Android source →
• ServiceWifiResources overlayable.xml, WifiCustomization (packages/modules/Wifi) - Android source →
• WifiOverlay AndroidManifest.xml, sample Wi-Fi RRO (device/google/coral) - Android source →
• Package provenance for com.android.wifi.resources.overlay - Android System App Database →
• Package provenance for com.google.android.networkstack.tethering.overlay - Android System App Database →

• Re-signed by each device maker with its own platform key - 13 different certificates appear across 9 device makers in our sample. That is the signature of a stock AOSP/system package every OEM builds and signs itself, not a single maker's or a third party's preinstall. These are platform-level keys: they also sign the Android framework itself.
• Its largest observed manifest declares 1 permissions: 1 runtime (user-granted).
• Never reported as user-facing, so it runs as a background or system component rather than an app the user opens.