com.mediatek.FrameworkResOverlayExt Copy

A MediaTek package whose name follows Android's Runtime Resource Overlay (RRO) convention, preinstalled on MediaTek-based devices. AOSP describes an RRO as a resource-only package that changes the resource values of a target package at runtime without modifying that target's code. From the name this is a framework-targeting overlay with an "Ext" suffix, so it reads as an additional overlay alongside com.mediatek.frameworkresoverlay, which is documented separately on this site and which this site records on many of the same device models. That target, and the division of work between the two packages, is inference from the naming convention rather than a sourced fact: MediaTek publishes no manifest or documentation for either package, and the resource values an individual firmware sets are not published. Provenance is the part that is recorded rather than inferred, and it repeats the pattern already noted on this site for MediaTek components. The sample here sees the same package name across 19 device makes, including Xiaomi, Samsung, Motorola, OPPO, vivo, TCL, Lenovo, Nothing, Infinix, OUKITEL, Ulefone, Unihertz, Newland, CUBOT and NUU, under 15 distinct signing certificates. Each of those certificates is classified here as the device maker's own key, and each is recorded as also signing the Android framework, a platform-level key. That per-maker platform signing is the pattern seen when a silicon vendor's component is rebuilt into each maker's firmware rather than shipped under one shared key. Builds are small, between roughly 8.5 KB and 16.8 KB, there is no launcher entry, no observation here is user-facing, and none is Play-eligible. One detail is recorded without interpretation. The aggregated permission set holds a single entry, POST_NOTIFICATIONS, and no sourced explanation for it was found. The same entry appears on com.mediatek.SettingsProviderResOverlay, documented separately here. This site aggregates permissions across observations rather than per build, so which builds request it cannot be established. Version note. Observations here run from API 31 to API 36, with a target SDK roll-up of 31 to 36; the oldest build by version code carries the version name 12 and the newest 16. By comparison this site records com.mediatek.frameworkresoverlay from API 29. The "Ext" package therefore appears on the newer API levels within this sample while its sibling appears on older ones too, which is an observation about what has been sampled rather than a sourced statement about when MediaTek introduced it. Whether the values it overlays changed across those releases could not be sourced. For Android Enterprise, EMM and kiosk use it exposes nothing a user interacts with, and no enrolment or management role is identified in the sources cited here. It is worth being explicit that an overlay is not a policy mechanism: it sets resource values in its target and does not grant, deny or override the restrictions an EMM applies through device policy. If it is the framework overlay its name indicates, disabling it would revert the framework to its unoverlaid values, which can change platform behaviour in ways that are chipset and firmware specific, so it is best left enabled and only changed with careful per-device testing.

• Change the value of an app's resources at runtime (RROs) - Android Open Source Project →
• Package provenance for com.mediatek.FrameworkResOverlayExt - Android System App Database →
• Package provenance for com.mediatek.frameworkresoverlay - Android System App Database →
• Package provenance for com.mediatek.SettingsProviderResOverlay - Android System App Database →

• Re-signed by each device maker with its own platform key - 15 different certificates appear across 10 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.