Being the middle man between ChatGPT and the Command Window I get a front row seat to witness his bumping around. My observations lead me to believe that AIs just bump around until they either hit a dead end, in which case they start off in a different direction, break something, in which case they start off in a different direction, or actually fix something, in which case everyone gets all excited saying how incredibly intelligent they are. Normally, no one sees all of the bumping around but, as I mentioned, being the AI’s cut-and-paste meat servant, I get to see it first hand.
Now forward. I had the AI look into the log files as I attempted a phone call using the Moto with your GIS. Here is its latest report after studying the log file. Hope this helps. Let me know if you have any recommendations of what I should have the AI do next. I’m not knowledgeable enough to recommend possible avenues of investigation.
Absolutely. I’d give Colors a concise technical report that separates observed runtime evidence from the stock-vs-GSI comparison, and avoids suggesting that individual files should simply be copied.
Moto g-2026 /e/OS Android 16 GSI — IMS/VoLTE Diagnostic Report
Device: Motorola Moto g-2026, XT2613-1 (nevada)
SoC: MediaTek MT6835
Carrier: T-Mobile
OS: /e/OS 4.3-a16-20260821-Unofficial-GSI
Android: 16
Objective
Determine why cellular data works on the /e/OS Android 16 GSI but voice calls do not, and identify what is missing from the GSI’s IMS/VoLTE implementation.
Current behavior
The T-Mobile SIM is recognized correctly and cellular data works on the /e/OS GSI.
However, outgoing voice calls fail immediately after reaching the DIALING state.
The same T-Mobile service works normally on the user’s Pixel 8.
Clean call-log evidence
ADB was used to capture a clean logcat. The log was cleared immediately before making one test call.
The call reaches DIALING, then Android reports:
CallsManager: markCallAsDisconnected:
disconnectCause=DisconnectCause [
Code: (ERROR)
Reason: (CM_SER_UNAVAILABLE, ERROR_UNSPECIFIED)
Tone: (27)
TelephonyCause: 36/-1
ImsReasonInfo: null
]
The same disconnect reason is recorded again immediately afterward:
SET_DISCONNECTED
DisconnectCause [
Code: (ERROR)
Reason: (CM_SER_UNAVAILABLE, ERROR_UNSPECIFIED)
TelephonyCause: 36/-1
ImsReasonInfo: null
]
The Dialer repeatedly reports:
ImsVideoCall.isAvailable - null video call
There are also messages showing that Android’s telephony framework is attempting to manage the connection through its IMS conference machinery.
Most importantly, the log contains no IMS registration/service-state information and no useful ImsReasonInfo from an actual IMS connection.
Runtime IMS service test
The following command was run on the running GSI:
adb shell dumpsys ims
Result:
Can't find service: ims
This indicates that the normal Android ims Binder service is not registered on the running system.
Installed-package test
The following command was run:
adb shell pm list packages | grep -Ei 'ims|mediatek|mtk'
Relevant results were:
package:com.android.imsserviceentitlement
package:me.phh.treble.overlay.mtkims_telephony
package:me.phh.treble.overlay.flossims_telephony
package:me.phh.treble.overlay.cafims_telephony
package:me.phh.treble.overlay.hwims_telephony
package:me.phh.treble.overlay.slsiims_telephony
package:me.phh.treble.overlay.sprdims_telephony
Notably absent is:
com.mediatek.ims
The stock Motorola firmware contains this package as:
/system_ext/priv-app/ImsService/ImsService.apk
with:
package: com.mediatek.ims
versionCode: 36
versionName: 16
The application’s main IMS service is:
com.mediatek.ims.MtkDynamicImsService
and its manifest declares:
MMTEL_FEATURE=true
RCS_FEATURE=true
EMERGENCY_MMTEL_FEATURE=true
Stock-vs-GSI IMS framework comparison
The stock Motorola firmware contains a substantial MediaTek/Motorola IMS implementation that is absent from the GSI.
Stock /system
Stock contains:
/system/framework/ims-common.jar
/system/framework/moto-ims-ext.jar
/system/framework/moto-telephony.jar
/system/framework/telephony-common.jar
and associated optimized/runtime files.
Stock /system_ext
Stock contains:
/system_ext/framework/mediatek-ims-base.jar
/system_ext/framework/mediatek-ims-oem-plugin.jar
/system_ext/framework/mtk-moto-ims-ext.jar
/system_ext/framework/mtk-moto-telephony-ext.jar
/system_ext/framework/mtk-telephony-common.jar
and:
/system_ext/priv-app/ImsService/ImsService.apk
There are also additional IMS-related applications and libraries.
GSI
The running GSI contains the generic Android:
/system/framework/ims-common.jar
but does not contain the corresponding Motorola/MediaTek implementation stack.
For example, these were specifically checked and are absent:
/system/framework/moto-telephony.jar
/system_ext/framework/mediatek-ims-base.jar
/system_ext/framework/mediatek-ims-oem-plugin.jar
/system_ext/framework/mtk-moto-ims-ext.jar
/system_ext/framework/mtk-moto-telephony-ext.jar
/system_ext/framework/mtk-telephony-common.jar
/system_ext/priv-app/ImsService/ImsService.apk
The GSI’s generic ims-common.jar was compared with the stock version. Both contain the normal com.android.ims framework classes, so simply replacing ims-common.jar does not appear to be the missing piece.
Vendor-side comparison
The stock vendor partition contains the MediaTek RadioEx IMS implementation, including:
vendor.mediatek.hardware.mtkradioex.ims-V1-ndk.so
vendor.mediatek.hardware.mtkradioex.voice-V1-ndk.so
vendor.mediatek.hardware.mtkradioex.mwi-V1-ndk.so
along with the other MediaTek RadioEx components.
Stock also contains IMS/VoLTE support binaries:
/vendor/bin/ipsec_mon
/vendor/bin/rcs_volte_stack
/vendor/bin/volte_clientapi_ua
and supporting libraries such as:
libipsec_ims_shr.so
librcs_volte_core.so
The GSI vendor partition contains the corresponding init scripts and VINTF declarations, but the actual IMS/RadioEx implementation libraries and helper binaries are absent.
For example, the GSI contains init definitions referring to:
/vendor/bin/ipsec_mon
/vendor/bin/rcs_volte_stack
/vendor/bin/volte_clientapi_ua
but those binaries are not present.
Similarly, the GSI VINTF manifest declares the MediaTek RadioEx interfaces, but the corresponding implementation .so files are not present in the GSI vendor filesystem.
Important architectural observation
This appears to be more than a missing configuration flag.
The GSI has portions of the description/configuration of the MediaTek IMS environment:
-
IMS-related permission XML
-
IMS overlays
-
MediaTek RadioEx VINTF declarations
-
init scripts for IMS-related helper processes
but lacks substantial portions of the actual implementation:
-
com.mediatek.ims / ImsService.apk
-
MediaTek IMS framework JARs
-
Motorola IMS/telephony extension JARs
-
MediaTek RadioEx native implementations
-
IMS/VoLTE helper binaries
The runtime result is consistent with this:
No registered "ims" Binder service
↓
No com.mediatek.ims package
↓
No functional MediaTek IMS service
↓
Telephony can initiate the call
↓
Call reaches DIALING
↓
Connection service unavailable
↓
CM_SER_UNAVAILABLE / TelephonyCause 36
This is the current working hypothesis based on the observed evidence.
Why I have not simply copied ImsService.apk
I do not think copying the stock ImsService.apk by itself is a safe or meaningful test.
The stock APK has dependencies on Motorola and MediaTek framework components, including classes/interfaces associated with:
com.mediatek.ims
com.mediatek.ims.internal
com.mediatek.ims.ril
com.mediatek.wfo
com.motorola.android.ims
com.motorola.android.telephony
vendor.mediatek.hardware.mtkradioex
The APK also declares the required shared library:
moto-telephony
and communicates with the MediaTek RadioEx stack.
Therefore, installing only the APK would leave many of its dependencies unresolved.
Request for GSI integration guidance
At this point, I would appreciate your advice on the correct way to integrate the Motorola/MediaTek IMS stack into the GSI.
Specifically:
-
What is the minimum set of stock framework components required to make com.mediatek.ims function on this Android 16 GSI?
-
Which of the Motorola/MediaTek framework JARs need to be integrated together?
-
Which RadioEx HAL implementations and supporting vendor libraries are required?
-
Are the missing binaries such as volte_clientapi_ua, rcs_volte_stack, and ipsec_mon required for basic MMTEL/VoLTE calling, or only for additional IMS functionality?
-
Does the GSI’s existing VINTF configuration need modification, or is it already sufficient once the actual vendor implementations are present?
-
Are there compatibility issues between the stock Motorola Android 16 IMS components and the /e/OS Android 16 GSI framework that need to be handled through overlays, classpath changes, or other integration work?
The goal is not to blindly transplant the stock IMS files. The goal is to identify the correct dependency chain and determine whether the stock IMS implementation can be integrated cleanly into the GSI.
Bottom line
The current evidence strongly indicates that the voice-call failure is associated with the absence of the Motorola/MediaTek IMS implementation in the GSI rather than simply a disabled VoLTE setting.
The most direct runtime evidence is:
adb shell dumpsys ims
Can't find service: ims
combined with:
com.mediatek.ims
being absent from the installed packages, while the stock firmware contains com.mediatek.ims and its supporting framework/vendor stack.
The clean call log then shows:
CM_SER_UNAVAILABLE
TelephonyCause: 36/-1
ImsReasonInfo: null
after the call reaches DIALING.
This gives us a concrete starting point for determining how IMS should be integrated into the unofficial GSI.
