com.qualcomm.qti.telephonyservice Copy

A Qualcomm-named system component with no label of its own: it is recorded here under its package name in each locale recorded, and has no launcher entry in any observation recorded here. No Qualcomm documentation for it was found. The description below comes from a copy of Qualcomm's source for it (QtiTelephonyService) in a vendor tree published on GitHub by a third party, whose files carry Qualcomm copyright dates of 2014 and 2017. It describes that copy; what the builds recorded here contain could not be sourced. In that copy it does two jobs. The first is an interface that, in the words of its interface file, exists "to make apis accessible to downloadable clients", beginning with user authentication APIs that let clients generate keys "by Generic Bootstrapping Architecture(GBA) based on AKA protocol". It has three methods: one returns the interface version, one runs the GBA bootstrapping procedure for a given SIM slot and card application, and one reads a value the file calls the IMPI. The implementation sends these requests to the Qualcomm radio interface layer (RIL) through Qualcomm's qcrilhook library. The manifest defines two permissions at protection level signatureOrSystem: com.qualcomm.qti.permission.USE_QTI_TELEPHONY_SERVICE, needed to bind to the service, and com.qualcomm.qti.permission.ACCESS_USER_AUTHENTICATION_APIS, which the implementation enforces on the two authentication methods. The second job concerns audio. When the service is created it registers, for each SIM slot, with a Qualcomm vendor radio HAL, vendor.qti.hardware.radio.am@1.0 IQcRilAudio, and gives it a callback through which that HAL can set and read audio parameters using Android's AudioManager. It also reports to that HAL when the audio server goes down or comes back. The manifest uses the phone shared user ID and marks the application persistent and direct-boot aware, and a boot receiver starts the service on the boot-completed and locked-boot-completed broadcasts if it is not already running. The makefile builds the package with the platform certificate and skips it on builds without telephony. Although it carries a Qualcomm name, it is shipped by device makers. It is recorded here on devices from CipherLab, Crosscall, Datalogic, Elo Touch Solutions, Fairphone, HMD Global, HONOR, isafemobile, Motorola, Nothing, OnePlus, Xiaomi and Zebra Technologies. Where this site holds signer data, which is 7 of those 13 makes (Fairphone, Motorola, Nothing, Xiaomi, Crosscall, isafemobile and HMD Global), each copy is signed by that maker's OEM key, a key that also signs the Android framework, a platform-level key. The four permissions recorded here are INTERACT_ACROSS_USERS, MODIFY_AUDIO_ROUTING, MODIFY_AUDIO_SETTINGS and RECEIVE_BOOT_COMPLETED. The cited manifest requests the last two together with com.qualcomm.permission.USE_QCRIL_MSG_TUNNEL, and not the first two, so at least one recorded build differs from that copy. This site aggregates permissions across observations rather than per build, so which builds request them cannot be established. For Android Enterprise, EMM and kiosk use no enrolment, policy or management role for it is identified in the sources cited here. In the copy cited it is a persistent component under the phone shared user ID that the RIL audio HAL can call back into and that permitted clients can use for GBA key generation. If the builds recorded here work the same way, disabling it would remove both. Which calling, audio or carrier features that would affect on a given device could not be sourced, so the rating below is caution and any change should be tested on one device with a SIM in use, including a voice call. Version note: it is recorded here on devices between API 28 and API 36, and this site's roll-up reports version strings from 13 (oldest) to 16 (newest) and target SDK levels from 28 to 35. Those figures do not establish how the package has changed. The cited manifest targets SDK 28, the lowest target level in that roll-up, and the permissions recorded here differ from it as described above. What changed between that copy and later builds, and whether its role differs on current Android releases, could not be sourced.

• QtiTelephonyService AndroidManifest.xml - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• QtiTelephonyService Android.mk - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• IQtiTelephonyService.aidl - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• QtiTelephonyServiceImpl.java - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• QtiTelephonyService.java - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• QcRilAudio.java - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• BootReceiver.java - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• Package provenance for com.qualcomm.qti.telephonyservice - Android System App Database →

• Re-signed by each device maker with its own platform key - 8 different certificates appear across 7 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 4 permissions: 2 signature or system-level and 2 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.