com.qualcomm.uimremoteclient 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 two copies of Qualcomm's source for it in vendor trees published on GitHub by third parties: an older copy whose files carry Qualcomm copyright dates between 2014 and 2019, and a newer copy that adds files dated 2023. It describes those copies; what the builds recorded here contain could not be sourced. In the older copy it is a service through which an approved app can present a remote UIM card to the modem (the code counts these as SIM slots). Its interface file describes it as "the service which allows a client to make a remote UIM card available to the service". A client registers a callback, reports card events for a slot (connection available or unavailable, card inserted, removed, error, reset or wake-up, with a transport value of Bluetooth, IP or other), and returns the remote card's response to each command APDU the service passes it. The service relays these to a Qualcomm vendor radio HAL, vendor.qti.hardware.radio.uim_remote_client@1.0, with one instance per slot, and passes that HAL's indications back to the client's callback. The manifest declares only this one service, exported and guarded by the permission com.qualcomm.permission.UIM_REMOTE_CLIENT, which the same manifest defines without a protection level. Each interface method also checks the caller against an allow-list of package name and SHA-1 signing certificate fingerprint; that copy's list holds one entry, com.qualcomm.qti.uim_remote. The makefile builds the package with the platform certificate and skips it on low-RAM targets. Although it carries a Qualcomm name, it is shipped by device makers. It is recorded here on devices from Crosscall, Datalogic, Elo Touch Solutions, Fairphone, HMD Global, Nothing, OnePlus and Xiaomi. Where this site holds signer data, which is 5 of those 8 makes (Nothing, Fairphone, Crosscall, Xiaomi 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 one permission recorded here is READ_PRIVILEGED_PHONE_STATE, which is what the newer copy's manifest requests; the older copy's manifest requests READ_PHONE_STATE instead. This site aggregates permissions across observations rather than per build, so which builds request it 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 copies cited it rejects calls from an app that is not on its allow-list, so if the builds recorded here work the same way it would matter only on a device that uses a remote SIM arrangement through an allow-listed client app. Whether any device recorded here does, and what stops working if the package is disabled, could not be sourced, so the rating below is caution and any change should be tested on one device with a SIM in use first. Version note: the two copies differ. The older manifest uses the phone shared user ID and runs the service in the com.android.phone process; the newer manifest does neither. The newer copy also adds a factory class, dated 2023, whose comment says it "creates a HIDL or AIDL UimRemoteClient HAL instance": it selects an AIDL HAL where the board API level (or, where that is unset, the first product API level) is Android 14 or above and that HAL is declared, the HIDL HAL otherwise, and a "not supported" stand-in where it finds no cellular support. It is recorded here on devices between API 29 and API 36, and this site's roll-up reports version strings from 13 (oldest) to 15 (newest) and target SDK levels from 28 to 35. Those figures do not establish which copy, if either, a given recorded build matches.

• uim_remote_service client AndroidManifest.xml - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• uim_remote_service client Android.mk - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• uim_remote_service client applist.xml - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• IUimRemoteClientService.aidl - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• UimRemoteClientService.java - Sushrut1101/android_vendor_qcom_proprietary (GitHub) →
• uim_remote_service client AndroidManifest.xml, newer copy - aospa-op13/proprietary (GitHub) →
• UimRemoteClientFactory.java, newer copy - aospa-op13/proprietary (GitHub) →
• Package provenance for com.qualcomm.uimremoteclient - Android System App Database →

• Re-signed by each device maker with its own platform key - 6 different certificates appear across 5 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 signature or system-level. 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.