Xiaomi 17 Pro Max (Popsicle) - Audio dropout during calls on 5G (EN-DC), works fine on 3G

[hsnyyldz]

Device: Xiaomi 17 Pro Max (Popsicle), Chinese ROM
Firmware: HyperOS 3.0, OS3.0.318.0.WPBCNXM (also tested on earlier builds, same behavior)
Carrier: Türk Telekom (Turkey)
Root status: Bootloader unlocked, rooted with Magisk (init_boot_a/init_boot_b patched)

Issue:
During regular phone calls, the earpiece audio cuts out completely after a variable amount of time (not fixed, ranges from a few seconds to a minute or more into the call). Switching to speakerphone immediately restores audio from the other party — but earpiece audio never comes back for the rest of that call.

What I've tested:
- Happens on every single call when the phone is on 5G (Preferred network type = 5G)
- Does NOT happen when I manually set Preferred network type to 3G/4G only
- Happens regardless of WiFi being on or off (tested with WiFi fully disabled, mobile data only)
- Voice network type shown in status = 4G (VoLTE), so calls are not using VoNR — Türk Telekom doesn't seem to have VoNR live yet
- Happens with earpiece grill clean, tested in Safe Mode (no third-party apps interfering), tested on different days/locations
- Reproducible: essentially every call while 5G is enabled

My working theory: this looks like an EN-DC (5G NSA dual connectivity) issue — the modem is maintaining simultaneous 5G NR data + 4G VoLTE voice bearer, and something in that dual-connectivity handling causes the audio path (not the call itself, call stays connected) to drop on the earpiece specifically, while speaker output is unaffected.

Has anyone else with this device (or other recent Xiaomi/Qualcomm SM8850 devices) on a 5G network seen this? Wondering if this is:
1. A baseband/modem firmware bug specific to this chipset's EN-DC handling
2. Something carrier-specific to networks that recently rolled out 5G (Türk Telekom went live with 5G on April 1, 2026)
3. A known HyperOS 3.0 audio routing bug

Any pointers to a modem firmware fix, a related bug report, or diagnostic steps (e.g. via *#*#4636#*#* or similar) to narrow this down further would be appreciated. Happy to pull logcat/modem logs if someone can point me to what to capture.

 

[Viking Hogar Strasni]

Its problem with provider sim card. I have same problem on Croatia A1

 

[DiogoAP]

Same bug here — Xiaomi 17 Pro Max (popsicle, 2509FPN0BC), Portugal, MEO,
dual SIM, same build as you: OS3.0.318.0.WPBCNXM.

Your description matches mine exactly, including the one detail that
convinced me we have the same fault rather than two similar ones:
switching back from speaker to earpiece does NOT restore earpiece audio.
The earpiece stays dead for the rest of that call. Only hanging up and
dialling again brings it back. That's specific and counter-intuitive, and
it's not something two people report by coincidence.

I instrumented my device and captured two failures plus four healthy calls
as controls, with verbose audio HAL logging:

setprop persist.log.tag.AHAL VERBOSE
setprop persist.log.tag.APM_AudioPolicyManager VERBOSE
setprop persist.log.tag.AudioFlinger DEBUG
adb logcat -G 64M

--------------------------------------------------------------------
WHAT THE LOGS SHOW
--------------------------------------------------------------------

Best-instrumented failure, 18:05, incoming call, SIM 2:

18:05:28.296 setMode(MODE_IN_CALL)
18:05:28.299 AHAL_Telephony_QTI: switchAudioMode: to AudioMode:IN_CALL
18:05:29.051 RadDeviceStateListener: audioReceiverState: 1 <- earpiece ON
18:05:32.308 *** last audio-stack log line of the entire call ***

--- 7 min 56 s with ZERO lines from AudioFlinger / APM / AHAL ---
--- earpiece goes silent somewhere in here ---

18:13:28.930 I tap SPEAKER
18:13:29.479 RadDeviceStateListener: audioReceiverState: 0
18:26:19.383 call ended (continued 13 min on speaker)

Two things stand out.

1) Android reports the earpiece as active for the entire silent period.
audioReceiverState logs exactly ONE "1" at call start and ONE "0" only
when speaker is tapped eight minutes later. Nothing in between.

2) The whole audio stack — AudioFlinger, AudioPolicyManager, the Qualcomm
and Xiaomi HAL layers — logs absolutely nothing while the audio dies.
No error, no reconfiguration, no device change. Total silence, with
verbose logging on.

--------------------------------------------------------------------
WHY SPEAKER->EARPIECE DOESN'T HELP
--------------------------------------------------------------------

Enabling speaker changes the RX device INSIDE the existing voice session.
The session is never restarted:

18:13:28.941 APM: selectBestRxSinkDevicesForCall() device
AUDIO_DEVICE_OUT_SPEAKER using HW Bridge
18:13:28.942 APM: updateCallRoutingInternal rxDevice
{AUDIO_DEVICE_OUT_SPEAKER} txDevice 0x80000080

Speaker works. Going back to earpiece re-issues the same configuration the
DSP accepted at call start, and produces no sound. The session is only torn
down at hangup:

18:26:19.372 AHAL_Telephony_QTI: updateCalls CallState: ACTIVE ->
INACTIVE vsid:VSID_2
18:26:19.372 AHAL_Telephony_QTI: stopCall: Enter
18:26:20.105 AHAL_Telephony_QTI: VoiceStop: Exit

Reading: the earpiece RX path inside the Qualcomm voice session enters a
stuck state. Re-selecting the earpiece within the session doesn't clear it.
Only a full stopCall / new session does. Nothing above the DSP notices,
which is exactly why the logs are empty.

--------------------------------------------------------------------
RULED OUT, WITH EVIDENCE
--------------------------------------------------------------------

Routing Telecom route stayed EARPIECE from ring to speaker tap.
No stream_devices_changed for STREAM_VOICE_CALL.
Volume STREAM_VOICE_CALL: Min 1, Max 11, earpiece: 11. At maximum.
Pressing volume-up produced no volume_changed event at all.
Thermal 33.9-34.0 C during the failure. Zero mitigation events.
Dialer app Google Phone issued no audio commands between answer and my
speaker tap. You reproduce it on a different dialer.
Third-party You reproduced it in Safe Mode.
Hardware Xiaomi's own CIT tool (*#*#64663#*#*) -> Receiver test
PASSES after a failure. Transducer and amp are fine.
Framework Setup trace is directly comparable to healthy calls:

| metric | failed | healthy |
| setPhoneState duration | 777 ms | 831 ms |
| setMode(IN_CALL)->receiver:1 | 755 ms | 594 ms |
| setCommunicationDevice re- | no | no |
| applied after IN_CALL | | |
| MR2SystemProvider "Could not | x2 | x2 |
| map ... route: 1" | | |
| final route | EARPIECE| EARPIECE|

Note that the MR2SystemProvider error and the ~800 ms setPhoneState appear
in HEALTHY calls too. They are normal for incoming calls on this device.
If you've been treating either as a symptom, they aren't.

--------------------------------------------------------------------
ON YOUR 5G / EN-DC THEORY — I HAVE TO BE HONEST
--------------------------------------------------------------------

My logs do not confirm it. I want to say that plainly rather than pile on
agreement:

- Voice was LTE/VoLTE (networkType=13) on EVERY call, failed and healthy.
No VoNR anywhere, same as you.
- My healthy calls had MORE EN-DC availability than the failed one:
59 and 31 samples versus 27.
- In one of my two failure windows there were ZERO radio events of any kind.
- Mid-call at 18:07:35 I had NR re-added + PhysicalChannelConfig changed +
a RIL anomaly logged, and the earpiece did NOT fail. That's a direct
counter-example inside the same call that later failed.

I also checked the radio anomalies people tend to quote. They're real:

RILJ: Invalid PhysicalChannelConfig
java.lang.IllegalArgumentException: Physical cell ID 65535 is over limit
AnomalyReporter: RIL reported invalid PCC (AIDL) (21 occurrences)
"Unsupported band type" / "Unsupported unknown band" (519 occurrences)

PCI 65535 (0xFFFF) is an invalid sentinel, so the modem is genuinely
reporting garbage and that's worth reporting on its own. But all 21
Invalid PhysicalChannelConfig events land at call setup/teardown INCLUDING
on healthy calls, and also with no call active at all. NONE falls inside
either failure window. The band warnings are continuous background noise.
Unhealthy modem stack, yes. Trigger for this bug, the data says no.

One more caution: in my first failure, the RIL anomaly and the EN-DC burst
appear 60-70 ms AFTER I took the phone from my ear. Taking the phone away
turns the screen on, which triggers a network state refresh. So radio
events cluster at the moment you react to the failure BECAUSE you react.
That's a confound worth avoiding in this thread.

Your controlled result — fails every call on 5G, never on 3G/4G — is much
stronger evidence than anything I can extract retrospectively. I'm going to
replicate it before drawing conclusions, and I'd suggest we make that the
thread's focus.

--------------------------------------------------------------------
PRE-EMPTING THE "CUSTOM ROM" OBJECTION
--------------------------------------------------------------------

I'm on xiaomi.eu with an unlocked bootloader and NO root at all — no su
binary on the device. You're on Magisk. Different unlock method, different
root state, identical bug. Root is not a factor.

More importantly, xiaomi.eu only rebuilds system and system_ext. On my
device the vendor and odm partitions carry the untouched stock fingerprint:

vendor -> Xiaomi/popsicle/popsicle:16/BQ2A.250705.001-BP2A.250605.031.A3/
OS3.0.318.0.WPBCNXM:user/release-keys
vendor build date: Tue Aug 4 15:26:59 CST 2026

The audio HAL and the Qualcomm voice path live there:
/vendor/lib64/hw/audio.primary.default.so, AHAL_Module_QTI,
AHAL_Telephony_QTI, AHAL_Telephony_MI.

Combined with the log evidence that the framework layer behaves identically
in working and failing calls, the failure sits in stock, signed, unmodified
Xiaomi vendor code. The ROM I'm running does not touch it.

--------------------------------------------------------------------
TWO QUESTIONS
--------------------------------------------------------------------

1) Which ROM exactly are you on — official Chinese, or xiaomi.eu? You wrote
"Chinese ROM" and it matters a lot. If you're on the official ROM, that
closes the loop: same vendor blobs, two different ROMs, same bug, and
nobody can wave this away as a modding artefact.

It also matters practically. My bootloader is unlocked, so Service &
Feedback discards my reports before a human sees them. If you're on the
official ROM, yours actually enter Xiaomi's pipeline — and I'd gladly
hand you my full write-up and raw logs to attach.

2) Has anyone here run the A/B properly? Several long calls locked to
LTE-only, then the same on 5G, changing nothing else. That single test
settles the EN-DC question either way and costs nothing. One confirmed
failure while forced to 4G kills the theory outright.

--------------------------------------------------------------------
IF YOU WANT TO CONTRIBUTE DATA
--------------------------------------------------------------------

adb shell "setprop persist.log.tag.AHAL VERBOSE; \
setprop persist.log.tag.APM_AudioPolicyManager VERBOSE; \
setprop persist.log.tag.AudioFlinger DEBUG"
adb logcat -G 64M # re-run after every reboot, persist.logd.size is
# SELinux-denied on this device
# after a failure, within ~30 minutes:
adb logcat -b all -d > fail.txt
# and if you're still in the call:
adb shell dumpsys audio > fail_audio.txt

Grep markers: audioReceiverState, AHAL_Telephony_QTI, setCommunicationDevice,
updateCallRoutingInternal, Entering audio route.

The single most diagnostic line is audioReceiverState. If it reads 1
throughout a period when you hear nothing, the failure is below the HAL and
everything above is behaving normally.

Full write-up with all timestamps attached.

 

[DiogoAP]

Update — I ran the A/B and it does NOT hold on my device.

Locked both SIMs to LTE-only via:
cmd phone set-allowed-network-types-for-users -s 0 1011101001110000111
(NR bit removed, everything else untouched.) Verified with the get- command
immediately before and after the failure.

It failed anyway, ~24 s into the call. Zero "isEnDcAvailable = true" samples
in the entire call log. So on my hardware this is not EN-DC related.

Two more things died with it:
- It was an OUTGOING call, so it isn't tied to the RINGTONE -> IN_CALL
transition either.
- setPhoneState took 233 ms, the fastest of any call I've measured (others
were 777-831 ms). It still failed, so the slow setPhoneState isn't the
trigger.

Since your result is so clean and mine is the opposite, I think the honest
reading is that we may have the same symptom from different causes, or the
5G correlation on your side is coincidental. Worth you re-running yours a few
more times to be sure.

One thing that IS strengthening on my side: all three of my failures were on
SIM 2 (VSID_2 in the Qualcomm voice session). All my long SIM 1 calls are
clean. Small sample, but I'm testing it next.

Are you dual SIM? If so, which slot do the failing calls use?

 

[DiogoAP]

Update on my side — I ran the 5G A/B and it does NOT hold here.

I locked both SIMs to LTE-only by removing only the NR bit:

cmd phone set-allowed-network-types-for-users -s 0 1011101001110000111

Verified with the get- command immediately before and after. It failed anyway,
~24 s into the call, with zero "isEnDcAvailable = true" samples in the whole
call log. So on my hardware this isn't EN-DC.

Two other things died with that same test:
- It was an OUTGOING call, so it isn't tied to the RINGTONE -> IN_CALL
transition.
- setPhoneState took 233 ms, the fastest of any call I've measured (the others
were 777-831 ms). Still failed. So the slow setPhoneState isn't it either.

I'm not saying your result is wrong — yours is a clean controlled observation
and mine is the opposite. Either we have the same symptom from different
causes, or one of the correlations is coincidental. Worth you re-running yours
a few more times to be sure it holds.

What's strengthening on my side is different, and I'd really like to know if it
applies to you.

All three of my failures were on the SIM that does NOT carry mobile data:

slot 0 MEO (personal) = my data SIM -> 3 long calls, all fine
slot 1 UZO (work) = non-data SIM -> 3 calls, all 3 failed

Not an exposure artefact: slot 1 failed at 24 s and 30 s, while slot 0 calls of
69 s, 72 s and 171 s were clean — two to seven times longer than the time it
takes slot 1 to fail.

The mechanism that would explain it: with "use mobile data during VoLTE calls
on the secondary SIM" DISABLED (mine was at 0), a VoLTE call on the secondary
slot forces the modem to suspend and switch the DDS. It's visible in the logs:

PhoneSwitcher: Qti Legacy or Smart temp DDS call_state_change

A call on the data SIM itself needs no such switch. That lines up exactly with
which of my calls fail.

I've now ENABLED that setting to see whether removing the temp-DDS switch
changes anything. Testing over the next few days.

So, three questions for you:

1. Are you dual SIM? If so, which slot do the failing calls use, and which slot
carries your mobile data? If yours also fail on the non-data SIM, that's a
much better lead than 5G for both of us.

2. What is "use mobile data during VoLTE calls on the secondary SIM" set to on
your device? Mine was OFF.

3. If you're single SIM and it still fails — that kills my theory outright, and
I'd genuinely rather know now than chase it for a week.

Also, two red herrings I burned time on, in case they show up in your logs:
MR2SystemProvider "Could not map this selected device attribute type" and a
~800 ms setPhoneState. Both appear in my HEALTHY calls too. They're normal on
this device, not symptoms.

 

[DiogoAP]

Update from my side — I found something that stops it, and it narrows the fault
considerably. Also a correction to one of my earlier posts.

--------------------------------------------------------------------
DISABLING VoLTE STOPS IT
--------------------------------------------------------------------

I disabled VoLTE on both SIMs. Since then:

~42 answered calls over two days
earpiece used on almost all of them
ZERO forced switches to speaker

My baseline before that was roughly 3 failures in 6 qualifying calls. At that
rate I would have expected around ten failures in this sample. There were none.

I checked that the test was actually testing something, because this caught me
out once already: there is no ImsPhoneCallTracker activity and no
networkType:13 anywhere in the two-day capture. The calls genuinely went over
the CS voice path, not IMS.

The metric I counted is stream_devices_changed [0,1,2] — STREAM_VOICE_CALL
moving from earpiece to speaker. That line appears every single time the
earpiece dies and I am forced to switch. Zero occurrences in two days. The only
voice-route changes were to and from Bluetooth, which is normal car use.

So: the earpiece, the amplifier, the codec and the DSP are identical in both
cases. The only variable is which voice path the modem uses. The fault is in
the IMS voice path and not in the CS voice path.

--------------------------------------------------------------------
HOW TO DISABLE IT PROPERLY
--------------------------------------------------------------------

The MIUI code *#*#86583#*#* did NOT work on my device. It sets the user
preference, which the carrier configuration then overrides. Only the per-SIM
toggle in Settings produced a real change.

Verify before trusting any result:

adb shell "dumpsys activity service com.android.phone | grep -oE 'volteEnabled=[a-z]+ +volteEnabledByUser=[-0-9]+'"

You want volteEnabled=false on every subscription. "VolteEnabledByPlatform =
true" will still show — that is the hardware capability, not the effective
state, and it is not a contradiction.

Cost: calls fall back to 3G/2G, so narrowband audio, slower setup, and no
VoWiFi. Check what your network actually drops to.

--------------------------------------------------------------------
CORRECTION TO MY EARLIER POST
--------------------------------------------------------------------

The non-DDS SIM correlation I posted is WRONG. Please ignore it.

I had the subId-to-slot mapping backwards. Subscription IDs are per-device
database row IDs, not slot indices — on my second unit subId 2 maps to slot 0,
the opposite of my first unit. Once I checked properly, that failure had
occurred on the SIM that DOES carry mobile data.

Everything else I chased is dead too, each with evidence:

5G / EN-DC failed with NR disabled and zero EN-DC present
SIM slot fails on both slots
Carrier fails on both of my carriers (MEO and UZO)
Data SIM fails on the data SIM and on the non-data SIM
Dialer app fails with Google Phone and with Xiaomi's own dialer
Device unit reproduces on a second Xiaomi 17 Pro Max
Call direction fails on incoming and outgoing
Earpiece HW Xiaomi's own CIT Receiver test passes right after a failure

VoLTE is the first variable that changed the outcome.

--------------------------------------------------------------------
A HYPOTHESIS WORTH TESTING, AND IT COSTS NOTHING
--------------------------------------------------------------------

Look at what you and I have in common:

me China-market device -> Portugal, MEO and UZO
you China-market device -> Turkey, Türk Telekom

Neither of us is using the device in the market it was built for, and neither
of our carriers is Chinese.

Carrier configuration lives on the device, indexed by MCC/MNC. A China-market
build carries profiles built around Chinese MCCs. If there is no profile for
our carriers, the device falls back to generic IMS parameters — and generic IMS
parameters are exactly the kind of thing that could produce subtly wrong
behaviour in the IMS voice path, which is where we have now localised the
fault.

This makes a clear prediction:

Anyone using this model IN CHINA on a Chinese carrier should NOT have this bug.

That is free to test and it decides between two very different explanations:

- A universal firmware defect, affecting everyone including users in China
- An interaction between generic carrier configuration and the IMS voice
path, affecting only those of us using the device outside its home market

It would also explain why a defect this reproducible has not shown up at scale
on a phone sold in volume.

You can check your own with:

adb shell "dumpsys carrier_config | grep -oE 'Phone Id = [0-9]+|Config from default app|Config from carrier app|carrierId=[0-9-]+'"

If it says "default app", you are running generic config.

--------------------------------------------------------------------
TWO QUESTIONS
--------------------------------------------------------------------

1) Is there anyone here using a Xiaomi 17 Pro Max in China, on a Chinese
carrier, who has seen this? Or, better, anyone who uses it heavily on the
earpiece and has NEVER seen it? A confirmed negative from China is worth
more than anything else in this thread right now.

2) You wrote "Chinese ROM" earlier — do you mean the official Chinese ROM, or
xiaomi.eu? It still matters. I am on xiaomi.eu with an unlocked bootloader,
and Xiaomi support has used that to dismiss my reports three times. If you
are on the official ROM, your report reaches their pipeline in a way mine
cannot.

Also, if you try the VoLTE change, please report the call count either way. A
confirmed failure with VoLTE off would kill my finding, and I would rather know
that now than believe it for a month.

 

[DiogoAP]

I'm currently running the official Chinese HyperOS 4 (Android 17), version OS4.0.0.44.XPBCNXM, and the issue still persists.

However, the behaviour has changed.

Previously, whenever the earpiece stopped working during a phone call, the only way to restore audio was to end the call and make a new one.

Now, when the earpiece stops working, I can restore it simply by switching to speakerphone and then switching back to the earpiece. The audio immediately returns.

I strongly suspect that this issue may be related to the fact that the Xiaomi 17 Pro Max was never officially released globally.

My theory involves the TAC (Type Allocation Code), which consists of the first eight digits of the IMEI and identifies the device's manufacturer and model.

Since the Xiaomi 17 Pro Max was designed primarily for the Chinese market, international mobile network operators may not have fully tested, certified, or provisioned this particular model for their networks.

This could potentially lead to compatibility issues with VoLTE (Voice over LTE) and IMS (IP Multimedia Subsystem), particularly if the device's modem configuration or carrier profiles are not fully compatible with the local network.

However, the fact that switching between speakerphone and earpiece immediately restores audio also suggests a possible software-level audio routing issue within HyperOS.

It would be interesting to investigate whether this is caused by a HyperOS audio routing bug, a modem firmware issue, or an incompatibility between the device's IMS configuration and international mobile network operators.

Either way, this is clearly an issue that Xiaomi needs to investigate and address.