1. Small correction to one paragraph above. I overstated “IMS service doing literally nothing.” More precisely:
-
The framework’s
ImsPhonewrapper is alive and processes events — for example, it handles SS messages for call forwarding setup (which works for me, falling back to control-plane signaling since IMS isn’t available). -
However
Phone-0: getImsRegistrationTechnology = -1(REGISTRATION_TECH_NONE) on every query. -
No
ImsService/MmTelFeature/ImsResolverlog lines fororg.codeaurora.ims, no SIP REGISTER, no IMS PDN.
So the gap is specifically between ImsPhone and the MMTEL layer below it: the framework wrapper is in place and asking, the IMS service is bound, but the IMS service never reports back a registered MMTEL feature.
2. Important cross-device data point. Another user on the same carrier (Yallo CH) running the same ROM (iodéOS 7.5) on a Fairphone 6 has fully working VoLTE / IMS registration. Combined with @iode-1520’s matching report on FP4 + Galaxus (also Sunrise MVNO) + iodéOS 7.x, this cleanly isolates the bug to the FP4 build of iodéOS 7.5 — not a general iodéOS 7.5 / Lineage 23 regression, and not a Yallo / Sunrise account issue.
The most likely interpretation: FP4’s org.codeaurora.ims and its supporting vendor blobs (carried over from FP4 stock firmware originally targeting an older Android version) don’t satisfy the new framework’s IMS service contract in the way the FP6’s newer Qualcomm IMS implementation does. FP6 ships newer blobs and “just works”; FP4 inherits the older ones and the framework can’t get a working MMTEL feature out of them.