VoLTE regression in Infinity-X 3.10 on MTK Helio P22 (MT6769S) — MMTEL stuck at EMERGENCY_OVER_MMTEL despite carrier_volte_available=true and IMS PDN connecting

[achiya-automation]

VoLTE regression in Infinity-X 3.10 on MTK Helio P22 (MT6769S) — MMTEL stuck at EMERGENCY_OVER_MMTEL despite carrier_volte_available=true and IMS PDN connecting

Summary

After upgrading from Infinity-X 3.9 (2026-04-19 build) to Infinity-X 3.10 (2026-05-10 build), VoLTE stopped working on my QIN F22 Pro (MT6769S / Helio P22). Every outgoing/incoming voice call now performs CSFB to UMTS/HSDPA (3G) instead of staying on LTE via VoLTE. The exact same hardware, modem firmware, MTK IMS APK, carrier configuration, and Magisk modules worked perfectly on 3.9. The only change was the GSI upgrade.

Environment

Field	Value
ROM	Infinity-X 3.10 GSI (Infinity-X-3.10_GSI_treble_arm64-ab_GAPPS-Official-20260510.img.xz)
Last known working	Infinity-X 3.9 (Infinity-X-3.9_GAPPS_20260426)
Device	QIN F22 Pro
SoC	MediaTek Helio P22 (MT6769S)
Build fingerprint	QIN/full_AGN_1244RO_MT6769S_MX6432/AGN_1244RO_MT6769S_MX6432:12/SP1A.210812.016/1690270202:user/release-keys
Build ID	BP4A.251205.006 release-keys (Android 16)
Carrier	HOT mobile Israel (mccmnc 42507, carrier_id 1991)
IMS APK	PHH-resigned ims-mtk-u (SHA1 matches floss-ims-29-udp-resigned exactly)
Magisk	Yes, with f22pro_connectivity_fix module providing carrier_config override + IMS APN + props
PIF	Yes (PlayIntegrityFix v4.5-inject-s, Zygisk hooks only — verified not the cause; disabling did not help)

Reproduction

1. Flash Infinity-X 3.10 GSI on Helio P22 device with HOT mobile (or any carrier where VoLTE was previously working on 3.9).
2. Ensure carrier_volte_available_bool=true is loaded (via dumpsys carrier_config).
3. Ensure IMS PDN connects successfully — dumpsys connectivity shows the IMS network with MMTEL capability and a valid PcscfAddresses from the carrier.
4. Place an outgoing voice call.
5. Observe: getRilVoiceRadioTechnology drops from 14 (LTE) to 3 (UMTS); callTechnologies: [GSM]; data switches LTE → HSDPA for the duration of the call (classic CSFB).

Evidence

IMS service state:

addConnection, subId=2, type=MMTEL,
   state=UNAVAILABLE,
   capabilities = capabilities={ EMERGENCY_OVER_MMTEL }

MTK IMS (com.mediatek.ims/.MtkDynamicImsService) binds and reaches state=READY, hasConfig=true at the controller level, but the MmTel feature only reports the EMERGENCY_OVER_MMTEL capability. SIP REGISTER never happens.

Carrier config (HOT mobile, applied correctly):

carrier_volte_available_bool = true
carrier_vt_available_bool = true
carrier_volte_provisioned_bool = true
carrier_volte_provisioning_required_bool = false
volte_replacement_rat_int = 14
ignore_vops_changes_for_volte_replacement_bool = true
support_vops_when_combined_attach_bool = true
editable_volte_override_lte_capability_bool = true

Modem report (the actual blocker):

LteVopsSupportInfo : mVopsSupport = 2 mEmcBearerSupport = 2
NetworkRegistrationInfo: domain=CS transportType=WWAN accessNetworkTechnology=LTE
   availableServices=[VOICE,SMS,VIDEO]   ← Combined Attach (CSFB) accepted by network

IMS PDN (proves the carrier does accept IMS):

NetworkAgentInfo network{172} ni{MOBILE[LTE] CONNECTED extra: ims}
   InterfaceName: ccmni1
   PcscfAddresses: [ /10.101.227.102 ]
   Capabilities: IMS&...&MMTEL

So the IMS bearer comes up fine and the network allocates a P-CSCF. The framework simply doesn't drive SIP REGISTER because mVopsSupport=2 is interpreted as "no VoLTE", even though ignore_vops_changes_for_volte_replacement_bool=true is set.

SIM / subscription (HOT mobile is provisioned):

carrierId=1991 displayName=HOT mobile mcc=425 mnc=07
isEnhanced4GModeEnabled=1
isVideoTelephonyEnabled=1
isVoImsOptInEnabled=1
serviceCapabilities=7

Diff between 3.9 and 3.10 (extracted from both ROM images)

Decompressed both .img.xz files and compared /system/ contents. Only two framework jars changed:

File	3.9 SHA1	3.10 SHA1	Size delta
system/priv-app/TrebleApp/TrebleApp.apk	d93b3efe10...	d93b3efe10...	identical
system/framework/telephony-common.jar	8c6336b193...	d87b00f774...	+440 bytes
system/framework/ims-common.jar	bf9641f54a...	f2828af606...	differs

The telephony-common.jar delta is tiny (~440 bytes) and includes (among possibly other tiny changes) the new string persist.sys.phh.force_euicc_slots. This strongly suggests the regression is a small change in one of these two jars.

What was tried (none fixed it)

• Forced cmd phone ims disable → cmd phone ims enable (with subId 2 explicitly)
• am force-stop com.mediatek.ims + framework re-bind — MtkDynamicImsService rebinds but still reports only EMERGENCY_OVER_MMTEL
• Manually set vendor.ril.mtk_hvolte_indicator=1
• Set preferred_network_mode=11 (LTE_ONLY) — modem still performs Combined Attach (CS over LTE)
• Toggled airplane mode for fresh attach
• Two full reboots (so init.f22pro.rc + restore_volte.sh + carrier_volte_override.sh re-ran cleanly)
• Wiped /data/user_de/0/com.android.phone/files/carrierconfig* and imsprovisioningstatus_*.xml then rebooted to force fresh provisioning state
• Wiped /data/data/com.mediatek.ims/files/* and cache/*
• Enabled wfc_ims_enabled=1 as a fallback — carrier_wfc_ims_available_bool=false, so WFC didn't engage either
• Tried installing FlossIMS — blocked by sharedUserId="android.uid.system" signature mismatch on Infinity-X
• Temporarily disabled PIF — no change (confirms PIF Zygisk hooks aren't the cause)

Expected behavior

SIP REGISTER should be initiated and MTK IMS should report MMTEL VOICE capability, given that:

1. carrier_volte_available_bool=true
2. carrier_volte_provisioned_bool=true
3. ignore_vops_changes_for_volte_replacement_bool=true
4. The IMS PDN connects with a valid P-CSCF address
5. The same configuration works on 3.9 with no change to the carrier, SIM, IMEI, or modem firmware (vendor partition is untouched between GSI versions)

Ask

Could you check what changed in telephony-common.jar / ims-common.jar between 3.9 (2026-04-19) and 3.10 (2026-05-10)? Specifically anything touching:

• VoPS interpretation in ServiceStateTracker or DcTracker
• ImsPhone / ImsPhoneCallTracker capability gating
• The volte_replacement_rat_int / ignore_vops_changes_for_volte_replacement_bool path

Happy to provide additional dumpsys phone, dumpsys telephony.registry, dumpsys carrier_config, and full logcat -b radio traces if useful.

Thanks for maintaining this excellent project. 3.9 was rock-solid on Helio P22.

[achiya-automation]

Update — additional findings after 8 more hours of debugging on the same device

TL;DR: the modem-side path is salvageable only if a properly signed com.mediatek.ims ships in /system_ext of 3.10. PHH-resigning is not sufficient because the APK declares android:sharedUserId="android.uid.phone", which on Android requires the matching system signature. The signature on 3.10's platform key does not validate the PHH-resigned APK, so ImsResolver reports getImsServiceControllers: couldn't find any active ImsServiceControllers even after cmd phone ims set-ims-service -s 0 -c com.mediatek.ims returns true.

New evidence on top of the original report

1. MTK IMS signature mismatch (confirmed root cause for MMTEL never reaching READY+VOICE)

   pm path com.mediatek.ims
   → package:/data/app/~~EY0-NQZOCfakei946kQv8Q==/com.mediatek.ims-…/base.apk
   

   It's a /data/app install — i.e. the APK could not place itself in /system_ext/priv-app because it requires the platform signature. aapt dump xmltree confirms sharedUserId="android.uid.phone", which is exactly the case Android refuses to honour unless the APK is signed by the platform key (see AndroidPackageUtils#sharedUserId checks). Result: MtkDynamicImsService is declared but never bound by ImsResolver.

2. FlossIMS as an alternative is a partial workaround only
   With a Magisk module that places FlossIMS in /system_ext/priv-app, ships a matching privapp-permissions-me.phh.ims.xml, and overrides config_ims_mmtel_package_override_string=me.phh.ims, the framework does bind me.phh.ims.PhhImsService, capabilities flip to EMERGENCY_MMTEL+MMTEL, and SIP REGISTER actually completes (200 OK, P-Associated-Uri: <sip:+972…@ims.mnc007.mcc425.3gppnetwork.org>, full AKAv1-MD5 auth handshake with HOT mobile's Nokia P-CSCF at 10.101.227.102:6000). However:

   • The modem still performs Combined Attach because mVopsSupport=2, so an actual outgoing call drops the IMS bearer and CSFB takes over (getRilVoiceRadioTechnology goes 14 → 3 at INVITE time).
   • FlossIMS' upstream call-audio path crashes on missing librnnoise_jni.so and ships SDP that echoes the offer back rather than constructing a proper answer — both fixable in fork, neither fixed upstream.

3. 3.9 → 3.10 framework-jar deltas (re-checked)
   Confirmed again that only system/framework/telephony-common.jar and system/framework/ims-common.jar differ between 3.9 (2026-04-19) and 3.10 (2026-05-10). The telephony-common delta is ~440 bytes; strings on both jars shows the 3.10 build added persist.sys.phh.force_euicc_slots plus what looks like extra gating in the volte_replacement_rat_int path. If you can share the cherry-pick range between those two builds for frameworks_opt_telephony / frameworks_opt_net_ims, I can bisect locally on the device and report back which commit causes MMTEL to stay at EMERGENCY-only.

Ask (refined)

Two independent fixes, either of which would restore VoLTE for everyone on MediaTek devices running 3.10:

1. Bundle a properly-signed com.mediatek.ims in /system_ext/priv-app/MtkImsService/ of the GSI, signed with the 3.10 platform key. This is what 3.9 effectively had via a signature-compatible chain (the same PHH-resigned APK that fails to bind on 3.10 worked on 3.9).
2. Revert or guard the VoPS interpretation change in telephony-common.jar between 3.9 and 3.10, so ignore_vops_changes_for_volte_replacement_bool=true + volte_replacement_rat_int=14 actually bypasses the mVopsSupport=2 gate the way they did on 3.9.

Happy to run any extra dumps you want — dumpsys ims_resolver, dumpsys carrier_config -s 0, full logcat -b radio from cold boot through call placement, etc. Also happy to test a candidate ims-common.jar you want to bisect with — I have both 3.9 and 3.10 images already unpacked.

Thanks again for the project.