com.mediatek.MtkSettingsResOverlay 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. Read that way, the name points at an overlay onto a Settings application as built from a MediaTek BSP, which would make it a sibling of com.mediatek.SettingsProviderResOverlay, documented separately on this site, whose name instead points at SettingsProvider, the AOSP component that backs the settings databases. The Settings application itself lives in packages/apps/Settings in AOSP. That target is inference from the naming convention rather than a sourced fact: MediaTek publishes no manifest or documentation for this package, no package named MtkSettings appears anywhere in this site's sample, and which resource values a given firmware overrides is not published. Provenance is recorded rather than inferred, and it repeats the pattern this site already records for MediaTek components. The same package name appears across 37 device models from 19 makes, among them 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, so each is 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 12.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, which is an odd thing for a resource-only package to declare. The same entry is already noted on this site for com.mediatek.SettingsProviderResOverlay and com.mediatek.FrameworkResOverlayExt, and no sourced explanation for it was found. This site aggregates permissions across observations rather than per build, so which builds request it cannot be established here. Version note. Observations here run from API 31 to API 36, the target SDK roll-up reports 31 to 36, and version names run from 12 to 16, so within this sample the package has tracked Android 12 through Android 16 rather than belonging to one release. Those are independent roll-ups across observations rather than a per-build pairing. Nothing sourced indicates the package has been superseded, replaced or modularised at a particular Android release, and whether the values it overlays changed across those releases could not be sourced, so that is flagged here as an open question rather than answered. For Android Enterprise, EMM and kiosk use it plays no part in enrolment or management and exposes nothing a user interacts with, so an administrator normally meets it only in an app inventory. 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. Disabling it would leave its target running on unoverlaid defaults, 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 →
• packages/apps/Settings - Android platform source →
• Package provenance for com.mediatek.MtkSettingsResOverlay - 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.