[Vibrant Android Development] Genesis3:
Let's clear the air on this, eh?

First, there are multiple issues involved:

1. There are a number of undocumented RIL commands that Samsung uses. The original "support" did not handle these at all, and ROMs that have the base SamsunRIL code in it that you try to run on the Vibrant will actually crash the modem driver when those upcalls come in. This results in the phone basically locking out for calls entirely under certain circumstances, including sometimes when you dial 911. In some cases this will leave the modem in a state that will REMAIN locked up until the phone is restarted.

2. If you ditch the undocumented calls and flatly-wrong calls into the radio that were originally in the code (that is, you code to ignore them so they don't blow up the radio stack and throw an exception at the phone app thereby blowing IT up too, along with fixing the code so it correctly passes both the extension and tty parameters - which I have done) then you get connected but there's no audio. That's unacceptable for all the obvious reasons.

#1 and #2 are bad news. They could lead to a serious life-safety issue. #1 is especially bad as a call that goes in like this and rings to the E911 board but cannot be returned MAY be presumed by the agency involved to be a duress (or "unable to respond" -- e.g. you just had a massive heart attack) situation and result in a request to the carrier for a "best guess" triangulation position and, if it's anything close to your billing address, it is at least somewhat likely (especially if you don't have a landline there!) to result in a high-dollar asset roll to that location. Needless to say that sort of thing, if it happens, has a good probability of leading to severe negative media attention and perhaps government

regulatory

attention aimed at people just like us who like to build and run our own custom firmware.

One temporary solution to this would be for the CM7 team to

BLOCK

all 911 dialing attempts. This can be done in the RIL code by refusing to place a call to any number in the emergency list. That would be a literal

two minute

coding effort. Doing that would disable ALL emergency dialing capability; this does not change the functionality we have now (none for 911 calls) but

does

prevent the risk of a connected call that doesn't work, and thus would avoid the potential regulatory issue and the risk of an asset roll and very angry public-service agency. Since it's your device if you wish to run it intentionally disabling emergency calling capability there's a pretty-clean argument that this is your decision to make. What's not within your right of decision-making is to place calls to an emergency system that are corrupted or otherwise unusable. At the same time a pop-up warning on boot (or in the kernel splash) to warn of this would be appropriate. If you wished to do this and remain in a given local area you could program in "Police" or "Fire" on your phone as a contact with the local (non-911) number and use that if the occasion arose. This is exactly what we used to have in our homes, usually on a sticker on the phone, prior to "911"

But it's not what was chosen here.

When I asked for access to the Hercules code it was due to the fact that the Hercules sometimes fails to connect audio even on ordinary calls. I happen to own both devices. IMHO the current Hercules build is

unusable

due to the fact that it sometimes loses audio for all calls --

but note that it remains available over on that board here on XDA for general consumption.

I was not told no - I was literally

ignored.

When I tried to poke the other side (the Vibrant) I was finally told, and I quote: "Talk is cheap and I'm done with you. None of us have the time to deal with the pontificating as we have yet to see you actually produce any code and you are just another developers whose "****" I'd rather not put up with." -- End quote.

Yes, that drew a strong response. No code eh? Uh, "Tickerguy" on github -- the Triumph port is mostly mine, which they were

well

aware of -- both Android and kernel fixes and enhancements, all in the open with published source and commits, and the chronology of the entire things is on Android Forums as well as here on XDA in the appropriate place (along with the kangs.)

The blatant hypocrisy in this case is blistering; on the one hand we have a phone that sometimes refuses to connect any audio, and on the other we have a life-safety issue yet in both cases the code remained available and released. Instead of opening the Hercules repo which would have been consistent with CM's prior actions, along with blocking all 911 calls and making clear on the boot screen that this functionality did not work on the Vibrant until and unless they could fix it, they decided to do what they did instead.

CM is free to do what they wish; as I often say in other venues we're all entitled to our own opinions but not our own set of facts. I continue to work the Vibrant 911 call issue; it is difficult to work on because although I have the device I cannot call 911 to test and thus must rely on others who both have the phone and work for a public-safety organization and can perform the testing. As they're not developers the information I get from them is in the form of logs without any intuitive feel or knowledge of exactly what I'm looking for or how the flow of the execution should go. In addition this isn't my day job by any means, and as such I work on it when I have time, which isn't all the time. Finally, there was basically ZERO information shared with me when I picked this up and as such I started from scratch -- either nobody in CM knew anything about it or they decided, for whatever reason, not to share what they did know. I don't know which it is but what I do know is that the unhandled calls are, as of my last sync against the released CM7 sources, unchanged from when I started looking at this well over a month ago.

Nonetheless not everyone has "abandoned" CM7 on the Vibrant, at least not at this point. This is not an impossible-to-solve situation -- I ran into a similar problem with the Triumph both pulling the PRL and with its Qualcomm radio sending up undocumented calls that blew up the radio stack and was able to work through them and reach a stable and functional codebase. In that case while it took me a week or so of fairly diligent effort I was working with something I could easily test since it happened all the time on all calls and thus I was able to instrument the suspect areas, test and debug in a highly-iterative process until I was able to isolate the problem and fix it. This is much more difficult; if I owned a base simulator and a big-ass faraday cage where I could run both the fake base and the phone without having the FCC knocking on my door for unlawful emissions I bet I could nail this within a couple of days but I don't so I'm forced to work with limited resources and by "remote hands." The "fake base" is not THAT expensive (you can buy the hardware and there's free software available to drive it) but as a licensed HAM and also as a historical holder of other FCC licenses I'm well-aware that firing up one's own base station is

very

illegal and I prefer not to have a visit from the guys in the nice dark suits driving Suburbans.

It is possible that the block is in fact coming from the radio code itself and not Android. I'm not convinced at this point in time and in fact have a heavily-modified build that I'm gathering information with at present. If it turns out that the problem lies in the kernel never being told to enable the proper audio paths I can fix it -- it may be messy, but I can fix it. If the kernel IS correctly setting audio routing and the radio is blocking it then it gets MUCH more difficult and the way I'd normally approach that pretty-much requires that faraday cage, as for me to get into the mental space where I need to be to run this down I need to be able to make rapid incremental changes and observe results in real-time and I'm very likely to produce all sorts of really wild results in the process that will highly annoy any legitimate emergency agency. That I simply can't do with "remote hands" -- I need a simulated base and place I can legally use it. Since I don't have one and neither does anyone I know if that's the conclusion I finally reach it's a dead end, but as of today we're not there.

If you (1) work for a public safety agency and can confirm to my satisfaction that you can actually test against the 911 infrastructure (not through emails - I need to be able to vet the claim), (2) you own a Vibrant and (3) are familiar enough with debugging android to be comfortable using adb where I don't need to teach you how to find your way around and are willing to do the testing required then feel free to contact me. I've got one person I'm working with who meets these criteria and one more might be helpful, but "friend of a friend" stuff doesn't cut it and I don't need a bunch of people -- just one or two who can turn a test reasonably quickly and understand what they're doing. If I can fix this and confirm it's fixed then I'll do exactly what I did with the Triumph -- I'll fork the repo(s) involved in the fix and commit the fixes and push them up to Github. If CM wants to pull them back from me and incorporate it that's up to them, if not that's fine too - those who want it can have it.

Finally, please be aware that I know of at least one "cooked" ROM for the Vibrant that originated on another Galaxy device which appears to connect a 911 call correctly but in fact the modem crashes as does the RIL stack when the connection occurs. While the log I have on that shows that the RIL recovered and the call was usable that was alarming enough to find that I would be very, very careful in this regard in terms of your expectations with various chef'd roms here or elsewhere for this device. Put bluntly there's a reasonably-high probability that any firmware based on anything other than the official Vibrant code (e.g. a port from any other Galaxy device) may exhibit the same misbehavior and potentially could fail in exactly the same way as CM7 does under an actual emergency situation. Since there's no legal and valid way for you to test this as a member of the general public and none of these builds lock out the emergency dialing numbers please be aware that all of them are at risk of similar misbehavior.

As a result at present the only firmware I could recommend you run on a Vibrant is:

1. The stock T-Mobile loads (any of them)

2. A CM7 or AOSP build from source that the builder has taken the time to lock out the 911 calling functionality from entirely. You'll have no emergency calling at all but other than that they should be ok.

3. A different build where you have independent verification that E911 connections work and do not exhibit signs of modem crashes during those calls in the logs. To the best of my knowledge there are no current ROM releases in the third category.

If I come to a conclusion -- which I don't have today -- I'll post it in this thread.