-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Q: In-call disconnect/reconnect?
- Thread starter erisuser1
- Start date
-
- Tags
- htc droid eris
Ya thats when it was happening to me too. I just flashed an older radio and so far on my 2 very short calls it hasnt happened yet. So im just gonna cross my fingers and hope for the best.
D
Deleted User
Guest
Weird.. this happened to me for the first time today, and it happened 3 times in a row. Odd. It's not happening with every call, though.
(Running KaosFroyo v32, baseband 2.42.01.04.27)
(Running KaosFroyo v32, baseband 2.42.01.04.27)
Same thing is happening here. Rooted, KaosFroyo v30, 2.42.01.04.27 radio. I will be talking to someone, hear the dropped call beep, pull the phone away from my face to see my homescreen, then it will ring as if I have an incoming call, I will answer, and the person I was talking to will still be talking and they won't even know it happened. It never happened to me on a rooted 2.1. Just 2.2. and it has not happened to me while using my bluetooth or speakerphone, only when holding it to my ear. This can't be a dropped call because the call continues on the other end.
i had this happen to me for the first time last night also..phone vibrated to tell me the call was disconnected looked at it and it was back and my contacts page then just reconnected and the other person was still talking like nothing happened..im running kaosfroyo v34 with the 2.42.01.04.27 radio
funkyfender
Well-Known Member
I've only had it happen to me on CM6-based roms when I'm on the phone for more than 5 minutes or so. And honestly, I don't make too many long calls.
I captured some new diagnostic information today.
Basically, it appears as if the "rild" (Radio Interface Layer Daemon) is "segfaulting" in the middle of the call and crashing.
For those of you that are not programmers, it occurs when an executable program references a memory address which is outside it's valid address space - the most likely case is trying to dereference a pointer which has a null value. (It can also happen as a result of memory heap corruption). In any event, it is quite possibly the most serious program logic error that a program can commit - it's one of those "this should never happen" type of errors.
I don't know offhand whether this is fixable or not; it probably will require quite a bit of detective work, because I don't believe that the relevant source code is available.
Rats.
eu1
Basically, it appears as if the "rild" (Radio Interface Layer Daemon) is "segfaulting" in the middle of the call and crashing.
For those of you that are not programmers, it occurs when an executable program references a memory address which is outside it's valid address space - the most likely case is trying to dereference a pointer which has a null value. (It can also happen as a result of memory heap corruption). In any event, it is quite possibly the most serious program logic error that a program can commit - it's one of those "this should never happen" type of errors.
I don't know offhand whether this is fixable or not; it probably will require quite a bit of detective work, because I don't believe that the relevant source code is available.
Rats.
eu1
eu1,
Is this helpful?
Radio Layer Interface | Android Open Source
/var/www/vhosts/netmite.com/android/mydroid/hardware/ril/rild/rild.c
(unless, of course, that you meant the source-code for the libraries being the relevant ones)
The stack trace indicates involvement of the vendor library libhtc_ril.so.
I am pulling the CM source tree right now - I am actually unsure if it is built from sources or appropriated from a HTC "factory" ROM - possibly the CDMA version of the Hero?
Still, something seems a little strange at the moment - I don't see where the dynamic link dependency of "rild" involves libhtc_ril.so - I recursively followed all the dynamic link dependencies (arm-eabi-objdump -x $lib | grep NEEDED), and couldn't figure out why it would get pulled in. So, I have no idea why "debuggerd" produced a stack trace that involves "libhtc_ril.so".
What is clear is that (at least for the Froyo ROM that I was using, Tazz 2.0), the "rild" and various RIL libraries (libril.so, libreference-ril.so, libhtc_ril.so) are not from HTC stock or OTA releases - they are identical to objects from the CM6-RC1 build for the Hero (CDMA version).
I'll look a little more. I suppose I could swap out various libraries and replace them with the corresponding files from the 2.1 OTA (July 17, 2010) HTC release for the Eris - just to see if the phone chokes right away on that.
eu1
[ Edit ] Duh. I should have read the link I provided ("vendor library") more carefully - the "rild" daemon explicitly calls the dynamic loader after reading rild.libpath and rild.libargs out of the Android property system. ( In Tazz 2.0, only the former property is set ... to /system/lib/libhtc_ril.so ). That explains how it gets linked in at runtime. Time for bed now, but I can not find anyplace in the CM6 tree where libhtc_ril.so gets built, so starting right now I will run an experiment where I replace the Hero (?) version:
HTC-RIL 2.0.0056H (Feb 26 2010,10:19:11) "libhtc_ril.so" 462,676 bytes; md5 e921186c8e5342fdf8c2fccac9f9f632
with the HTC Eris July 17 2010 OTA version ( == Leak-V3 version):
HTC-RIL 2.0.0029H (Jan 8 2010,22:41:37) "libhtc_ril.so" 458,608 bytes; md5 2857bca5b51163004d2254a1b13ab0cd
to see how that goes.
Initial result: everything seems OK using web browsing, SMS, MMS, Gmail, Email, Voicemail. Now I just need some more testers - I recall somebody said they experienced the problem many times a day. (I make a poor tester because I simply don't talk on the phone that much, so its a long time between occurrences of the problem - it might take me weeks to determine if this experiment has an effect).
eu1
Well, at the moment, I only have a hypotheses - I need some testers to help out.
This is one of those situations where success is measured by the disappearance of a symptom that only occurs infrequently in the first place. If you are reading this, and the problem occurs to you somewhat frequently, you are in the best position to help out.
I can provide explicit instructions if the above post seems vague.
eu1
If you want to assist testing this out (that is, if you are experiencing this problem as a result of using a Froyo ROM), I have attached instructions on how to make this simple change at the end of this XDA post
eu1
eu1
happened to me for the third time earlier today. havent had this problem anywhere else except for in my man cave in the basement. today i was in the middle of telling a friend a funny story from the other night, and this happened, but he said he heard me say "wtf" when the phone disconnected, i said that right after i heard the first beep and said disconnected. im thinking that its not even really disconnecting, maybe just some sort of funky **** up on the eris with 2.x or something..??
The call is absolutely staying connected on the radio side of things. What happens is that all the apps that that you interact with get their data (whether voice, or RTT/EVDO data) through the "rild" (Radio Interface Layer Daemon). If it crashes, those apps - specifically the phone app, behaves as if the call has been disconnected, even though the hardware/firmware side of the call is still connected (as far as the radio is concerned). "rild" gets automatically restarted, and so the call pops back into place once "rild" restarts.
Please help out if you can by installing the Eris library and testing to see if you continue to observer the problem in the "man cave" (or elsewhere) after you have patched.
eu1
Update:
Yesterday, I replaced the Sprint library "libhtc_ril.so" with the Eris 2.1 version (from either Leak-V3, or July 17 OTA - they are the same file in both those ROMs), and approximately 8 hours later had the exact same phenomenon occur: loss of call audio, "call end" vibration, return of the dialer GUI, and then seconds later the call audio re-appeared. I dumped the "logcat", and sure enough, the same thing happened: at that exact moment in time, the "rild" process had crashed (segfaulted).
This seems to imply that the version of "rild" which is being built out of the CM trees is the source of the problem, rather than the vendor-specific library, as the same behavior is experienced with both the Sprint Hero and Verizon Eris (HTC) vendor library. (Note that the same phenomenon was observed in CM5.0.8 ROMs as well.)
I initially thought that it would be impossible to simply replace the version of "rild" in the Froyo/CM6 ROM with the HTC Eris (17 July OTA) version because of version-checking in the dynamic linking of rild** - but, I dropped it into place, and no complaints from the linker. I then did some testing - voice call, SMS, MMS, browsing, Gmail, email, Google Maps, etc - no apparent trouble. I am currently running Tazz 2.0 + CFS4 + replacement of "rild" and "libhtc_rild.so" by the Eris 2.1 (17 July OTA) components.
Again, if anyone who experiences this problem frequently would like to assist in testing this out, your participation would help out greatly. Let me know if you need help to set it up.
eu1
** "rild" dynamically links directly to
liblog.so
libcutils.so
libril.so
libc.so
libsdtc++.so
libm.so
libdl.so
and these libraries in turn (if you follow all dependencies) dynamically link to
libutils.so
libbinder.so
libhardware_legacy.so
libz.so
libwpa_client.so
libgps.so
libnetutils.so
librpc.so
Yesterday, I replaced the Sprint library "libhtc_ril.so" with the Eris 2.1 version (from either Leak-V3, or July 17 OTA - they are the same file in both those ROMs), and approximately 8 hours later had the exact same phenomenon occur: loss of call audio, "call end" vibration, return of the dialer GUI, and then seconds later the call audio re-appeared. I dumped the "logcat", and sure enough, the same thing happened: at that exact moment in time, the "rild" process had crashed (segfaulted).
This seems to imply that the version of "rild" which is being built out of the CM trees is the source of the problem, rather than the vendor-specific library, as the same behavior is experienced with both the Sprint Hero and Verizon Eris (HTC) vendor library. (Note that the same phenomenon was observed in CM5.0.8 ROMs as well.)
I initially thought that it would be impossible to simply replace the version of "rild" in the Froyo/CM6 ROM with the HTC Eris (17 July OTA) version because of version-checking in the dynamic linking of rild** - but, I dropped it into place, and no complaints from the linker. I then did some testing - voice call, SMS, MMS, browsing, Gmail, email, Google Maps, etc - no apparent trouble. I am currently running Tazz 2.0 + CFS4 + replacement of "rild" and "libhtc_rild.so" by the Eris 2.1 (17 July OTA) components.
Again, if anyone who experiences this problem frequently would like to assist in testing this out, your participation would help out greatly. Let me know if you need help to set it up.
eu1
** "rild" dynamically links directly to
liblog.so
libcutils.so
libril.so
libc.so
libsdtc++.so
libm.so
libdl.so
and these libraries in turn (if you follow all dependencies) dynamically link to
libutils.so
libbinder.so
libhardware_legacy.so
libz.so
libwpa_client.so
libgps.so
libnetutils.so
librpc.so
dude, i would totally help you do this, but i am so computer re+arded that i wouldnt know what to do. im running kaosfroyo v32 and im lucky that i even got that to work!!
[ Edit ] - Deprecated as of 2010/09/20 - (confirmed that this does not fix anything; apologies for any inconveniences)
I put up flashable .zips to install the test case (two files) in this XDA post. Your assistance with testing would be appreciated. Additional testing by anybody else that experiences this problem frequently on Froyo (Android 2.2) ROMs would be of great value.
eu1
PS. Frisco - I put this thread originally into the main Eris forum, because initially I was looking to see if anyone experienced the problem on HTC stock, or HTC-derived ROMs from 2.1 (in addition to in CM or AOSP 2.2 ROMs). At this point it seems obvious that this problem is confined to only CM5/CM6/AOSP ROMs, so feel free to move the thread to the eris-all-things-root subforum.
warnermomx2
Lurker
I was running a Kaos Froyo V. 29 and had that happen, then went to PlainJaneT2 and have not had that happen since.
That is consistent with other reports. The problem seems to affect most, (but perhaps not all) CM (CyanongenMod) 5.0.6, 6.x, and AOSP ROMs. All ROMs which were derived from the HTC 2.1 ROMs (which includes PlainJaneT2) do not experience the problem.
eu1