Database Develop

911 and e911 explained

Personal background: Associate degree in Laser Electro Optics. 12 years research and development semiconductor manufacturing, 15 years as an EMT, last 10 years as a 911 telecommunicator for Austin-Travis County Emergency Medical Services. 6 of those years as a Training Officer.
The reason for my (cough) resume is so everyone understands I have the technical background and experience to explain the differences between e911 and 911.
Public Safety Answering Point: the local organization tasked with answering emergency request phone calls and dispatching appropriate emergency resources. PSAP's are broken into two types, primary and secondary. The primary PSAP is typically the local police department for city's and the local sheriff's department for unincorporated areas. Some colleges have their own police department and may have their own PSAP. So realistically a person can connect to a different 911 call center depending upon their location within a small geographic area.
Large urban areas typically have secondary PSAP's. The secondary PSAP usually consists of public safety departments not related to law enforcement such as fire and/or emergency medical services (ambulance services) specially trained to send request specific resources dependent upon the emergency. In Austin and Travis County we run 120 thousand EMS 911 calls per year. The police department takes about 2000 911 calls per day.
911: a simple to remember phone number nation wide allowing everyone access to emergency services. No location information is transmitted or received. The PSAP is responsible for determining location by interrogation of the caller. This can a problem if the caller is altered or otherwise unable to give accurate information.
e911: Enhanced 911 was created to ensure location information was transmitted to the 911 call center regardless of the callers ability to give this information. The phone companies are responsible for ensuring this information is available and transmitted to the PSAP. Conventional e911 is effective for landline phones. Cell phones present a completely different problem.
Cell phones are required to meet two different location technology standards.
Phase 1 wireless data: as cell phone use skyrocketed in the nineties, legislation was passed requiring provider's to transmit location data based on the cell phone tower that the cell phone was connected to. While this is helpful, it is problematic due to the sheer size of the area that had to be searched if the caller was unable to give their location.
Phase 2 wireless data: legislation now requires GPS location data be provided by the cell phone company. This location information can be transmitted via the gps chip from the cell phone or via radio location triangulation using the cell towers in the immediate area of the caller.
So in a nut shell, my test of neobuddy's ICS indicated that 911 worked for a sim loaded phone. I did not test the phone with the sim pulled. I also did NOT verify that GPS data was being received by the PSAP.
If 911 works with your phone it should work in any area. I was connecting with two different PSAP's as I live right between two different area's and sometimes connect to one or the other.
Hope this clears some of the confusion. A good explanation is located at en.wikipedia.org/wiki/Enhanced_9-1-1.
genesis3 and I are still working on the cm7 issue and getting closer to a resolution.
Later tators
Sent from my Touchpad using xda premium

thanks a lot. i can confirm cm7.1 has 911 issue.
Sent from my SGH-T959 using XDA Premium App

Developers should also note that as technology continues to advance, video conferencing and text message 911 activation requirements will also be legislated in.
I firmly believe that Google should begin requiring manufacturers make their modem software and audio software open source. Manufacturers should also be required to provide detailed explanations of how the relevant library's interface with the operating system, modems and audio system when activating an emergency call. This is Androids achilles heel. All it will take is one national media event to slam the door on open source operating systems for cell phones. I love the freedom Android provides and the exceptional programing skilss of our developers.

Im sorry, while this is a great explanation, i really didnt get the bottom line....
What we have on nonsamsung roms then is just a plain 911 incapable of transmitting location?
Sent from a cell tower to the XDA server to you.

Im sorry, while this is a great explanation, i really didnt get the bottom line....
What we have on nonsamsung roms then is just a plain 911 incapable of transmitting location?
Click to expand...
Click to collapse
correct as none had the source code....but for 2.3 onwards rom.
genesis3 and I are still working on the cm7 issue and getting closer to a resolution.
Click to expand...
Click to collapse
made my day.....thanks a lot....will be keeping a close eye on this thread...

My understanding is the issue is only without a sim right?

The 911 issue is with SIM, i don't know about without and im not planning on finding out.

HaloMediaz said:
My understanding is the issue is only without a sim right?
Click to expand...
Click to collapse
It has to do with emergency mode (no dim) and when no compatible roaming network is around (no service) .
Sent from my HTC Sensation 4G

hmmm I havent called 911 in YEARS but it still feels nice to have the ability and this was a nice explantion thank you

MIUI 360 in Asheville NC works fine but not in other areas?

Hopefully they can test the cm9 test ports that are out now.
Sent from my SGH-T959 using xda premium

http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.

Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
Can we get independent confirmation of this? (not that I don't believe you)
Sent from my SGH-T959 using xda premium

Uh, the guy who tested and verified it is the OP on this thread.
Read the first post.

You typed all that from your touch pad? props
Sent from my SGH-T959 using XDA App

Genesis3 said:
Uh, the guy who tested and verified it is the OP on this thread.
Read the first post.
Click to expand...
Click to collapse
No, I get that. Just wanted to make sure he verified was all..

Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
Don't know who you are or where you came from but, you sir may have saved CM development for the vibrant community. Here's hoping and you're the man!!!
Sent from my SGH-T959

Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
I just downloaded your kang and running great so far, Thanks for you work !!
Question, is this 911 fix kernel dependent ? ie will it break if I flash another cm7 kernel ?
Thanks again for your hard work !!!

will replacing the kernel break both 911 and gps fixes?

I didn't save anything.
Here's the bottom line, if you're interested in it.
In the original Vibrant device directory there was a set of sources for libaudio -- one of the shared libraries that Android depends on to talk to the audio hardware in the phone. There was no documentation as to where this source came from, but I know where it didn't come from -- it didn't come from a public Gingerbread source for the Vibrant, because there isn't one.
It turns out the library this source builds does not work correctly but exactly why I'm not certain of. One of the problems with debugging this is that I have to have someone else test for me, which means I can't do the sort of testing I like to when I'm tracing things like this (a highly-iterative process that requires that I actually be staring at the debugging screen while doing the deeds that cause the bad behavior) since I can't call 911 myself.. Had the provenance of this code been documented originally (or lack thereof) I would have investigated this possible connection, as I knew the problem lay in the audio connectivity due to myriad kernel and application traces a couple of months ago. I didn't chase that library down and attempt to graft in other related versions because I assumed that the CM people knew what they were doing building that library from source rather than using a cribbed copy from, for example, Froyo or a different gingerbread build off a similar device.
Picking up a different shared library does work. Exactly what the provenance of that library is (e.g. was it grabbed from a binary, was it built from DIFFERENT source, where did it come from?) is also unknown.
Now that I have a working shared library on this device and a non-working one I'm going to compare traces. Maybe I'll get lucky and find the changes necessary in the source that's in the build tree and be able to fix that, at which point I'll know what I've got rather than having a "magic" library from God-knows-where.
Now here's the part that annoys me -- I was all over some of the CM guys about audio problems with other Samsung devices and tried to get access to the "not yet finished" repos because I expected that if I could run down the same sort of problem with ordinary calls in one of the OTHER Samsungs it was rather more likely than not that the same fix would be pertinent in some way on the Vibrant -- simply because manufacturers tend to use the same chipsets and bits, along with APIs, between different devices (it makes it easier for their coders and maintainers to do their jobs.) In addition when I started working one this one of the other protagonists didn't give me jack and crap about the provenance of anything in the device tree and, again, there's no docs embedded in the tree either. You can find the flamewar and slander aimed at me here if you'd like. It turns out I was on the right path; the problem this library allegedly fixed was having to hit <MUTE> twice to turn off and on the audio path. Sound familiar? Well, the pointer to the file that I found and integrated was from a bug logged against the I-9000, a similar phone to the Vibrant, and that library version works. What's changed in it? There's no set of commits logged against the ZIP file provided in that patch; is it a binary lift from a different build (e.g. some factory build) or did someone fix the source?
Who the hell knows because again, it's not documented in the bugtracker. Until I know where it came from and, if there's source, I have access to it, I won't support it. I don't play the "hide the sausage" game when it comes to alleged community coding projects.
I ran into something similar with the Triumph in that there was a different set of parameters coming up from the hardware when a wired headset was plugged in. That was easy to run down because I could do it and see what was going on; it was a literal couple of line change in the code once I found it. There are a couple of places in the libaudio source that might be the cause of this now that I have a reason to look in there, but without being able to easily reproduce the condition that creates the failure (e.g. call 911) it's a guess.
The ICS builds out at present have a different copy of the same compiled library and it also works. I bet that one works too on CM7 as it's fairly close to the metal and thus the API's probably the same (or close) on the Android side but I haven't tried it yet. I've got little reason to since I now have a libaudio.so that's functional on CM7 in any event.
While I've been working on the 911 issue (for a couple months on and off) I also traced down some actual working (properly) GPS libraries that handle the AGPS assist data in the correct way, something that other sets of them do not, and added those too. I also made a few other changes. The battery life is reported to be rather impressive, and the near-instant GPS locks most-definitely are. I can't speak much to the battery life view of the world as of yet but I will be looking at that; that's an area I know quite a bit about (getting these devices to properly go into deep sleep as they should) and the source tree I'm working with does have kernel source.
Any sideloaded kernel that leaves libaudio.so alone (check the zip file to make sure that /system/lib/libaudio.so is NOT present) should be ok, but no promises. Before you go screwing with kernels make sure you want to --you might break GPS performance as a number of the kernels have various attempts to get the GPS to work right and load various libraries along with the kernel itself with varying degrees of success.
I'd be willing to maintain this port but there are two conditions -- first, I expect apologies from the CM people who attacked me, in public, and second, I expect a formal commitment that there will be no more hiding of information. "I don't know" is an acceptable answer provided you run down the person who does -- someone does know because someone DID either import or code the material in question; silence and lack of documenting where things came from and how they came to be is not acceptable. When things go into the codebase through review they damn well ought to be documented. I played "talking to the brick wall" with the Triumph and now the Vibrant and I won't do it if I'm taking on responsibility for maintaining something.
If CM wants me involved in this that's the deal. If not I'll consider setting up a parallel build and set of repos for the bits that have to be changed from the base CM7 Gingerbread branch as I did for the Triumph if there are people interested in it, but my time is not unlimited and in all honesty my taste for working with the CM people and the CM code in general has been seriously damaged, never mind that what I have here seems to work just fine. As such the benefits of continued efforts are likely to be relatively small. If I decide against a continuing effort I will take the build environment that produced that I have now and attempt to set up a manifest so it can be cloned by anyone else who cares to do so, which should take care of others being able to build and run the KANGs from source if they wish. The latter may take a while as I need to find a day when I'm not busy and can put that together (again, lack of documentation doesn't help) and then pull a clean test from a zero base and make sure it builds and runs.
The Vibrant is no longer my daily device but I do still own one, and given its relatively modest resale value I'll probably keep it as a spare device -- it's a very credible phone and with working GPS code it actually locks faster and better than my Hercules does. It's biggest shortcoming is that it's relatively RAM-starved compared to more-modern devices.
Fancy that.

[q] OTG on ICS

Im looking for a way to run a camera control software for nikon DSLRs on my note. However theese apps all are tablet software for android 3+. They run just fine on the cyanogen alpha, but that rom is too far from daily use even for bleeding edge enthusiasts, like most of us here. Thus, until now I have been forced to reflash everytime i need to control the camera with the phone.
Now several ICS ROMs have emerged, but those I have tested, though stable enough, refuse to work with USB on the go devices. The notice about the OTG cable show up all right ob them all, but they do not detect anything attached to the other end of it like in gingerbread and cyanogen alpha.
Is there a way i could fix this by copying some files from the cyanogen ROM over to one of the other ROMs? If so, which files would that be?

It's a kernel related issue. This means that we have to wait for Chainfire to get back from his vacation and tackle this problem. Or some other kernel dev.
Nothing we can do about it right now.

Ok, though i am a novice in the world of android hacking, that is not the case, at all, regarding linux kernel hacking. Setting up a cross compiling dev environment and moving a driver from one kernel source to another or compiling a module is actually less unfamiliar to me than trixing around with binaries from different beta releases. If that is the case i might be up to it. But that would only work if the source code, or at very least the kernel headers are available for the kernels used in the betas.
Sent from my GT-N7000 using XDA App

[Q] Sim contacts not available - critical bug on all custom kernels

Hi. This developer gathering sounds promising, I'm glad you guys help each-other for the benefit of users and leave personal fame aside.
But. GT-S5830i Spain (Moviestar) (S5830IBGLH4 S5830IXECLH2)
All your kernels have the Sim contacts not available critical bug. And I say critical as it's a basic function of a phone.
There is only one workaround, flashing the S5830CVJKL4 baseband (odin-izing just the phone=modem part is enough).
- then I've noticed that it greatly affects network reception with 30-70% less signal and no signal at all in some places.
- and it does not end here: antutu gpu scores goes down from the already low 290~ish to <190~ish.
- flashing the whole stock S5830CVJKL4 firmware with it's stock kernel has the same bad network reception and low antutu gpu scores.
So this workaround ends up doing more harm than good.
So now I have some questions for all of you, Rafael.Baugis, axyllum, hell-lock:
- what source do you use for building as Samsung provides no less than five S5830i sources: GT-S5830I_CHN_GB,
GT-S5830I_HK_GB, GT-S5830I_MEA, GT-S5830I_SEA_SWA_GB and GT-S5830i (I'm guessing none of them, but some C/M version).
In the light of these findings, can we say:
- "The kernel can be used on any rom." notice in all your releases is just wishful thinking and a bit misleading?
- there is yet another hardware difference (the modem) at least with this Moviestar version and should be blacklisted for now?
- there is something special with this S5830CVJKL4 firmware?
Thank you very much for your hard work.

It's not really critical if there's a workaround.
Also, simpler workaround: use your Google account to sync contacts.

WHAT THE ****!! That bug is on my kernel too??!!
---------- Post added at 04:21 PM ---------- Previous post was at 04:20 PM ----------
I am using GT-S5830I_CHN_GB ...

hell_lock said:
That bug is on my kernel too?
Click to expand...
Click to collapse
Unfortunately.
I've checked the 3 custom kernels vs. 6 stock roms and 6 custom roms for the s5830i. This Moviestar version does not work, and from the number of complains all over the threads here, I'm guessing there are other models that simply do not work. These should be blacklisted so people don't get their hopes up and start flashing each time one of your kernel versions is updated (this needs input from all the people complaining, a forum search should be a good start, maybe I will do it later).
It's a shame that all that is missing is a suitable config/driver for the kernel - or could the problem be in the locking mechanism - the phone I'm testing is factory unlocked. The source code will clear this up I think, but who do we have to push to get the Moviestar source code as I understand they are bind to release it on request? I will look into this.
Bottom line, there is nothing wrong with your kernels other than not addressing this phone's issues.
GermainZ, there are people that can live with the google contacts sync, good luck with that, but for people that use many sim cards interchangeably it would be a problem (requiring multiple g-accounts, selective syncs). What would you say if your sdcard does not work and the answer you get from support is: "You can use the skydrive cloud instead". Easy to spot unsuitable tasks.

bobdynlan said:
Unfortunately.
I've checked the 3 custom kernels vs. 6 stock roms and 6 custom roms for the s5830i. This Moviestar version does not work, and from the number of complains all over the threads here, I'm guessing there are other models that simply do not work. These should be blacklisted so people don't get their hopes up and start flashing each time one of your kernel versions is updated (this needs input from all the people complaining, a forum search should be a good start, maybe I will do it later).
It's a shame that all that is missing is a suitable config/driver for the kernel - or could the problem be in the locking mechanism - the phone I'm testing is factory unlocked. The source code will clear this up I think, but who do we have to push to get the Moviestar source code as I understand they are bind to release it on request? I will look into this.
Bottom line, there is nothing wrong with your kernels other than not addressing this phone's issues.
GermainZ, there are people that can live with the google contacts sync, good luck with that, but for people that use many sim cards interchangeably it would be a problem (requiring multiple g-accounts, selective syncs). What would you say if your sdcard does not work and the answer you get from support is: "You can use the skydrive cloud instead". Easy to spot unsuitable tasks.
Click to expand...
Click to collapse
Do you know what file is missing? I may fix it.

bobdynlan said:
Hi. This developer gathering sounds promising, I'm glad you guys help each-other for the benefit of users and leave personal fame aside.
But. GT-S5830i Spain (Moviestar) (S5830IBGLH4 S5830IXECLH2)
All your kernels have the Sim contacts not available critical bug. And I say critical as it's a basic function of a phone.
There is only one workaround, flashing the S5830CVJKL4 baseband (odin-izing just the phone=modem part is enough).
- then I've noticed that it greatly affects network reception with 30-70% less signal and no signal at all in some places.
- and it does not end here: antutu gpu scores goes down from the already low 290~ish to <190~ish.
- flashing the whole stock S5830CVJKL4 firmware with it's stock kernel has the same bad network reception and low antutu gpu scores.
So this workaround ends up doing more harm than good.
So now I have some questions for all of you, Rafael.Baugis, axyllum, hell-lock:
- what source do you use for building as Samsung provides no less than five S5830i sources: GT-S5830I_CHN_GB,
GT-S5830I_HK_GB, GT-S5830I_MEA, GT-S5830I_SEA_SWA_GB and GT-S5830i (I'm guessing none of them, but some C/M version).
In the light of these findings, can we say:
- "The kernel can be used on any rom." notice in all your releases is just wishful thinking and a bit misleading?
- there is yet another hardware difference (the modem) at least with this Moviestar version and should be blacklisted for now?
- there is something special with this S5830CVJKL4 firmware?
Thank you very much for your hard work.
Click to expand...
Click to collapse
all kernel sources from samsung have this issues in SIM contacts!
the roms VJKL4 and rajrocks work SIM contacts!
but need to flash param.lfs in ODIN.

hell_lock said:
Do you know what file is missing? I may fix it.
Click to expand...
Click to collapse
That's the problem. I guess the Spain Moviestar version is based upon GT-S5830I_EUR_XX source (GT-S5830i_Opensource.zip). If that's so, there are quite a few differences between the european kernel and the chinese one you are using, confirming my theory that you can't build an universal kernel that works on all roms.
Differences are mostly incremental patches, touchscreen stuff, but also the suspected different locking stuff. modules\drivers\char\brcm\fuse_ril. I have zero inside knowlege of this stuff, but I interpret lines like #define BCM_CFG_SIM_LOCK_SUPPORTED as: CHN kernel enforces a check for SIM LOCK & other SIM related stuff while the EUR kernel does not.
Samsung will not help modders with this (network sim stuff) instead will direct you to mod the kernel from the right source. So the feasible solution is to build different kernels for phone models that have this issue - bye bye universal kernel (it never was universal, it just worked cause samsung did a great job; samsung would have not bothered to keep each platform with a coresponding kernel source).
Attached the actual different files (not a diff patch) between the CHN and EUR Samsung opensource.
Rafael.Baugis, did not know that all samsung sources are having this issue. Did you also test build from this EUR one?

bobdynlan said:
GermainZ, there are people that can live with the google contacts sync, good luck with that, but for people that use many sim cards interchangeably it would be a problem (requiring multiple g-accounts, selective syncs). What would you say if your sdcard does not work and the answer you get from support is: "You can use the skydrive cloud instead". Easy to spot unsuitable tasks.
Click to expand...
Click to collapse
I never said it shouldn't be fixed, I simply said it's not critical (considering not many people use more than a sim card; you're right I didn't think of all possible scenarios, I never thought of yours).
And I'm most certainly not the support.
Also, regarding the EUR kernel, it's outdated. I could try compiling the stock kernel from it if you want.

Is sim working on any source based kernel??
Sent from my GT-S5360 using XDA

Guide to modify kernel for another variant of android device

I have a note 5 n920T and the problem that I have is that most of the oreo or pie custom rom dont exist for this particular model. if a rom boots on it usually call audio is an issue. So, I want to modify existing kernel to work with n920T. I have been unable to find any guide related to "modify kernel for another variant of android device". Can anyone point me to any related guide or tutorial or video. I am a newbie to development and watched a few videos related to custom rom development but it doesn't help me as I want to modify kernel belonging to say n920C to work with n920T. I shall be grateful for your guidance. I have programming knowledge including c and c++

The big issue is with the speaker not working properly when ported to the T-Mobile variant. I believe it's a driver issue.
To be honest, none of the Oreo roms for our device are "good". They both are too unstable and have some major issues such as no/bad Camera (most apps will just crash), Bluetooth doesn't work, etc.
I've been using Oreo lately and just today alone I've had 10+ freezes/reboots. Unable to use bluetooth. Many apps using the camera just crash.
I think it's time to upgrade from our device as there's just no third party support anymore. The LG G7 seems to be the best value high-end phone on ebay, however there's not much support via XDA at this time.

Is this the best place to ask about Moto Z3 (non-play, XT1929-17)

Hello,
I'm very new to android roms
Well, I did a little bit of that back in pre-2010 times and some times with my samsung galaxy nexus, but I assume things have changed a lot since then.
I have many XT1929-17 Z3 non-play and a couple Z4 XT1380 and a few Z2F
I want to try many things,
Download all firmware from each phone, and upload firmware to a phone (I guess that's the flash device and radio firmware , not sure)
Make setup a phone to my taste, make a backup so I can continue messing around without having to go through the entire setup process again !
Next, I have the crappy verizon firmware, I would like the stock android or Z3 motorola stock firmware instead of the verizon one ! WIth all the non-erasable bloat- and spy-ware
Next, I am stuck on Android 9 forever, I would like to try android 10/11/12 especially if the moto mods and gestures are still working. Really, just android 10 would be great, the only thing I really want is darkmode notifications and settings !
After that, if there are roms for those, I would like to try lineageos, grapheneos, pixel experience and the other popular firmwares that are made for many phones.
I would like the fastboot and adb windows 10 offline drivers to remote control all aspects of the phone. (I will be using many of those phones as wifi cameras and I'm trying to reliably stop and start recording 240fps video with wifi remote control)
Oh, and I would like to try just plain linux on those phones, if that's even possible. Even if that's just cpu/ram/wifi. I'd like to use one of them as a mini server
I think that's pretty much all I want to try with these phones, do you have advice on how to do this on Moto Z3 non-play ?
Thanks !

you cannot run linux on android smartphone, except you're talking about "linux" on top of "android kernel" which still provides full hardware HAL access. the overhead is nearly the same as running android, so no point in this. but here you go.
https://docs.ubports.com/en/latest/porting/introduction