com.mediatek.capctrl.service Copy

Labelled "RilCap", this is a MediaTek platform component preinstalled on MediaTek-based devices. It has no launcher entry, no observation here is user-facing, and none is Play-eligible, so it is a non-launcher firmware component rather than an app anyone opens. This site records the label RilCap across the locales in its sample. The label and package name are most of what can be said about its job. RIL is the Radio Interface Layer, the telephony abstraction documented by AOSP, and "capctrl" reads as capability control, so the name places this on the modem and telephony side of a MediaTek build. What capability it controls, and on whose behalf, is not documented: MediaTek publishes no per-package documentation for it, and descriptions circulating on APK catalogues are not a basis for a claim. Treat the specific function as vendor-defined and firmware-specific rather than a documented fact. Two further details are recorded rather than inferred. Its aggregated permission set holds two entries, DEVICE_POWER and RECEIVE_BOOT_COMPLETED. The Android platform manifest describes the first as allowing low-level access to power management and marks it as not for use by third-party applications, and the second as allowing an application to receive the ACTION_BOOT_COMPLETED broadcast sent after the system finishes booting. This site aggregates permissions across observations rather than per build, so which builds request them cannot be established here. Builds are small, between roughly 61.9 KB and 66.0 KB. Provenance repeats the pattern this site already records for MediaTek components: the same package name appears across 19 device makes, including Xiaomi, Motorola, vivo, realme, TCL, Lenovo, Nothing, Infinix, Blackview, OUKITEL, Ulefone, Unihertz, Newland, CUBOT and NUU, under 12 distinct signing certificates, each classified here as the device maker's own key and each 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. Version note. Observations here run from API 29 to API 36, the oldest build by version code carries the version name 14 and the newest 16, and this site's target SDK roll-up reports 33 to 36. Those are independent roll-ups across observations rather than a per-build pairing, so they cannot be read as saying which target SDK any given device carries. Nothing sourced indicates the package has been superseded, replaced or modularised at a particular Android release, and whether its role has changed across releases could not be sourced, so that is flagged here as an open question rather than answered. For Android Enterprise, EMM and kiosk use, no enrolment or management role is identified in the sources cited here and it presents nothing to a user, so an administrator normally meets it in an EMM app inventory. Because it carries a platform-level signature, sits in the chipset vendor's namespace and requests RECEIVE_BOOT_COMPLETED in the aggregated sample, disabling it offers no clear benefit and could have chipset and firmware specific effects that could not be sourced. It is best left in place, and only touched with careful per-device testing that includes placing and receiving a call.

• RIL refactoring (Radio Interface Layer) - Android Open Source Project →
• core/res/AndroidManifest.xml (DEVICE_POWER, RECEIVE_BOOT_COMPLETED) - Android platform source →
• Package provenance for com.mediatek.capctrl.service - Android System App Database →

• Re-signed by each device maker with its own platform key - 12 different certificates appear across 8 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 2 permissions: 1 signature or system-level and 1 install-time. The signature/system share marks it as a privileged component, not an ordinary app.
• Never reported as user-facing, so it runs as a background or system component rather than an app the user opens.