HyperOS 3 Telemetry: How Xiaomi Reports Your Installed Apps

On October 31, 2026, a security researcher using the handle MeTerminator666 documented an incident that is becoming common for users in mainland China. An acquaintance with a rooted Xiaomi 14 running domestic HyperOS 3 firmware got a phone call from local public security officers telling them to uninstall X and Telegram.

In a case like this, the usual suspect is the network layer: a misconfigured proxy client, a split-tunneling rule that lets UDP port 53 traffic reach the local ISP resolver, an IPv6 route that bypasses the virtual interface, or a TLS SNI trigger on the carrier backbone. The Xiaomi 14 was rooted and had strict traffic routing rules, so the researcher ruled out a VPN or DNS leak and examined the host operating system instead.

That investigation, together with an October 13, 2026 forensic teardown of a Redmi K90 Ultra running HyperOS 3.0.306 by independent researcher ChrisLi-Tech, shows how host-level telemetry works on domestic Chinese Android builds. If the privileged layer of the OS inventories, packages and exfiltrates the user environment, the list of installed foreign apps is gone before any traffic reaches a virtualized tunnel interface. Users who inspected a Xiaomi 17 Pro Max later verified the same components, so this is firmware-wide behavior. The telemetry runs through two privileged subsystems: a carrier-mandated device management agent (com.mobiletools.systemhelper) and Xiaomi’s internal behavioral risk and anti-fraud engine, which is split between com.miui.guardprovider and the Xiaomi Security Open Framework (XSOF) inside com.miui.securitycenter.

To follow how these parts work, you have to look past the consumer privacy toggles and into the partition layout, Binder IPC bindings, SQLite persistence layers and Xiaomi’s own developer SDK documentation. None of the packages involved is third-party malware. They are platform-signed system services in /system/priv-app/, running under elevated UIDs and backed by hardware-level trust verification.

Why a VPN or proxy cannot hide installed apps on HyperOS 3

On stock Android, ordinary apps run in isolated SELinux sandboxes under their own user IDs, typically in the u0_aXXX range. Android 11 (API level 30) added package visibility filtering, so a normal app can no longer call PackageManager.getInstalledPackages() or getInstalledApplications() to list everything on the device. It needs specific <queries> elements in its manifest or the QUERY_ALL_PACKAGES permission.

Privileged system apps in /system/priv-app/ or /product/priv-app/ live under a different security model. They are signed with the OEM’s platform key or exempted through the priv-app allowlist in /etc/permissions/. Packages such as com.miui.securitycenter, com.miui.guardprovider and com.mobiletools.systemhelper run either as system (UID 1000) or with privileged permissions that include QUERY_ALL_PACKAGES, PACKAGE_USAGE_STATS, READ_PRIVILEGED_PHONE_STATE and REAL_GET_TASKS.

A proxy client on Android usually creates a virtual interface (tun0) through the VpnService API. On a rooted phone it may instead edit iptables or nftables chains and policy routing tables (ip rule) to push outbound packets to a local transparent proxy daemon. Privileged system services can get around either setup in two ways.

First, ConnectivityManager lets processes holding CONNECTIVITY_INTERNAL or NETWORK_STACK bind sockets directly to a physical interface, such as the cellular rmnet_data0 or wlan0, using Network.bindSocket(). That ignores the default tun0 VPN route.

Second, many domestic proxy configurations deliberately bypass split tunneling for domestic IP ranges (geoip:cn), carrier domains and Xiaomi system domains (*.miui.com, *.xiaomi.com, *.wo.com.cn), so that push notifications, system updates and carrier VoLTE provisioning keep working. When a system daemon uploads an inventory of foreign apps to a domestic endpoint, the proxy client sends it straight onto the domestic ISP backbone, uninspected and unencrypted.

SystemHelper (com.mobiletools.systemhelper): carrier-level app reporting

The first part of the HyperOS 3 reporting pipeline is com.mobiletools.systemhelper, labeled simply “SystemHelper” in the system interface. Consumer forums often take it for a SIM activation utility or an OTA configuration helper. Static and dynamic analysis says otherwise. Academic work on eastern Android distributions, such as the 2023 arXiv study Android OS Privacy Under the Loupe, and the October 2026 Xiaomi 14 teardown both identify it as a carrier device management (DM) and registration SDK, built to meet Chinese telecom regulatory mandates.

Package enumeration and usage correlation

SystemHelper runs periodic background jobs against PackageManager and UsageStatsManager. Through UsageStatsManager.queryUsageStats() it tallies every app with foreground or background activity in the last 24 hours. It also lists all installed packages, skipping any package name that starts with com.android.

That one string filter says something about intent. Dropping com.android.* removes baseline AOSP components such as com.android.settings, com.android.systemui and com.android.phone, which keeps the payload small and puts the focus on third-party software and OEM additions. The component then cross-references the filtered list with NetworkStatsManager (or /proc/net/xt_qtaguid/stats and eBPF traffic counters on modern kernels) to tie each app UID to its traffic volume and usage timestamps.

IMEI, IMSI and ICCID: tying the app list to a real identity

An app inventory only helps law enforcement or regulators if it can be tied to a physical handset and a real person. China requires real-name registration (实名制) for every cellular SIM, so binding an app list to a SIM links the software environment to a government ID.

SystemHelper does this through TelephonyManager, using READ_PRIVILEGED_PHONE_STATE, a permission normal third-party apps cannot get on modern Android. Its serialized payload carries these identifiers next to the 24-hour usage log:

• IMEI (International Mobile Equipment Identity): the 15-digit hardware identifier burned into the modem NVRAM, which identifies the physical Xiaomi handset across cellular networks.
• IMSI (International Mobile Subscriber Identity): the 15-digit subscriber number stored on the SIM (MCC + MNC + MSIN), which maps directly to the subscriber’s account in the carrier’s Home Location Register (HLR) or Unified Data Management (UDM) core.
• ICCID (Integrated Circuit Card Identifier): the 19-to-20-digit serial number of the physical SIM or eSIM profile.

Combined with the non-AOSP package inventory and the 24-hour traffic metrics, the IMEI, IMSI and ICCID leave no ambiguity about who is using the device or which apps generated network activity.

The dm.wo.com.cn endpoint and the MCC 460 trigger

Once serialized, SystemHelper sends the payload to dm.wo.com.cn:18080/register. Academic literature documents parallel carrier endpoints such as China Mobile’s a.fxltsbl.com, and Xiaomi’s own fraud engines receive data as well. The domain wo.com.cn is the official portal of China Unicom (中国联通), and the dm subdomain is its Device Management platform.

The service uses plaintext HTTP on TCP port 18080 rather than HTTPS on 443. That is a holdover from legacy carrier CoAP/HTTP device management specifications, where carrier edge routers inspect or terminate traffic inside the telecom intranet. Over Wi-Fi, it leaves the payload readable to any network observer in between.

Reverse engineering shows a specific condition on execution. The daemon reads the Mobile Country Code (MCC) from the active SIM slot through TelephonyManager.getSimOperator() or getNetworkOperator(), and the reporting routine runs only when the MCC is 460, the ITU country code for the People’s Republic of China. With a foreign SIM (MCC 310 for the United States, 404 or 405 for India), the check fails and the carrier reporting path stays dormant.

The package itself stays in /system/priv-app/, though, with its BOOT_COMPLETED, CONNECTIVITY_CHANGE and SIM_STATE_CHANGED receivers registered in the system manifest. When a mainland Chinese SIM goes in, or when a user on a China Mobile SIM triggers the unified DM SDK, the receiver wakes the service and it sends the telemetry payload to dm.wo.com.cn:18080/register.

com.miui.guardprovider: Xiaomi’s System Security Component

SystemHelper handles carrier-side registration and usage tallying. The second package from the Xiaomi 14 investigation, com.miui.guardprovider, is labeled “System Security Component” (系统安全组件) and acts as an active content and application inspection engine. It began as a wrapper for antivirus definitions (engines from Avast, Tencent or AVL) used to scan sideloaded APKs at install time. In HyperOS 3 it also does continuous application provenance reporting and real-time multimodal anti-fraud detection.

Package provenance and signing certificate auditing

SystemHelper looks at package names and usage duration. com.miui.guardprovider pulls full structural metadata from every third-party app on the phone. For each installed APK it parses AndroidManifest.xml and queries PackageManager with the GET_SIGNING_CERTIFICATES flag (or the legacy GET_SIGNATURES). The report it builds contains:

• Package name (applicationId): the Java-style identifier, such as org.telegram.messenger or com.twitter.android.
• Application display label: the localized name under the launcher icon.
• Version name and version code: the exact build numbers of the installed binary.
• Cryptographic signature digests: the SHA-1 or SHA-256 hash of the developer’s X.509 signing certificate, taken from the APK signing block (v1 JAR signature or the v2/v3 APK Signature Scheme).
• Manifest structure and scan verdicts: declared permissions, exported components and local heuristic classifications such as “fake app” or “risk app” flags.

Collecting the signature digest next to the package name defeats a common evasion trick: repackaging a banned app (a proxy client like Clash or v2rayNG, or Telegram) under a random package name with a different launcher icon. Say a user recompiles an open-source client as com.example.calculator. If they reuse a known signing key, or the manifest component tree matches known heuristics, the digest and the manifest report still reveal what the binary is. And if someone sideloads the official X or Telegram APK from an overseas mirror, the developer certificate digest proves that exact foreign app is on the device.

com.miui.guardprovider sends these reports over HTTPS to two Xiaomi security endpoints:

• fraud-detection.engine.miui.com/hyperos/fraud/app/report
• flash.sec.miui.com/detect/app

The second endpoint also ties into Xiaomi’s fid (device fingerprint ID) anti-tampering architecture, which lets the receiving server verify that the report really came from that handset and was not spoofed. After the October 31, 2026 disclosure, filter list maintainers on repositories such as uBlockOrigin/uAssets quickly opened issues to block fraud-detection.engine.miui.com under privacy rules. DNS-level blocking on an unrooted phone does little, since system processes bypass user-space resolvers.

The ephemeral screen recording pipeline

The most intrusive capability found in com.miui.guardprovider during the Xiaomi 14 work is its cloud-based visual and audio risk detection pipeline. It was built to fight telecom and social-engineering fraud over ordinary cellular calls, Tencent QQ and WeChat (微信) VoIP sessions, and its code can capture live audio transcriptions, upload raw audio feedback and record the physical display.

Static analysis of the screen recording routine shows a tight capture-and-upload loop with these parameters:

Because com.miui.guardprovider is a privileged system component, it never has to show the standard Android MediaProjection consent dialog (“Start recording or casting with…?”) that ordinary screen recorders must trigger. It can create an internal system screen recording object, or a virtual display surface through SurfaceControl / DisplayManager, using the CAPTURE_VIDEO_OUTPUT or READ_FRAME_BUFFER permissions.

The encoder is hardcoded to portrait 720 × 1280 at 24 frames per second. A continuous multi-minute recording would eat storage and show up as disk I/O spikes, so the recorder cuts the stream into MP4 segments of about 3 seconds each in the app’s private cache directory. When a segment is finalized, a worker thread reads the file into memory, encodes the bytes as Base64, wraps them in an encrypted payload and sends it to Xiaomi’s cloud detection servers.

The state machine then blocks until the cloud returns a verdict. If the server-side computer vision or OCR model finds no fraudulent UI pattern or blacklisted content, the daemon deletes the temporary MP4, waits 2 seconds and starts the next 3-second recording. If the cloud flags a match, the daemon keeps one MP4 clip locally for user feedback and evidence, shows a system-level fraud warning overlay and stops the recording service.

Since non-matching segments are deleted every five seconds (3 seconds of capture plus a 2-second delay), the service leaves almost no forensic trace on flash storage. Meanwhile, a near-real-time visual feed of the screen can go to remote servers whenever a trigger condition, such as an active VoIP call or a financial or sensitive app session, is met.

Xiaomi Security Open Framework (XSOF) and fraud_detection_data.db

The Xiaomi 14 analysis exposed the outbound payloads of SystemHelper and guardprovider. The October 13, 2026 forensic analysis by ChrisLi-Tech on a Redmi K90 Ultra running HyperOS 3.0.306 covered the other half: the local persistence and inter-app distribution layer that ties Xiaomi’s anti-fraud ecosystem together, the Xiaomi Security Open Framework (XSOF).

Working from a temporary KernelSU root shell (uid=0(root)) with SELinux kept in Enforcing mode so native behavior stayed unaltered, the researcher audited running system services with dumpsys activity services and dumpsys package. Xiaomi’s main system management app, com.miui.securitycenter (Phone Manager / 手机管家), turned out to spawn a persistent process named com.miui.securitycenter.remote under the privileged system UID (1000). That process hosts two services and two content providers:

• com.xiaomi.security.xsof.MiSafetyDetectService
• com.xiaomi.security.xsof.frauddetection.service.MiFraudDetectionService
• FraudDetectionProvider
• XSOFProvider

The local behavioral database

MiFraudDetectionService does not just pass events around in memory. It keeps a persistent, regularly updated SQLite database in a protected system directory that normal users cannot reach:

/data/misc/user/0/securitycenter/fraud_detection_data.db

Opened read-only with sqlite3, the database shows six behavioral logging tables:

• screenshot: every display capture event across the operating system.
• screen_share: screen mirroring, casting and virtual display recording sessions.
• install_app: package installation events, source installers and risk classifications.
• fraud_phone: incoming and outgoing cellular calls involving international prefixes or flagged numbers.
• fraud_url: URLs accessed or scanned that match anti-fraud heuristics.
• voip_record: voice-over-IP call sessions inside third-party communication apps.

Static decompilation of the com.miui.securitycenter APK reveals the SQL schema that creates the screenshot table, including a developer typo in the column name screenshort_time (an extra “r” in “screenshot”):

sql

CREATE TABLE screenshot(
    _id INTEGER PRIMARY KEY AUTOINCREMENT,
    screenshort_time INTEGER NOT NULL
);

Each time the user takes a screenshot anywhere on the phone, whether in a web browser, Bilibili, a banking app or the system settings, a system listener catches the media creation event and inserts the exact Unix epoch timestamp in milliseconds (screenshort_time) into fraud_detection_data.db.

Declining the privacy policy does not stop the logging

One of the worst findings in the HyperOS 3.0.306 audit concerns how MiFraudDetectionService treats consent. On domestic Xiaomi ROMs, opening com.miui.securitycenter (Phone Manager) brings up a privacy policy agreement dialog. Wary users often decline, assuming that refusal switches off the Security Center’s background data collection.

ChrisLi-Tech tested that assumption by refusing the policy in the Phone Manager UI. While the “Awaiting Privacy Policy Agreement” screen was showing, the researcher took a screenshot of that very screen (saved as Screenshot_2026-10-13-16-57-05...jpg) and then queried the database directly from a root terminal:

bash

SQL=/data/data/com.termux/files/usr/bin/sqlite3
DB=/data/misc/user/0/securitycenter/fraud_detection_data.db
"$SQL" -readonly "$DB" "SELECT datetime(screenshort_time/1000,'unixepoch','localtime') FROM screenshot ORDER BY screenshort_time DESC LIMIT 10;"

The query returned 2026-10-13 16:57:05, the exact second the screenshot of the refusal dialog was taken. The consent toggle in the com.miui.securitycenter UI is therefore decoupled from the MiFraudDetectionService daemon running in com.miui.securitycenter.remote. After an explicit opt-out, the UID 1000 background service keeps intercepting system events and writing behavioral records to fraud_detection_data.db.

Cleanup routines in the APK also hardcode a retention and query window of 259200000 milliseconds (exactly 72 hours). Three days of behavioral telemetry stay queryable on disk even if the user later deletes screenshots, clears call logs or uninstalls an app.

How Xiaomi exposes behavioral telemetry to third-party apps

Why keep a local 72-hour SQLite database of screenshots, screen shares, VoIP sessions and app installs inside com.miui.securitycenter.remote? Xiaomi’s own HyperOS Developer Platform answers this under “Security Open Services: Device Fraud Detection” (安全开放服务 / 设备涉诈检测), in specifications published in April 2026 (pId=2243 and pId=2255).

Xiaomi built XSOF (com.xiaomi.security.xsof.service.version=3) as more than an internal OS warning system. It works as a local behavioral data broker that commercial third-party apps can query directly on the device, in two tiers:

• Basic service (涉诈风险分评估 API): returns a composite fraud risk score from 0 to 100 (as a float string), produced by Xiaomi’s internal temporal chain model and signed with a SHA-256 hash and verification token.
• Advanced service (获取涉诈行为元数据 API): aimed at large enterprises such as banks, e-commerce platforms, payment processors and social networks that run their own risk-control algorithms. Instead of Xiaomi’s score, it lets third-party apps pull raw behavioral metadata as nested key-value JSON across 7 time intervals (timestampTypes) and 4 duration thresholds (durationTypes), looking back up to 72 hours (259,200,000 ms).

What third-party apps can query through the XSOF API

Xiaomi’s official API schema (pId=2243) lists the behavioral keys exposed to authorized partner apps. When a partner app calls the Current or Preceding Fraud Behavior Detection APIs, XSOF returns 0, 1 or 3 flags across a long list of user actions:

json

{
  "data": {
    "airplaneMode": { "0": 0, "1": 0, "2": 0, "3": 0, "4": 0, "5": 0, "6": 0 },
    "callForwarding": { "0": 0, "1": 0, "2": 0, "3": 0, "4": 0, "5": 0, "6": 0 },
    "conferenceApp": { "0": 3, "1": 3, "2": 3, "3": 3, "4": 3, "5": 3, "6": 3 },
    "financialApp": { "0": 3, "1": 3, "2": 3, "3": 3, "4": 3, "5": 3, "6": 3 },
    "riskApp": { "0": 1, "1": 0, "2": 0, "3": 0, "4": 0, "5": 0, "6": 0 },
    "suspiciousApp": { "0": 1, "1": 0, "2": 0, "3": 0, "4": 0, "5": 0, "6": 0 }
  },
  "authenticity": {
    "hash": "82d1854695454a2074477be350b82f89d404837c0cb63d8968a90de49b44136c",
    "token": "xxxxxxxx"
  }
}

The behavioral flags documented in Xiaomi’s SDK specifications include:

• riskApp (risk application installation): flags whether the user tried to install an app that the code-scanning engine identified as carrying risk signatures. Xiaomi’s documentation defines it to cover malware and criminal fraud apps, and also “device modification and root tools (改机root工具) and automated scripting tools (自动化脚本工具).”
• suspiciousApp and unclassified apps (无法区分类型的App安装): flags whether the user installed an APK while offline (sideloading cut off from the network to avoid cloud checks) or installed an app missing from Xiaomi’s domestic “ecological base table” (生态基表). That catches sideloaded foreign APKs such as X, Telegram or overseas VPN clients.
• financialApp and conferenceApp: track installs of banking, crypto and asset trading, credit and cloud video-conferencing software. The documentation notes: “Even after the user uninstalls the app within the valid time window, it will still register a hit (有效时间内卸载后依然命中).”
• screenSharing, callForwarding, airplaneMode, SIM/VoIP calls and AI face-swap detection: show whether the user took screenshots, shared the screen, toggled airplane mode or made flagged calls over the past 72 hours.

Silent permission grants and live Binder connections

In standard Android design, access to sensitive device state needs either a dangerous runtime permission, which shows an Allow/Deny prompt, or a signature permission reserved for the OEM’s own apps.

Xiaomi lets commercial apps reach XSOF without alerting the user by defining the custom permission com.xiaomi.security.permission.ACCESS_XSOF in the system manifest with protectionLevel=normal. Android grants normal-level permissions at install time with no prompt, so any third-party app that declares <uses-permission android:name="com.xiaomi.security.permission.ACCESS_XSOF" /> in its manifest silently gets binding rights to Xiaomi’s anti-fraud service.

Running dumpsys package on a live HyperOS 3.0.306 system during the October 2026 audit showed 16 commercial apps already holding ACCESS_XSOF: granted=true. They include major Chinese social, e-commerce and navigation platforms: Xiaohongshu (小红书 / com.xingin.xhs), Baidu Tieba (贴吧), Douyin (抖音), Alipay (支付宝), Taobao (淘宝), Xianyu (闲鱼), JD.com (京东) and Amap (高德地图).

These apps do more than declare the permission. dumpsys activity services showed an active Binder connection from Xiaomi’s Xiaohongshu client (com.xingin.xhs v9.49.2, UID 10350 / u0a350) to MiSafetyDetectService inside com.miui.securitycenter while the app was running:

ServiceRecord{... com.miui.securitycenter/com.xiaomi.security.xsof.MiSafetyDetectService c:com.xingin.xhs}
  intent={act=com.xiaomi.security.xsof.SAFETY_DETECT_SERVICE pkg=com.miui.securitycenter}
  recentCallingPackage=com.xingin.xhs
  recentCallingUid=10350
  isBindService=true
  Bindings:
    IntentBindRecord{... CREATE}
      requested=true received=true hasBound=true doRebind=false
      Client AppBindRecord{... ProcessRecord{... com.xingin.xhs/u0a350}}

The researcher then decompiled Xiaohongshu’s base.apk (21 primary DEX files, 2 secondary DEX files and 164 native ARM64 .so libraries) to find which XSOF method codes it invokes: 004_2 for historical behavior queries including screenshot history, 004_3 for behavior duration, and 004_4 for risk scores. No XSOF interface string appeared in plaintext in the DEX bytecode or the native symbol tables. The app opens a live Binder IPC session to com.xiaomi.security.xsof.SAFETY_DETECT_SERVICE at runtime and hides the invocation logic behind string encryption, reflection or dynamic code loading.

Hardware-backed attestation with Qualcomm QSEE and mrm

The obvious countermeasure for a rooted user is to hook the Java framework with Zygisk/LSPosed and feed fake “0” values to MiFraudDetectionService, or to edit the SQLite database directly. Static analysis of XSOF inside com.miui.securitycenter shows that Xiaomi anchored the framework in the hardware Trusted Execution Environment (TEE).

When XSOF processes behavioral queries or generates its authenticity signature token, execution routes through com.xiaomi.trustservice, which calls the proprietary vendor HAL interface vendor.xiaomi.hardware.mrm. Decompiled native libraries show direct calls into Qualcomm’s Secure Execution Environment (QSEE / TEE) and checks of Android Verified Boot (ro.boot.vbmeta.device_state), SELinux enforcement status and the usual root artifacts.

The authenticity token in the XSOF JSON response is signed or attested through the TEE and verified against Xiaomi’s backend servers. Tampering with the local Java service on an unlocked bootloader therefore risks invalidating the hardware attestation signature, which tells both Xiaomi and the querying third-party app that the device environment is compromised.

HyperOS 3 telemetry stack: how the subsystems fit together

On a domestic Xiaomi handset, the three subsystems overlap like this:

How an X or Telegram install reaches local authorities

When you trace how an X or Telegram install reached local authorities, the three layers overlap so much that little is left to chance. Even if all app traffic goes through an encrypted proxy tunnel, com.mobiletools.systemhelper still lists the non-AOSP packages and sends them, with the handset’s IMEI and the SIM’s IMSI and ICCID, to carrier management servers.

At the same time, com.miui.guardprovider hashes the APK’s signing certificate and reports the install to fraud-detection.engine.miui.com. MiFraudDetectionService logs the install event (flagged as an unclassified foreign app or a root/modification tool) in fraud_detection_data.db, where up to 16 everyday domestic commercial apps can query the behavioral flags over Binder IPC and pass them into their own analytics pipelines.

How to harden a Xiaomi device against HyperOS 3 telemetry

For engineers and security practitioners trying to harden a domestic Xiaomi device, every standard fix comes with serious limits.

Unrooted ADB debloating

On a non-rooted phone you can run adb shell pm uninstall -k --user 0 com.mobiletools.systemhelper or pm disable-user --user 0 com.miui.guardprovider. That removes SystemHelper and guardprovider from the active user profile (user 0), but the base APKs stay in the read-only /system or /product partitions. OTA updates or background guard routines in com.miui.securitycenter can re-enable them.

You also cannot uninstall or disable com.miui.securitycenter, home of MiFraudDetectionService and XSOF, on HyperOS without causing a bootloop. Xiaomi couples the Security Center APK tightly to core Android framework hooks, battery management and permission controllers.

Root-level hooking with Magisk, KernelSU and LSPosed

On a rooted handset you can use a systemless overlay in Magisk or KernelSU to blank out /system/priv-app/SystemHelper and GuardProvider, or deploy LSPosed modules (such as community-built AppListUploadBlocker hooks) to intercept PackageManager queries and block outbound requests to fraud-detection.engine.miui.com. It turns into a permanent cat-and-mouse game, for three reasons.

First, unlocking a bootloader on mainland China HyperOS now requires passing strict Xiaomi community account level checks and real-name verification, which itself records that the user is modifying the device.

Second, XSOF’s riskApp detector specifically scans for root tools (改机root工具), and its integration with com.xiaomi.trustservice and vendor.xiaomi.hardware.mrm (Qualcomm QSEE/TEE) exposes root artifacts and broken Verified Boot chains at the hardware trust layer.

Third, if an LSPosed module fails to hook obfuscated or dynamically loaded native JNI calls inside com.miui.securitycenter.remote, fraud_detection_data.db keeps filling silently in the background.

Replacing the firmware or separating hardware

The only deterministic way to remove privileged OS-level telemetry from an Android handset is to remove the domestic vendor firmware. A clean, verifiable AOSP build (such as LineageOS or GrapheneOS on supported hardware) drops the proprietary /system/priv-app/ daemons and the ACCESS_XSOF framework modifications, and restores the standard Android sandbox guarantees.

Where custom ROMs are impossible because the bootloader is locked, the original researchers’ recommendation stands: do not install sensitive foreign apps or censorship-circumvention tools on domestic Android firmware, and keep strict hardware separation between devices holding domestic SIM cards and apps and devices used for external communications.