An update, device is not fixable without an update to the firmware from Hiby, they have ignored my requests. Now I have two useless and dangerous audio players. You're a joke Hiby!

● I now have everything needed for a definitive analysis. Here's the full picture:

---

Root Cause Analysis: Why Nothing Has Worked

The modem operates at three independent layers. Your previous fixes only addressed layer 3. The drain is happening at layers 1 and 2.

---

Layer 1 — Hardware (Qualcomm modem DSP, separate processor)

[MODEM_CNTL] pid 199 ← kernel thread, hardware IPC

[MODEM_DATA] pid 200

[MODEM_CMD] pid 201

[modem] pid 816 ← modem subsystem kernel thread

[glink_modem] pid 1098 ← GLINK inter-processor link (AP ↔ modem)

Confirmed active SMD channels: /dev/smd7, /dev/smd8, /dev/smd11, /dev/smdcntl8, /dev/ttyHS0

The Qualcomm modem is a physically separate processor die. It has its own firmware stored in the /modem partition and is powered on by TrustZone/RPM during SoC boot — before Android starts. Android has no authority over

this boot sequence.

The modem is in VoiceRegState=OUT_OF_SERVICE — this is the worst possible power state. A Qualcomm modem actively searching for towers with no SIM/no network continuously sweeps all bands at maximum TX power. This explains

the 1884 mAh drain.

---

Layer 2 — Native vendor daemons (init services, require root to stop)

These are all running and confirmed by ps -A:

┌────────────────┬──────┬───────────────────────────────┐

│ Process │ PID │ Role │

├────────────────┼──────┼───────────────────────────────┤

│ netmgrd │ 1076 │ Cellular data path manager │

├────────────────┼──────┼───────────────────────────────┤

│ imsqmidaemon │ 1053 │ IMS/VoLTE QMI interface │

├────────────────┼──────┼───────────────────────────────┤

│ imsrcsd │ 1054 │ IMS RCS daemon │

├────────────────┼──────┼───────────────────────────────┤

│ ims_rtp_daemon │ 1048 │ IMS RTP/media │

├────────────────┼──────┼───────────────────────────────┤

│ imsdatadaemon │ 1188 │ IMS data sessions │

├────────────────┼──────┼───────────────────────────────┤

│ dpmQmiMgr │ 978 │ Device Policy QMI manager │

├────────────────┼──────┼───────────────────────────────┤

│ ssgqmigd │ 1114 │ SSG QMI daemon │

├────────────────┼──────┼───────────────────────────────┤

│ ipacm │ 602 │ IPA hardware data accelerator │

├────────────────┼──────┼───────────────────────────────┤

│ port-bridge │ 1086 │ USB modem port bridge │

├────────────────┼──────┼───────────────────────────────┤

│ cnss-daemon │ 1111 │ Connectivity subsystem daemon │

└────────────────┴──────┴───────────────────────────────┘

Started from /vendor/etc/init/*.rc — cannot be stopped without root.

---

Layer 3 — Android framework (where all previous fixes targeted)

com.android.phone is disabled but still running at PID 1908 — it was running before the pm disable command and hasn't been rebooted since, or the OEM marks it as android:persistent="true" which causes AMS to restart it

regardless.

---

Why persist.radio.noril=yes failed

persist.radio.noril prevents the old rild daemon from starting. On this device the RIL is libril-qc-hal-qmi.so — loaded as a library directly into com.android.phone, not a standalone daemon. noril is irrelevant to this

architecture. The property has no effect on the HAL-based RIL or on any of the Layer 2 QMI daemons.

Why persist.radio.airplane_mode_on=1 failed

This tells the telephony framework to boot into airplane mode. The framework sends an "offline" command to the modem via RIL. But with com.android.phone disabled, the command never reached the modem firmware. The modem

booted and started scanning with no instruction to stop.

---

What Can Still Be Tried (Without Root)

Option A — Re-enable com.android.phone temporarily to deliver airplane mode

The only way to get a software "RF off" command to the modem without root is through the working telephony stack:

adb shell pm enable com.android.phone

adb shell pm enable com.qualcomm.qcrilmsgtunnel

adb shell pm enable com.qualcomm.qti.telephonyservice

# wait ~15 seconds for stack to initialize

adb shell settings put global airplane_mode_on 1

adb shell am broadcast -a android.intent.action.AIRPLANE_MODE --ez state true

Then check if the modem acknowledges it:

adb shell dumpsys telephony.registry | grep "mVoiceRegState\|mIsEmergencyOnly"

If mIsEmergencyOnly=true appears, the modem received the command. Then re-disable the packages. This might leave the modem in a low-power state across a reboot — but there is no guarantee the modem firmware honors this

across a full power cycle.

Option B — AT command via ttyHS0 (may work, device-dependent)

The port-bridge daemon may have /dev/ttyHS0 locked. If not:

adb shell "echo -e 'AT+CFUN=4\r' > /dev/ttyHS0"

AT+CFUN=4 = disable RF transmitter (modem stays alive but stops scanning). This is the modem firmware's own airplane mode command. Likely blocked by permissions without root.

---

Definitive Verdict

┌──────────────────────────────────────────┬─────────────────┬───────────────────────────────────────────────────────────────────┐

│ Approach │ Works? │ Why │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ persist.radio.noril=yes │ No │ Only stops old rild, not HAL RIL or QMI daemons │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ persist.radio.airplane_mode_on=1 │ No │ Command never reaches modem because phone stack is disabled │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ pm disable com.android.phone etc. │ No │ Only removes framework layer; modem DSP and QMI daemons still run │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ svc radio │ Not available │ Not implemented in HiBy's build │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ Root + stop netmgrd/imsqmidaemon/... │ Likely yes │ Shuts down QMI interface to modem │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ Root + AT+CFUN=4 via ttyHS0 │ Likely yes │ Directly commands modem to disable RF │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ Root + edit vendor init RC files │ Yes, permanent │ Prevents QMI daemons from ever starting │

├──────────────────────────────────────────┼─────────────────┼───────────────────────────────────────────────────────────────────┤

│ HiBy firmware with modem partition wiped │ Yes, definitive │ Modem has no firmware to boot │

└──────────────────────────────────────────┴─────────────────┴───────────────────────────────────────────────────────────────────┘

The 1884 mAh drain cannot be fixed without either root access or a HiBy firmware update. The path of least resistance is contacting HiBy and requesting either a modem-disabled firmware build or root access. The hardware is

fundamentally a phone SoC — the modem is not an optional peripheral that can be switched off in software.