com.mediatek.telephony Copy

Its English label is "Telephony Assist", with localised equivalents in other locales such as Telefonie-Hilfe, Asistente de telefonía and Телефонный помощник. It is a MediaTek platform component in the chipset vendor's com.mediatek namespace, 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. The label and package name are most of what can be said about its job. No MediaTek documentation for it was found in research for this note, and the descriptions circulating on APK catalogues are not a basis for a claim, so its specific function should be treated as vendor-defined and firmware specific rather than a documented fact. Its aggregated permission set holds three entries: READ_PRECISE_PHONE_STATE, READ_PRIVILEGED_PHONE_STATE and RECEIVE_BOOT_COMPLETED. The Android platform manifest describes the first as read-only access to precise phone state for special-use applications such as diallers, carrier applications and IMS applications, with a protection level of signature or privileged, and the second as read access to privileged phone state, used internally, with a protection level of signature, privileged or role. The third allows an application to receive the broadcast sent after the system finishes booting. Those are read-side telephony permissions: the set recorded here contains no permission to modify phone state or to open network sockets. What it does with the state it can read is not documented in the sources cited here. This site aggregates permissions across observations rather than per build, so which builds request them cannot be established. Provenance repeats the pattern this site records for other MediaTek components: the same package name appears across 19 device make names, including Xiaomi, Motorola, TCL, OPPO, vivo, realme, Nothing, Infinix, OUKITEL, Ulefone, Unihertz, Blackview, CUBOT, Newland and NUU. Among the observations that carry signing data, 13 distinct certificates are recorded, each classified 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 34 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 privileged telephony permissions and RECEIVE_BOOT_COMPLETED in the aggregated sample, disabling it offers no clear benefit and could have chipset and firmware specific effects on telephony 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, sending an SMS and using mobile data.

• core/res/AndroidManifest.xml (READ_PRECISE_PHONE_STATE, READ_PRIVILEGED_PHONE_STATE, RECEIVE_BOOT_COMPLETED) - Android platform source →
• Package provenance for com.mediatek.telephony - 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 3 permissions: 2 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.