Hello all,
I successfully installed 7.5 last week on my Fairphone 4 using the described method to update from 6.X to 7.X using adb. Everything appeared to be working until I noticed, that I cannot make or receive any calls.
Everything worked perfectly fine until the update.
TL;dr:
- Carrier Yallo (Switzerland) on Sunrise network
- APNs are all set correctly. I reverted to default, double checked
- VoLTE is activated → tried with on or off
- Wi-Fi Calling is activated –> tried with on or off
- Preferred network type is 5G –> tried with LTE only
- *#*#4636*#*#** returns, that IMS is not registered (this appears to be the main issue)
I can receive SMS and 5G data works.
I made a bug report using Claude, who helped me crawl through the logs.
Summary
After upgrading my Fairphone 4 from iodéOS 6.x to 7.5 (locked bootloader, sideloaded the OTA in recovery per documented procedure, which performs a factory reset and Seedvault restore), I lost the ability to make or receive voice calls. SMS and mobile data still work. Diagnostics show that org.codeaurora.ims is installed and bound to com.android.phone, but no MmTelFeature is ever activated: no NetworkRequest with NET_CAPABILITY_IMS is ever created, the IMS APN’s PDN is never brought up, and no SIP REGISTER ever leaves the device. IMS Service Status reports “Not Registered”. Same symptoms as @iode-1520 reported on Galaxus / Sunrise here (post #19).
This matters in Switzerland because Sunrise shut down 3G at the end of 2025, so no VoLTE = no calls.
Environment
-
Device: Fairphone 4
-
ROM: iodéOS 7.5 (clean install from 6.x last week via
adb sideloadin recovery + factory reset + Seedvault restore — the documented path for locked bootloaders) -
Bootloader: locked
-
Carrier: Yallo (MVNO on Sunrise, CH) — MCCMNC 228 02, ICCID prefix 89410
-
Network: registered REG_HOME on LTE/LTE_CA, bands 3 and 20,
isVopsSupported = true
Symptoms
-
Outgoing/incoming calls fail (no ring, drop after ~30 s)
-
SMS works
-
5G/LTE data works
-
*#*#4636#*#*→ Phone Information → IMS Service Status: IMS Registration: Not Registered -
VoLTE worked perfectly on iodéOS 6.x with the exact same SIM until the upgrade
What I’ve already ruled out
-
Not stale state from 6.x. Locked bootloader meant the upgrade required a factory reset; this is effectively a clean 7.5 install with only a Seedvault app/data restore on top. The IMS stack is failing on a freshly initialized system.
-
Not a SIM/carrier whitelisting issue. Network reports
lteVopsInfo = {isVopsSupported = true, isEmcBearerSupported = true}on every registration update. Yallo is offering VoLTE; the device just never tries to register. -
Not an APN issue. After
Reset to default, both APNs are present and clean (UNEDITED):Sunrise Internet(default/supl/hipri, IPv4) andIMS(type ims, IPv6 home / IPv4v6 roaming). -
Not a carrier-config issue.
com.android.carrierconfigmatched the SIM (carrier ID 1413, cached XML restored) and appliedcarrier_volte_available_bool = true,carrier_wfc_ims_available_bool = true, fullims.*settings populated. -
Not a missing/disabled IMS APK.
org.codeaurora.imsis installed in/system_ext/priv-app/ims/, enabled (PRIVILEGED, SYSTEM_EXT), and bound tocom.android.phone(verified viadumpsys activity services org.codeaurora.ims—requested=true received=true hasBound=true, process record 2785 running for 7+ minutes). -
All Qualcomm IMS daemons are alive.
imsqmidaemon,imsdatadaemon,imsrcsd,ims_rtp_daemon,com.qti.phone,qtidataservices,com.android.imsserviceentitlement— all in process list.
What’s actually broken
Despite all of the above, the IMS stack is silent:
-
service listshows onlytelephony_ims: [android.telephony.ims.aidl.IImsRcsController]— no MMTEL binder. -
cmd imsreturns “Can’t find service: ims”. -
dumpsys connectivityhas noNetworkRequestwith id=4 (NET_CAPABILITY_IMS) anywhere in the system. -
dumpsys telephony.registryshows only one activePreciseDataConnectionState: the defaultSunrise InternetPDN. The IMS APN never gets a PDN. The active PDN haspcscf = [](expected for the internet APN; relevant because no IMS PDN ever comes up to learn P-CSCF from). -
44-second
logcat -b allwindow (covering several radio events including cell reselection band 3 → band 20, PDN state transitions, RILJ messages) contains zero log lines fromImsService,MmTelFeature,ImsResolver(fororg.codeaurora.ims),Volte,cscf, orregister— the IMS service is bound but doing literally nothing. -
org.codeaurora.imsprocess state:S (sleeping)for the full session.
Hypothesis
org.codeaurora.ims as shipped in iodéOS 7.5 for FP4 binds at the AIDL level but its handshake with the Lineage 23 / Android 15+ telephony framework never results in MmTelFeature creation. Therefore no IMS NetworkRequest is published, no IMS PDN is requested from the data layer, and no SIP registration is ever attempted.
Likely related to the framework’s ImsResolver expecting capability declarations or feature metadata that this build of org.codeaurora.ims (carried over from the FP4 stock firmware blobs originally targeting an older Android version) doesn’t publish in the new framework’s expected form. RCS appears to bind separately and works at the framework controller level, but MMTEL — the part that does VoLTE — does not activate.
This is consistent with @iode-1520’s report and with rik’s earlier note about APN regressions between Lineage 22 and 23, although in my case the APNs themselves are clean — the regression for me is one layer deeper, in IMS service activation.
Key diagnostic excerpts
dumpsys carrier_config (Phone 0):
carrier_volte_available_bool = true
carrier_wfc_ims_available_bool = true
carrier_volte_provisioning_required_bool = false
ims.* settings populated
dumpsys telephony.registry after fresh APN reset:
mPreciseDataConnectionStates={Pair{1 [ApnSetting] Sunrise Internet, 6305, 22802, internet, ...,
supl | hipri | default, IP, IP, ..., UNEDITED}= state: CONNECTED, ...,
pcscf: [], ...}
mPreciseDataConnectionStates={} ← second slot empty, no IMS PDN ever attempted
dumpsys activity services org.codeaurora.ims:
ServiceRecord{...} org.codeaurora.ims/.ImsService c:com.android.phone
app=ProcessRecord{... 2785:org.codeaurora.ims/u0a130}
Bindings: requested=true received=true hasBound=true
service list | grep -i ims:
250 telephony_ims: [android.telephony.ims.aidl.IImsRcsController]
(No MMTEL binder; no vendor imsrtpservice / imscallservice / similar registered.)
logcat -b all filtered for IMS-related tags over 44 s window covering boot and several cell reselections: zero matches from org.codeaurora.ims.
Modem-side, from RILJ:
DATA_REGISTRATION_STATE: REG_HOME, LTE_CA, ...,
lteVopsInfo = {isVopsSupported = true, isEmcBearerSupported = true}
What I’d appreciate
-
Confirmation whether anyone else on iodéOS 7.5 FP4 + Swiss carriers (Sunrise, Salt, Swisscom, or MVNOs of those) currently has working VoLTE — to narrow whether this is FP4-specific, Sunrise-specific, or both.
-
Pointer to anything I can try short of rolling back to 6.x or switching ROMs — e.g. is there a known fix in iodé’s pipeline, or a way to force the framework to (re-)bind to
org.codeaurora.imswith the MMTEL feature? -
If this is a known regression, an ETA on a fix would help with deciding whether to wait or switch.
Happy to provide more dumps (full dumpsys carrier_config, full logcat -b all around boot, dumpsys telephony.ims equivalents, etc.) on request.
Thanks and happy sunday! 
If the provider doesn’t know what to do with that information, at least make sure they do an “IMEI check” to verify it is eligible for registration on their network. That would clarify “is the hardware allowed?” (step 1)
Falls der Anbieter nicht weiß, was er mit diesen Informationen anfangen soll, stellen Sie zumindest sicher, dass er eine „IMEI-Prüfung“ durchführt, um zu überprüfen, ob das Gerät für die Registrierung in seinem Netz zugelassen ist. Damit wäre geklärt: „Ist die Hardware zugelassen?“ (Schritt 1)