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.
On Omni 4.4.2 I'm trying to get Wifi Direct working for both file transfers and as a required part of screen mirroring and found this post that describes a fix that is out of my ability to test (my computer shuts down from heat every time I try building a rom or any big compile)
I just would like to bring it to the attention of of a actual OMNI developer.
http://forum.xda-developers.com/showpost.php?p=49775086&postcount=28
Have you actually tested that fix? Re-enabling that if just means that it won't return an error when Wi-Fi Direct isn't supported. So you might not have your "failed" message, but it wouldn't work either (unless samsung magic).
I would test if I could but my laptop is getting old and now shuts down from heat issues when doing big compiles. Which that post says is needed.
I really don't know much about that fox other then the guy that posted it also made a Wi-Fi direct test so so I assumed he was good on the subject.
I sort of recall ages ago on n801x that there was a small p2p_supplicant arguments fix needed for that device... there might be a similar fix needed on the galaxys2-common family.
Shouldn't need to fix the supplicant source code itself though.
Just haven't had time to play with this.
Hi Everyone
I flash a lot of roms on my phones, and same with the Mi5.
Since nougat update of MIUI, the wifi speed drops to 30kb/s at times while other devices get 4mb/s. To test I have ran speedtest by okla at the same time, and results differ with PING and DOWNLOAD SPEED.
Though it can be fixed temporarily by toggling airplane mode on and off.
Since then I have been trying different roms like: Lineage, Mokee, AOSP Extended, MIUI Global Dev, Global Stable, MIUI China Dev, China Stable. No luck in any of them.
However i flashed the android 6 of Mokee which ran perfectly for 7 days then had the issue, while other have it from day 1 of flashing.
Took the device to service center and stupid stuff like, we cannot find log file of your phone. Please take it to other service center.
I know this is the home for talented people, who can help me. Please suggest ways to fix it.
P.S:- Also tired of TWRP Error 7.
Thanks
Hello
Background
I have a OnePlus 3 since Nov 2016. The phone is awesome. But doesnt play well with Android auto when using with custom roms. Atleast on my car, a Mahindra XUV 500.
In the initial few months, there was an issue with stock rom too, but OnePlus solved it and the stock rom works brilliantly with Android Auto.
What is the problem?
On custom roms - every time i connect my phone using the stock OEM cable to my car, android auto is detected and the headunit displays the interface. This lasts for a few seconds to a few minutes and Android Auto disconnects.It re initiates and the interface displays once again, only to disconnect once again. This goes on and on in an endless loop.
On stock rom - no problems. It stays on rock solid.
What have I explored so far
I have tried to triangulate the issue using circumstantial evidence. But there is nothing that consistently triggers this issue. I have tried:
- changing Roms [have tried 8-10 roms, all have this exact issue]
- changing cables [stock, aftermarket, et al. no luck]
- allowing all wakelocks in custom kernels
- disabling USB fast charge
- disabling charging all together
- enabling disabling various usb modes - debugging, mtp, ptp etc.
- upgrading/ downgrading Google play services and other google apps
- various quirky tweaks - with sim, without sim, display always on, etc etc.
There is no trend noticed whatsover
What works?
The only time the connection is stable is when there is activity happening on the screen. Which means, if there is active navigation through maps or music is playing or notifications are flowing. This is the only time when android auto does not disconnect.
My Theories
My conclusion is that there either some form of communication that is happening which keeps the connection going or there is some wakelock that is preventing the connecting from disconnecting.
It could also be something to do with the charging current. Stock rom usually forces the permissible limits but custom kernels push the limit on the amperage. But note that disabling USB fastcharge has no impact. So it could even be the normal USB current as included in the kernel.
Proposition
I am willing to offer a bounty to any developer who could help me by pin pointing the commits that are required to make custom roms/ kernels work. I am very confident this is possible because stock rom already has made it work long back.
Since the demand for android auto on custom roms is quite low, i dont find too many users talking about this. But i use AA extensively - couple of hours each way on my commute and i want to stick with custom roms. Hence this request and offer.
My initial offer is for USD 50 to whoever can help do it first.
Resources
the oneplus commit that they claim made AA work back in the days of N:
https://github.com/OnePlusOSS/andro...mmit/33a109bb360e89182a0db0b00e0650b1b915f4a2
look for the description that says "usb: change product name to OnePlus for Android Auto". After this the stock rom has been rock solid. Also note that this change did not find its way into the Oreo source code. No clue why. This only points to the fact the problem is elsewhere.
Example custom rom source, for reference, which doesnt work:
https://forum.xda-developers.com/on...ice-development/rom-nitrogen-os-beta-t3737654
https://github.com/nitrogen-project/android_kernel_oneplus_msm8996
PS: I hope this finds some takers. Really hoping!!
Will try to post a video later today.
Cheers!
Hi, I have been using the xiaomi.eu rom on my Mi 10 Ultra for quite a while, it works fine in most scenarios but when it comes to functionality that is important when using the phone for calls, photo AND as a tool at work..... I have got rather frustrated with important bugs that never gets fixed even if I report them.
Has I been unlucky or is this "normal" when using xiaomi? (previously I have been using Samsung and Huawei and then I have never had theese problems)
The reason for asking is that I WANT to buy a Mi 11 Ultra but if that means: Top hardware, excellent camera and a lot of issues when it comes to using the phone for work => Need to choose something else.
Examples of issues:
* If I try to share a file over "teams", the phone (falsely) suggests that I'm not loged into my work profile and ask me to log in to that profile. However it is not possible.
* In similar way, it is IMPOSSIBLE to change keyboard layout on a physical keyboard. I can go into the menu but the changes I make are ignored. I live in Sweden but I can see on the internet that people in France has the same problem. Bug reported long time ago but no fix and no response whatsoever.