States also regulate 911 service. Try your state's office of emergency services.
There's something called "Kari's Law" that may apply here. This was passed in 2018 after someone was being attacked in a hotel room and their 9 year old daughter tried to call 911. She couldn't get through because the phone system required dialing 9 for an outside line. So, now, all business phone systems are required to recognize and pass through 911 to the main phone network. There are criminal penalties. (Microsoft might argue that "Teams" is not a "multi-line telephone system". That probably wouldn't go far with a jury. The clear intent of the law is that if you interpose something between a phone handset and the 911 network, it has to pass through 911 calls.)
The whole 911 area is heavily regulated, since it requires that so many things interoperate reliably.
Microsoft might argue that "Teams" is not a "multi-line telephone system". That probably wouldn't go far with a jury. The clear intent of the law is that if you interpose something between a phone handset and the 911 network, it has to pass through 911 calls.
Google may blame Microsoft but there is no way an app should be able to disable 911 calling on a phone. This means that other apps could disable 911 intentionally. This is Google's problem to fix. A phone OS needs to guarantee certain things and 911 is one of them.
Half of Google's response is corporate speak that plays down the issue. The priority here should have been to explain and disseminate the workaround, not to start with several sentences of establishing that the blame must be shared.
> We will also be providing an Android platform update to the Android ecosystem on January 4.
They postpone the fix to the next regular patch release, while fully knowing that other apps could trigger the same bug, including malware. This is criminal negligence.
Google also has the power to immediately disable Microsoft Teams on most Android devices, until the fix is rolled out. They are taking down apps for dubious reasons all the time. But when a popular app triggers a life-threatening bug, then let's wait for them to issue an update, here are some tricks to avoid the bug, don't forget to tell grandma.
> The priority here should have been to explain and disseminate the workaround, not to start with several sentences of establishing that the blame must be shared.
Below is one of the comments on the original reddit thread that gives more context of how this could happen. u/rbrome on reddit thread[0]:
Teams is a wide-ranging service that includes VoIP phone service. I believe it is designed to replace your company's phone system if you want it to. So it makes sense that it registers with Android as a VoIP service.
There are situations where someone might want/need Teams to handle a 911 call. Perhaps you have an Android device with Teams that's designed to be a campus-only phone, without cellular service. Any device that presents as a phone and can make calls, is required by the FCC to be able to complete a 911 call.
>Perhaps you have an Android device with Teams that's designed to be a campus-only phone, without cellular service.
I feel I don't care about vanishingly rare use case of a wifi-only Android device on a campus network. If a device has a cell phone radio in it, it should be able to make a 911 call, and letting an app block that is inexcusable.
>> Perhaps you have an Android device with Teams that's designed to be a campus-only phone, without cellular service.
Unless it lacks a cellular radio entirely, I find it unlikely that voip would be a better option than cellular service on any college campus I'm aware of.
Take a Nexus 7 WiFi with teams installed. It can do phone calls. It can’t receive cell signals. It has to be able to handle 911, by passing them through to teams.
Yeah, but the device really ought to make a 911 call using the cell radio if at all possible (i.e. it has a cell radio with a signal), and only fall back to third parties if not. This is different from the normal call flow, where you might delegate all non-emergency calls to the third party.
Disagree. They provided context allowing people to understand the reason for what would otherwise seem a bizarre set of steps that seem to cure the problem in the meantime. It's clear and direct.
Context can be provided without all the filler expressions that play down the issue as the sentences progress. By the time they arrive to the workaround, this is how they continue:
> Out of an abundance of caution, in the meantime, we suggest
Does that suggest urgency to you?
> Because this issue impacts emergency calling, both Google and Microsoft are heavily prioritizing the issue, and we expect a Microsoft Teams app update to be rolled out soon – as always we suggest users keep an eye out for app updates to ensure they are running the latest version. We will also be providing an Android platform update to the Android ecosystem on January 4.
I believe heavy prioritization shouldn't involve planning to wait an entire month to issue an Android update.
So how does their "clear and direct" statement help those who happen to have their phones in this bad state, don't realize it because they haven't had to call 911, and haven't read this statement either?
Seriously, the cryptic statement could mean your message above should have called 911 instead of letting you enter the digits 9, 1, 1 into a message
this highlights that phones are now multi use. What's "making a phone call" is no longer clear. I "call my friends" via zoom/meet/fb messenger/line/slack/discord. I don't use phone numbers to call people. are all those varied services required to handle 911? I can "call people" via dating apps. Are the also required to handle this situation?
Federal regulations are not something you want to be afoul of. Think of Eye of Sauron, but with the ability to take your money, and not for a reason you respect.
I can understand disagreements over the wording and how it's interpreted, but would you at least agree that Teams should be disabled or removed in some manner, until the bug is fixed?
Personally, I frown on Google/Apple/whoever mass disabling apps for all users without warning, but if there is ever a case for a mass disabling, this is absolutely it IMO.
> Google also has the power to immediately disable Microsoft Teams on most Android devices, until the fix is rolled out.
This seems heavy handed and unreasonable. Disrupting millions of people's lives to fix an unusual use-case (even if it might be life or death) is not proportionate.
Only in our dystopian software hellscape where we rely on software for absolutely everything, but get considered a rube for expecting anything to actually be reliable.
They could disable the app only on devices that Google believes are impacted, not to mention not waiting an entire month to release a platform update that would fix the root issue.
> They would have to essentially take down Teams on android.
Yes, and Google product managers can always choose to not act immediately, continue to allow the disruption of emergency calls on Android devices until the next app and scheduled OS update, and become felons.
> Google may blame Microsoft but there is no way an app should be able to disable 911 calling on a phone.
Google runs a battery of automated tests on any app before admitting it to the Play Store. A part of this testing should be simulated 911 calls. Failing to do so could open Google to liability through negligence.
The law mandates the functionality. How to enable and test this functionality is the responsibility of the carrier. Whether the compliance is achieved by testing third-party apps or via an in-house bypass implementation is immaterial. On the other hand, assigning liability for non-compliance is tricky and for Google the jury is still out (pan intended).
Android is a general purpose embedded OS, it's not just used on devices with cell radios. It doesn't manage the BP (cell phone processor) either afaik.
For example, a voip android desk phone - it relies on voip to make calls. Android is agnostic about it and allows third party software to handle underlying calls, whether it is Qualcomm/Samsung/etc software for cell calls or Microsoft Teams for VOIP.
There isn't a straightforward approach here for Android. It's not like iOS where Apple owns the entire software stack, including modem software.
I wonder if this is a result of various ways microsoft software is trying to force users to login to a microsoft account. If so the problem will be systemic as the microsoft programmers will be in an ongoing battle to disable as much unrelated stuff as possible.
Reading through the reddit threads, yes, that seems to be exactly what happened. Without being logged in to MS Teams, dialing 911 caused the phone's calling function to crash.
Every once in a blue moon you get logged out and need to log in again. Teams seem to cache some stuff and not others so in that case behavior isn't exactly intuitive.
I am not the least surprised that it trigger crashes.
On Mobile, I do it with a browser "Show Desktop Version" and click on the "Continue on this browser" option. This is only an option when one doesn't need to fully participate in Teams, which is the case for me.
I do not currently use a Microsoft account for anything. I have one, and once in a while, I log in with it for some reason or other.
Everything else is a Office 365 account tied to an email provided by the people funding that access.
For me personally, using OSS gets the job done for all my computing needs otherwise.
Not last time I tried. That flow (i.e. you are not part of/logged into an institutional Teams account) is completely broken. Teams makes you go create a free Microsoft account, which then doesn't work to log into Teams.
Personally, I would argue that if Teams is able to somehow interfere with dialing 911 from outside of the app, that's a major Android bug much more than a Teams bug. --The last thing you want is any app to be able to interfere with emergency calls whether it's intentional or not.
But Microsoft is certainly not going to try and argue that Teams doesn't have to be able to make emergency calls, at least not when it's used as a VOIP solution - they have plenty of documentation to help ensure emergency calls are routed properly: https://docs.microsoft.com/en-us/microsoftteams/what-are-eme...
> Personally, I would argue that if Teams is able to somehow interfere with dialing 911 from outside of the app, that's a major Android bug much more than a Teams bug. --The last thing you want is any app to be able to interfere with emergency calls whether it's intentional or not.
Ironically, Microsoft wrote a lot about compatibility in Windows and all the tricks they used to make sure apps that were using APIs wrong (or just flat out pulled crazy stunts to hook themselves into Windows) could still run fine even on newer versions. Sad to see Google didn't apply the same engineering principles and are trying to shift the blame. Maybe because most Pixel phones are outside of their two years of updates...
> But Microsoft is certainly not going to try and argue that Teams doesn't have to be able to make emergency calls, at least not when it's used as a VOIP solution - they have plenty of documentation to help ensure emergency calls are routed properly
Teams can also run on devices where it's maximized and the only app available from the UI (think conference rooms). In this case it makes sense for it to handle emergency calls. But on Android where the user can be signed-in to N different phone apps at the same time? Not so much.
This is probably the most preposterous take I’ve seen about this situation. “It’s my phone!! If I want to disable 911, I should be able to!!!” What ridiculousness!
There are so many regulated, built-in fallbacks to ensure anyone can reach emergency services from any cellular device that is within any network range. You don’t need a SIM, an active plan, and you don’t even need to unlock the phone first.
Google should be handling emergency services calls on the cellular network, and should have always prevented any third-party software from interfering.
More like "Google AI murders user, sends notification to Android phone."
"Android 14 is here! Android 13 had some bugs that led to an inadvertent use of deadly force. The error has been rectified and lethality should decrease in this version."
"A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one."
Unfettered capitalism says that the corporation has no conscience and if it can clear responsibility for the death with an out of court settlement, then that's it done and there's no further business.
The obvious fix is some kind of government/regulatory involvement that introduces additional fines/costs for bad behaviour, whether specific to endangering the public or more broad. And of course, sometimes this is upfront standards stuff like we have for emissions, lighting, seatbelts, etc, whereas other times it's prosecuted as a negligence charge after that fact.
In my experience, the feds don't have the resources to investigate many of the things that the law says they can/will. Usually they look at the most egregious ones, it takes a long time to get around to it.
The short answer is it doesn't, it just dials 911.
Way, way back in the day when dial-up was a thing, I worked at a company that had an automated system that called a large bank of test numbers to make sure they were still working. This system ran 24/7. It required you to put in the numbers as <areacode>-<number> without a prefixed 1. The code would add the 1 automatically. Because it operated in a lab inside of our phone system, it dialed 9 to dial out. Well, at some point someone had to reconfigure this system and I guess thought it would be good to add a 1 before each # in the configuration.
This resulted in thousands of 911 calls being made to our local call center. We had accidentally created a 911 war-dialer.
The moral of this story is don't dial 9 to get an external line. You're literally a keystroke away from calling 911 every single day.
As with any short answer the real answer is “it depends”.
Any modern internal phone system has a dial plan and the default will certainly call 911 but you can certainly change it.
I used to work inside a call center where you had to dial 91 to get an outside line. You can imagine how many people accident dialed 911. Since we couldn’t muck with 911 we made outbound dialing straight from the sip client only and not through the handset and told people not to dial outbound to order lunch or whatever from the handset. We didn’t care about them ordering lunch just couldn’t muck with 911. But that being said I could have most certainly changed the dial plan instead and screwed with 911.
This is a classic in America when calling Europe or International.
The dial out in corporate, usually you used 9. Then you google how to dial in Europe because the numbers are not natural. Google mentions dial 11 + country code + phone number.
So people hit 9 to dial out, then 11 to dial in Europe. Instantly you hear: Emergency 911, is this an emergency?
No, 9011 is correct. "011", the international exit code for calling from the US, is what the + gets mapped to in a number such as "+49 xxx". It is followed by the destination country code (which starts with a 3 or 4 for Europe [1]), and then the local number. So for example, to call a number in Germany from a PBX in the US:
9-011-49-(German number) [3]
For long-distance domestic, the national trunk prefix should be used instead. For the US, this is 1 (unrelated to the US country code, which is also 1):
9-1-(10-digit US number)
For local calls, you do not need the trunk prefix, so you would dial:
9-(7-digit US number)
However, no US (or North American) area code nor central office code starts with a 1 [4]. So even in the above two cases, the sequence "911" should never occur.
The rule is really simple: If you dial 911, you must be immediately connected to the emergency services. This means that there cannot be any other number that starts with the prefix 911. If this means that you have to shuffle around what number you use to call an external line, then you just have to do that.
They upgraded our PBX so that you can just dial the number as it is and the software figures out internal or external or 911. The 1 key on a lot of our phones was bouncing so 9-1-800-bla-blah would turn into 911 way too often. So they changed to not require the 9.
Bizarrely, my work office phone (at a US Federal agency no less) was switched from 7 for an outside line to 9 just before the pandemic hit. People really like 9 for some reason.
And no 'special' ones (like 911)? e.g. 112. Relatedly, countries usually implement each other's codes for tourists' and children who watch foreign films' benefit - 999, 911, and 112 will all work in the UK for example.
And when you say area codes [can't] start with a 1, is that only when you include a 0 prefix?
Country codes can start with 1. There doesn't seem to be a +11~, but is it forbidden? Are there no US or Canada (+1) numbers that start with even a single 1?
Depends on what you mean, but there are no 1XX area codes in North America, so there is no reason you’d ever dial 9 (for outside line) 1 (country code) 1 (first digit of area code).
> Country codes can start with 1. There doesn't seem to be a +11~, but is it forbidden?
No country code (or phone number) can be a prefix of another. There cannot be a +11 country code, since after the first 1 you are already within the NANP "country" (and it seems the NANP rules disallow area codes starting with 0 or 1, so the next digit can only be on the 2-9 range).
The North America Numbering Plan does not allow any (normal) phone numbers that begin with the area codes 000-199. So there can be no valid numbers that are of the form +1 (1nn) nnn-nnnn.
(There are special dialing codes like dialing 011 for international that are an exception to this, but no normal phone numbers.)
That's what I meant by 'special', say you had a 118 for some other purpose, you couldn't dial it (unless also special cased as not needing a 9 dial-out prefix) as 9118.
> There doesn't seem to be a +11~, but is it forbidden?
Well, kinda... The thing is, even if not required by standard (It is, there's a Numbering Plan for the US and Can), most 9-to-dial-out systems would fail to call such a number, redirecting 911-anything to immediately dial out 911 once the second 1 is dialed.
IIRC, I've seen POTS also skip the inter-digit tone wait (the time between your last dial and the system going "okay, that's all the numbers, let's call!") when calling x11 numbers, generally considering "911" and other emergency/service numbers to be a magic triple that doesn't wait for other numbers to dial out.
There are no area codes starting with 1 in the US nor Canada to my knowledge since any dialing in a system with 9-to-call-out should end up being dialed as follows :
* 9 (leave system)
* 1 (country code)
* 1 (first digit of the area code)
And there is no step 4, because 911 is a special number like 411 and 311, that has a special dial plan. Since there is a possibility of issues if we make the treatment any less dumb, we don't do that. 999 is a special, unassigned code in the US too. 112 is likewise impossible to clash with here in NA since calling that with a corp system just means typing 9112, which ends up being 911, and dialing it on its own can also be allowed to be a special case since there are no area codes with 1 because of 911.
In fact, even "small area codes" or, officially, "office codes" are also required to not be X11. You used to be able to call locally in your area code without dialing the area code, too. It ends up being that xxx-911-xxxx is also an invalid number. Because locally, you would have had to type "911" to start dialing that number. There are also other limitations that can be seen here as well as allocation for future expansion :
https://en.wikipedia.org/wiki/North_American_Numbering_Plan#...https://en.wikipedia.org/wiki/North_American_Numbering_Plan_...
There's also probably a physical, legacy reason it's probably much more difficult to make a physical 911 switch when "911" is also a valid part of a phone number. It means you need to figure out "Is it what they meant, or are there more numbers coming?" It means the sequence of operations "<open line><9><1><1>" always means emergency, fast connect, and probably easier to implement as a side-channel than as a part of the dial logic? This is speculation, I haven't actually opened a POTS PBX with a physical implementation of the 911 dialing logic.
Do you really think Google gives a damn about the FCC, much less the state governments? They'd probably just ask them to submit a feedback request with a screenshot.
Why raise hell about this? There is an issue in Android/Teams/inbetween, a user reported the issue and all involved parties acknowledged the issue and are "heavily prioritizing" fixing the issue.
What would filing a complaint improve to this process?
Because it should never have gotten to this point. They are lucky that somebody has not already died.
> What would filing a complaint improve to this process?
It would encourage proper testing, and proper development practices that would prevent such a bug from occurring. Why was the system so poorly designed that Microsoft Teams could cause a hang during a 911 call in the first place?
At least in vehicle infotainment systems, we test 911 functionality EXTENSIVELY. It's a major part of call testing, because dialing 911 overrides all sorts of lockouts and exercises code paths that aren't otherwise well-covered by testing.
Usually there's a hidden config register where we can change "the number for 911", so for some portion of testing, we'll set that to "Chris's phone" and inundate a coworker with calls, but once we've been through a shakedown with that, it's time to coordinate with the local PSAP and identify a slow time when they can field some real test calls from us.
There are all sorts of safeguards here -- they want a regular phone number for one of the testers, so if the test phone malfunctions in any way (say, calls complete but audio doesn't open), they can reach us out-of-band. And it's always perfectly clear that they can cancel the activity at any time, if enough real 911 calls come in that they don't have spare operators for our testing.
It's been a long time since I was on the carrier side, but I remember doing tower turn-ups, we'd also place one test call per carrier-sector, to make sure the location info was transferred correctly. Similar coordination but it was largely a formality because it was usually just 3 or 6 calls, and very brief ones at that.
In the instant case, both the phone maker (Google) and the carrier (unsure) should've exercised this in their acceptance testing. Since it sounds like a Teams bug, it's understandable that they didn't catch it, but also unacceptable that Teams could interfere with the ability to dial 911. Since we've now learned that apps can interfere with that, this hugely balloons testing requirements until/unless they fix the OS so apps cannot interfere.
> At least in vehicle infotainment systems, we test 911 functionality EXTENSIVELY. It's a major part of call testing, because dialing 911 overrides all sorts of lockouts and exercises code paths that aren't otherwise well-covered by testing.
When I worked at Motorola doing mobile infrastructure, you couldn't even merge your code into a release candidate branch unless it was tested against emergency calls, for all the reasons you listed (plus more).
We used giant attenuators screwed on to the antenna plugs because everything had to be running at full power to ensure that it was as life-like as possible. Every once in a while, though, someone didn't screw the attenuator on tight enough and the emergency call would be picked up on the real mobile network and the fire department would show up in our parking lot.
Where are they playing it down? I know it's easy to blame compagnies. OP open a post on reddit saying that 911 does not work, did he contacted Google support? No.
There is most likely an issue but we don't really know what it is. how do you know it's not on the Verizon side?
Most likely half the 911 calls in the US are made from Android phones and we never heard of common issues.
from post: "I also contacted Google already, but haven't heard back. Also shout-out to whoever pointed me to the FCC as I'm filing the too.
Google Support reached out to me through here -" (not contain all sentences)
he had contacted Google support, but unfortunately, he do not get response now.
any response other than 'this is a bug in android and we are working 24/7 to release a fix' is playing it down. this is the emergency number. kids in kindergartens learn songs about calling 911 or 112.
i know it isn't a verizon problem, because google tried to blame teams.
Google should have built in some mechanism which verifies that the integration from Teams can't prevent calling 911 - either as part of Play Store verification, or as a general test of their system (they delegate to other apps, if these fail or hang the native mechanism should take over).
Having something that can screen calls for spam, something that can stop you accidentally dialling a premium rate number and getting an unexpected large bill, or something that can intercept a call and route it over a cheaper VoiP connection is really useful.
It needs to be a carefully managed feature, but it's certainly not "zero need".
911/112/etc. calls should just not be screenable or blockable by apps or susceptible to third party app crashes. They should be short-circuited to just happen on the default phone app, with little possibility for any interference from apps on the system.
> Because it should never have gotten to this point. They are lucky that somebody has not already died.
This is such a stupid argument, so out of the billions of android phone, it should never never happen? If you don't want hardware / software to fail never use it then.
Next you use a landline phone, for some reason 911 does not work, oops. But I was told 911 should work 100% of the time.
> This is such a stupid argument, so out of the billions of android phone, it should never never happen? If you don't want hardware / software to fail never use it then. [...] Problem will always happen to some degree.
And this is an even dumber argument. Yes software can fail, but a critical piece of software like this should have as few failure modes as possible. This bug would have been preventable through proper design and testing. There is no good reason to allow any third party integrations to interfere or become involved with dialing an emergency number, and oh so many reasons to outright forbid it.
You wouldn't pass a bug in a pacemaker off as "oh, shit happens". So why would you take that stance on a bug may prevent people calling emergency services in a potential life or death situation? Are you even listening to yourself?
This is critical software and it needs to be tested. Tested properly. It's thinking like this that gives software engineering a poor reputation as a discipline and leads to incidents like the Therac-25.
“All parties acknowledged and prioritising” is a fine state of affairs for a “file sync ate my data” bug, but you don’t get to sweep a potential criminal issue under the rug like that.
Right now it only one of the bug among thousands of others bugs in their bug tracking system, By raising hell with fcc, After penalty and rapping from fcc Organizations legal department will get involved, they will make sure this gets required attention. Will ensure this is one of the must check/test before shipping product/app.
"heavily prioritizing" here means Google doesn't currently plan to fix it until some date in January, from what I read in their response to the Reddit post.
> "heavily prioritizing" here means Google doesn't currently plan to fix it until some date in January
Like Microsoft with Windows, Google releases their security fixes for Android monthly. And January 4 is obviously the date for the next one (it goes out at the beginning of each month, and AFAIK the December one has already gone out). So the fix (which might even be ready already) is going to be released on the first opportunity.
This is not a "security" fix. This is a health and safety fix.
This is at the same time as we head into a) the holiday season in much of the world, b) winter in much of the world, c) an ongoing pandemic that is dealing with the spread of a new variant and the roll out of not only initial vaccines but also boosters.
Having emergency calls not go through because of a bug needs to be fixed immediately, not subject to some update cycle.
If the issue is health & safety, and the dangerous failure mode is pretty rare - then how much time should be spent in validation, testing, etc. - to make sure the fix you rush out the door ASAP does not actually make things worse?
From what I understood, it will be fixed immediately, through an update to Microsoft Teams. The underlying cause (which can be considered a security fix, since it should not be possible for a non-privileged application to interfere with that mechanism) will be fixed by the monthly Android security update.
To prevent this from happening again. To force their hand to ensure that their incentive structure changes to test and verify emergency calls _first_ regardless of how long it takes even if it slows revenue generation before releasing their products to production. To hold them accountable to society for brazenly ignoring one of our major rules while still selling products pulling in a ton of cash. Lots of reasons to raise an official complaint. So they don’t just get to walk away with an “oops my bad”, much like many of us wouldn’t be able to if we messed up big time.
It’s not like this is some random Joe shop that missed a small feature. This is Google and Microsoft, two of the biggest tech companies out there, making billions while not even caring to follow society’s rules (move fast and break things right? All in the name of scaled super fast profit)
Every app vendor who sells a phone product in the US? Uh, yes? It’s the law. 911 Call centers literally make testing available for this. And all you really need to test is that you’re making the outbound call properly without shit hitting the fan.
What’s the alternative? Just have 911 calls fail every once in a while since everybody is too busy with their feature work to look into it?
I feel like you’re being obtuse. They would need to verify that the call can be made and make it out the phone to the network, not actually make the call to a 911 operator. This can be part of an automated test suite even. Just ensure specific phone numbers cannot be intercepted by applications and diverted.
@nikanj since I can’t reply directly to you. I would say you don’t worry about that, what purpose does your app have intercepting it? It should be something that the OS picks up on, and handles. If you are writing a dialler, you should be confident when you hand it off to the OS that it won’t pass it along to another app. I’m not sure why the radio portion is relevant when the issue is that Teams intercepted the call and caused it to fail. It never made it off the phone.
> If you are writing a dialler, you should be confident when you hand it off to the OS that it won’t pass it along to another app.
I've no idea how exactly this bug happened and therefore whether the following has any relation to that issue or not, but if you want VOIP apps and similar things to work, you do need to allow the "I've got a phone number and I want to place a call" step to be intercepted, because otherwise how are you supposed to make a call via VOIP etc. when selecting a number from your contacts list, a phone link in a browser, etc. if that step was hardcoded to the regular phone app?
There's a difference between a phone call, and an emergency phone call. The documentation for the ACTION_CALL intent even says that emergency calls won't work for the intent.
Android already differentiates between normal calls and emergency calls. Normal will be intercepted, emergency shouldn't be. And an emergency call is required to still work even if a SIM card is not present in your device.
No, I'm not. Android's documentation says it handles emergency calls through a separate workflow. The law requires Android to handle emergency calls through a separate flow. Neither of those things is predicated upon a cell connection.
Emergency is required to work a certain way, by law, and is documented to work that way, but didn't happen in the case of this bug. The OS is responsible for emergency calls, the dialler, which may be third party, for normal calls.
How do I, an lone app vendor, verify that my call makes it out of the phone, or abort it without 911 noticing a dropped call? The radio+network part is a black box from my perspective
PS: At least where I live, emergency services will show up at your house if you make a few 0-second 911 calls
You can contact your 911 call center through a non emergency line (numbers available here when you enter your state/region: https://www.nasna911.org/contact-911). You can then call and set up a time window for outbound test calls to be placed where they won’t send emergency services.
I've worked on some custom Android firmwares before, and I did this for our releases. It's easy, the 911 call center doesn't mind (it's scheduled beforehand), and it ensures that the phone can dial 911. If you can't manage to test emergency calls, don't release phone software.
Yes, that's the clear and obvious answer. We have regulations around things like being able to make 911 calls for a reason, because it's literally a life and death issue. Nobody should be making or selling a call-hijacking app if they can't perform even the most basic level of testing to ensure 911 calls still work.
You call the PSAP's non-emergency number and ask to schedule a few test calls. If you don't know how to reach them, call your local police non-emergency number, they'll be able to put you in touch.
You're supposed to do this when setting up new VOIP service too, to make sure location information is reported correctly. It's quite a normal thing and they're not at all surprised by it.
I would go so far as to say there are 2 types of phone people: Those who've placed a lot of 911 test calls, and those who're placing their users at risk.
Can’t seem to reply any deeper on the thread, but also I never specifically mentioned CI. The only rule is that if you release a phone app, 911 has to work 100% of the time, no exceptions. That is the law. Also, this is Google and Microsoft, both of whom have basically unlimited resources. However they figure out how to do it reliably is up to them. Note that no other apps or service providers seem to be out of compliance.
Emergency calls working as expected is a live and death issue and I don't think you'd be so blasé about this if it had been you vainly trying to call 911 and someone you loved died because of this bug.
I assume you see this through the lens of "bugs happen, as long as developers make a sincere effort that's fine" under which most software development takes place. But this is absolutely the wrong way to look at this, and I bet you wouldn't apply this framework to physical engineering artifacts which are subject to legislation ensuring safety standards like bridges, cars or heaters.
It's a life critical system, so it shouldn't need to rise to malicious intent. Regulators don't handle malicious intent, they handle negligence. Police handle malicious intent. Look at Takata air bag recall. No malicious intent but regulator had to step in order a larger recall.
Negligence in testing also needs to be disincentivized.
If they've BUILT a system where apps can interfere with the ability to place calls, AND NOT written appropriate exceptions for 911 calls to bypass all such interference, AND NOT tested such exceptions, then there's a huge problem. That is absolutely the regulator's business.
I can't speak to the way modern phones are designed, but in earlier ones, 911 calls have all sorts of special status. They override pretty much all the phone's self-preservation mechanisms:
Transmitter deck too hot, normal calls can't be placed? 911 overrides that; the phone will melt itself if that's what it takes to get your call through.
Battery too low, normal call would be dropped so the phone can shut itself down without corrupting its flash filesystem? 911 overrides that, it will run until the circuitry physically ceases to function, in case that buys you a few more minutes of contact with the operator who might save your life.
Power control? Some phones would allow higher wattage when docked in a car-kit, but limit themselves to a lower power level when hand-held, to comply with tissue absorption regulations. Guess what limits go out the window when you call 911! Of course it's not gonna use the power unless it needs it, but if weak signal would cause a normal call to drop, 911 calls can tap into extra capability.
They will do ANYTHING to make that call go through.
And for software to fuck it up in the name of some obscure feature that clearly didn't get adequate testing, is unconscionable and spits in the face of literal decades of engineering effort.
> We determined that the issue was being caused by unintended interaction between the Microsoft Teams app and the underlying Android operating system.
As someone whose organizational policy signs my Teams client out after a couple hours of inactivity, I would love to know how on earth this is possible. I truly am at a loss, and I am furious at the thought that I have been unable to dial 911 for who knows how long.
At least I know the ten digit number for my local emergency services, but the average person probably doesn't. This is unacceptable.
They need to release more technical details on this to restore confidence. How can a sandboxed user installed app with limited permissions cause dialing 911 to fail? How do they know other apps won't cause the same issue?
And they mentioned an Android update, but what about the millions of Android phones that aren't getting regular updates? Does that mean there's potentially millions of phones that can't dial 911?
I like Pixel and Android, but am seriously thinking of switching to iphone because I really need a phone I can trust will dial 911 when I need it.
What's really terrible here is that Google are saying they won't fix this until their regularly scheduled January release.
SERIOUSLY..... They won't rush a fix out for this? Not even for this??? Unbelievable.
Note that Google is no longer providing updates (/maybe/ one more in 22Q1) for the OP's Pixel 3, a 3yo device which is otherwise still a great phone. It's simply not good enough. Google needs to support their own phone past three years and be the example to others that ship Android devices. How long are we going to ignore it and let those who can't afford a new phone every couple of years be left exposed?
Looks like it's only impacting phones from 2019 onwards and in very specific circumstances (still not great at all but a very specific bug):
If you are unsure what Android version you are on, confirm you are running Android 10 or above by following the steps here. If you are not running Android 10 or above, you are not impacted by this issue.
You are also not impacted if you have teams installed and are signed in:
If you have the Microsoft Teams app downloaded, check to see if you are signed in. If you have been signed in, you are not impacted by this issue, and we suggest you remain signed in until you’ve received the Microsoft Teams app update.
If you have the Microsoft Teams app downloaded, but are not signed in, uninstall and reinstall the app. While this will address the problem in the interim, a Microsoft Teams app update is still required to fully resolve the issue.
We advise users to keep an eye out for an update to the Microsoft Teams app, and ensure it is applied as soon as available. We will update this post once the new version of Microsoft Teams is available to 100% of users.
That we know of. If Teams can cause this, surely other apps can also. Moreover, who's to say there isn't a much larger number of people who've been affected by this bug that haven't reach out to Google to file a complaint and bug report. (Or couldn't, possibly because they died while trying to call emergency services.)
The thing is, it's clearly not as simple as "Has MS Teams installed", I mean the bug itself is not due to one specific piece of software, but rather that software advertising itself to the OS in a certain way.
Making a call to emergency services shouldn't be able to fail on hardware with a mobile phone modem. If Android allows apps to provide the capability to do that, then the OS must take responsibility for the app actually being able to do so, if the dialer tries to call an emergency services number, and whatever app is prioritised to take care of that fails, then the next one in line needs to be called upon, until we hit Android core functionality which they have verified beforehand can actually perform the task (given that there is a mobile phone modem on the platform in question, but perhaps this could be done over the internet as well, in which case that isn't even a requirement).
Blaming this on shitty code by a third party is not acceptable.
> Google needs to support their own phone past three years
It's not really Google's choice. Qualcomm gives up on their SOCs pretty quickly and unlike on Linux Android's license doesn't force them to publish driver sources.
And what if there is another app that causes the same bug? Teams doesn’t have any special permissions so one has to assume there are more apps out there that could be a problem.
Scrolling through the permission list on teams, there's a whole bunch I don't usually expect on most apps, ie. "Route calls through the system" (id imagine this is the one needed to implement voip service on top of android).
And it gets even worse for apps that can create corporate profiles so they can be administratively controlled remotely by the corp. That's next level of permission bs one has to give up to.
I do get your point that they’re uncommon requirements but my point was Teams doesn’t any uniquely granted permissions that Google have backdoored for Microsoft. So it is entirely possible that another app / VoIP client (or even malicious actor) could prevent emergency calls.
This is what I am reading also. Couple that with another similar and recent bug discussed in the reddit thread this links to (https://www.androidpolice.com/notifications-feeling-sluggish...) and I'm starting to wonder if there isn't a whole host of unnoticed side effects in peoples Android devices.
These are failures on the Android level, apps users can download from the store shouldn't have the capability to break things like calling emergency services, or notifications for other apps.
And that's not a standard permission, have to go to All Permissions to see it, and I don't see a way to remove that permission, or find all apps that have it
trying to avoid the trap you speak of: I've submitted a case to my corporate technology department with the permalink to Google's Reddit reply partly so the enterprise can't say they knew nothing about this defect (and I cc: my manager).
If that's the only solution/workaround, I guess Teams should be banned from Play Store and existing Teams app automatically disabled or uninstalled next time a user pings Play Store.
In any case, it's Google that is responsible to fix the mess caused by broken sandboxing of their OS.
I’d now be worried that 911 won’t work with other dialers either. Calls to 911 should probably always be handled by some first-party dialer since it’s not reasonable for everyone to test if their specific installation will be able to call 911.
It sounds like the issue is that Google didn't specifically exclude the emergency number for {user's country/province} from being sent to third-party calling apps. These apps can register to handle calls for legitimate reasons.
Ah, so MS Teams is a phone app and Android couldn't decide which of the installed phone apps has precedence. Are there similar issues around WhatsApp, Signal,...?
Android use the default "Calling app" when the user wants to make a call. MS Teams is one such "Calling app": the first time you install any other than the default shipped with your phone, you (the user) are presented a choice to choose which one you want to use. After that, Android remembers your choice.
This means in this case, MS Teams was configured as the default "Calling app" and the issue could have been prevented at 2 level:
- at the Android level, if the user dials an emergency number, don't use the default "Calling app" and use a special "safe" calling app to ensure the call succeed even if a user-installed app is misbehaving.
- at the MS Teams level, allow emergency calls to succeed even if the user isn't logged in (or any other reason that could prevent an emergency call to be made, really).
As for WhatsApp, at least on my device, it's not a "Calling app", and as such cannot override the default calling app. I don't have Signal installed to check.
How exactly do you check your "calling apps"? I'm on Android 12 and have a list of "Phone apps". However, the only other app listed there (besides "Phone") is a VOIP app I specifically installed to make alternative phone calls with. Signal, WhatsApp, Telegram and not listed, even though I've used all of them to call other users on the respective apps.
First: I used "Calling apps" because that's how it's displayed on my Android 8 phone. The actual naming isn't consistent across Android versions, so yours is probably named "Phone apps". That's located in the settings, and again the exact way to access it varies according Android versions, manufacturer and whatnot (which is an endless source of pain to guide end-users by the way).
To appear there, apps have to declare they are phone apps and handle the proper calls (an "Intent" in Android jargon) when the system receive a request to make a phone call. WhatsApp, Signal and Telegram do not do that: you are only able to initiate a call when already inside the app.
I don't know about Android 12, but on Android 11 it's in Settings > Apps an notifications > Defaults Apps.
This is where you choose which app you want as default for phone, browser, messages, etc
> at the Android level, if the user dials an emergency number, don't use the default "Calling app" and use a special "safe" calling app to ensure the call succeed even if a user-installed app is misbehaving.
That doesn't make sense, the user has to pick the app to dial with before they have an interface to enter the number.
Assuming that your hypothesis is correct: No. Signal doesn't have that permission and I think whatsapp doesn't either, and neither signal nor whatsapp can be signed out in the first place.
I wouldn't go so far as calling my post a hypothesis, it was like a guess. Another guess, wouldn't the fact that neither WhatsApp nor Signal are causing the same issues hint at MS Teams being the culprint?
Teams does the wrong thing, there's no question about that. But it's not clear to me that the Android core is unable to check that the phone app does the job, and has to trust it blindly.
> Why on earth would you want apps to be able to intercept calls on a phone?
Because there are housands of users even on HN that WANT apps like Signal to be able to manage secure encrypted calls like a first-party app with the same rights. Basic software freedom and all that.
I want Signal, Slack, Teams, my apartment buildings intercom system, etc, to be able to present their own native incoming calls through the same dialogs that regular calls come through. But not at the cost of potentially not being able to call emergency services...
> I want Signal, Slack, Teams, my apartment buildings intercom system, etc, to be able to present their own native incoming calls through the same dialogs that regular calls come through. But not at the cost of potentially not being able to call emergency services...
Understand that calling emergency services on VoLTE is essentialy VoIP as well - noone here disagrees that this is a horrifying bug. But the issue with this bug is not the APIs that allows VoIP apps to integrate into call system (after all, those APIs also make Signal/WhatsApp/Skype/Teams calls work over systems like smartwatches, Android Auto and Bluetooth car integrations) but the fact that Android somehow missed the fact that a buggy app can stop a call.
Incoming calls or manually dialling a number directly through the respective app is a different matter, but when you click a stored number in your contacts list, or a phone link in your browser or another app, or anything like that, that app just hands the number to the OS and basically says "please call this number for me".
If you want to allow alternative VOIP apps and things like that to exist, at that point the OS must allow routing that number to any app that claims it can handle (outgoing) phone calls.
Yeah sure, and for most things it's fine if things break, irritating and bad press, but fine. Things like calling emergency services can never be allowed to break. It must have fallbacks, if it even needs to be allowed to be overridden in the first place.
According to this old bit of documentation (https://android-developers.googleblog.com/2013/05/handling-p...), the usual way of intercepting call requests should already handle emergency calls ("Note that the system broadcasts NEW_OUTGOING_CALL only for numbers that are not associated with core dialing capabilities such as emergency numbers."), so it'd be interesting to know what went wrong in this case (and why only on Android 10 and newer), but until then it's hard to say more and it's all just speculation…
There are many reasons why an app would want to be notified of a call taking place - e.g., a music app could use this event to auto-pause playback, Teams might set the availability status to "busy", etc.
The question is what should happen if such an app takes an excessively long time handling the event. In this case, the OS should not wait for the app and should directly go on making the call. The bug seems to be that the OS did wait, so a misbehaving app can effectively block phone calls by e.g. going into an infinite loop.
> Why on earth would you want apps to be able to intercept calls on a phone?
My daughter enlightened me to this recently.
Android devices are not phones. They are computers that come preinstalled with some apps, one of which is a phone app. Importantly: They are not marketed as PHONES. They are marked as "Smartphones". Just search for the word "phone" on the websites of any major Android device manufacturers.
The distinction is important.
Be careful when punishing children from "using the phone". Today, this means that they cannot use the app called "phone". This incident is a stark reminder that "phone" is an app today, not a physical device.
You are right that many younger people (and not only younger people) primarly think of those little black rectangles as computers with several apps. As you say, in their minds, making voice calls in the classical way just happens to be one of those apps rather than the device's primary function.
But you are dead wrong about the word "phone". It still means those little black rectangles. If you primarily think of those little black rectangles as computers (or social media machines) then the word "phone" has shifted meaning to match that. If you punish a child by banning them from "using the phone" you will absolutely get the horrified reaction you'd expect.
Of course words vary in meaning throughout the world and maybe "phone" really does mean the classical phone app in your area, or in your daughter's social group. But that's exceptional, regardless of age.
I'm basing the definition on the usage of words by the companies which manufacture and market the devices. See the usage of the words "phone" and "smartphone" on the LG, Samsung, and Xiaomi websites.
Apparently, the "phone" in "smartphone" is about as relevant as is the "fun" in "funeral".
The evolution of the meaning is even more obvious in at least one other language: Japanese borrows the English word "smartphone" for those, but uses "denwa" (with its own kanji) for non-smartphones.
Sure, I agree with that. (But also, what marketer would miss an easy opportunity to include "smart" in their product's description.) I was just talking about your last paragraph.
Sure, I'll accept that. But the point isn't that the devices _are_ something specific, rather, the point was that the device _isn't_ considered a phone by the manufacturers. "Phone" is one function of the device, but no even its major selling point.
There is a fallback call flow for emergency calls in cases where the phone cannot register properly but it would be nice to be able to overlook missing bureaucratic elements and just save lives, and that’s what “Emergency Calls Only” signifies, but it probably only activates when normal flow fails.
> How can a sandboxed user installed app with limited permissions cause dialing 911 to fail?
No idea about this particular problem, but my takeaway was that Android apps are more similar to web extensions with service workers than to traditional executables.
An app can register itself for all kinds of OS hooks during install. When a hook is triggered, the OS will send an event to the appropriate process of that app. If no process is running, the OS will launch one.
This means there is not a lot of meaningful distinction between "running" and "not running" on Android: As long as the app is installed, the OS may run code from that app at any time.
(This is why you can have half a dozen messenger apps running "in the background" without draining your battery: There is no actual background process for each messenger, just entries in a database somewhere. When a new message comes in, the OS receives a push notification, displays a message to the user styled according to the app's configuration - and might eventually launch a process for the app if the user interacts with the message.)
So it's quite possible that the Teams app registers itself for some kind of "outgoing phone call" hook, and there was a bug in Teams' handling of that.
Not an Android expert, but this is how it seems to me.
It's Google's responsibility to implement the hooks in a secure way, so that an app that is registered e.g. for the "call" hook cannot prevent the call from taking place.
The issue is that you might have a device where emergency calls have to be routed through a VoIP app, per legal requirements, e.g. if no cellular emergency calling is available (e.g. on voip-enabled wifi-only devices, or on voip-enabled devices in locations without cellular signal))
> And they mentioned an Android update, but what about the millions of Android phones that aren't getting regular updates?
That's my concern as well. My phone stopped getting updates from the manufacturer after getting Android 10, which is affected by this bug according to the linked comment. How are they going to get this update out to phones that the manufacturers has abandoned after the usual two years of updates?
I have always had Pixels which get monthly updates, but this is a crucial point. Even if Google says "hey guys, we fixed it in AOSP, aren't you proud of us?"
No Google, we're not. This AOSP fix won't come to millions and millions of users.
From what I understood, there will be two updates, one to Android and one to Teams. Either of these updates will be enough to fix this issue. So even if Android is no longer being updated for your phone, updating Teams will be enough to fix it.
I mean if it will never be updated again how could you fix any issue ever? Like yeah this one is particularly severe but any resolution will be an update of some kind to the software.
My iPhone 6s runs Teams just fine. Granted notifications continue to display on my phone, even when I'm on the desktop or using Teams directly - but nonetheless it still works when I need it to (on iOS, can't say the same for the Android fellows rn)
Google wants you to blame Microsoft Teams for this, and judging from some other comments that’s nearly working. But, the blame is entirely on Android. It doesn’t matter how badly Teams screwed up - it should not have the ability to mess up a core system function like this.
Let’s not forget - someone very nearly could have died thanks to this glitch. Thankfully, a landline was available.
> "I am furious at the thought that I have been unable to dial 911 for who knows how long."
Initially I thought the above comment was unreasonable. But when I put myself in the same shoes, I have the EXACT same feeling.
It is like the person who was coming at the intersection at blaring speed, but missed me. The fact that he COULD have hit me, and if that happened, I would likely have died, is a very frustrating thought. But when conveying it to a 3rd party, I feel the 3rd party might think "hey, its ok. nothing happened. you are safe. he did not hit you, so why are you upset?"
This might be related: https://blog.enablingtechcorp.com/planning-emergency-calling...
"Routing emergency calls to the appropriate 911 Public Safety Answering Point (PSAP) is a legal requirement in the United States [...] Teams can determine an Emergency Caller’s current location and automatically pass the call and the current location information to the appropriate PSAP"
Agreed. As a Pixel/Android user who has never used Microsoft Teams this is still incredibly concerning.
A third-party app causing this issue on accident means a third-party app could cause this issue maliciously and any app not part of the base operating system should not be capable of causing an issue interfering with emergency calling.
I assume/hope their January 4th fix addresses whatever the issue is at a more fundamental level, but this seems like the sort of thing that should be addressed a lot sooner than a month out.
I think the issue is that Teams even tries to do this in the first place. If I want to call someone via Teams, I'll fire up Teams. Or maybe add a button in the address book when I search for someone (I've got this on iOS, don't know if it's a thing on Android).
But on the dialler? When I'm there, I expect to be using the phone app to actually call the number I'm dialling.
So yes, this does seem to me like legitimate MS bashing. Even if the platform allows for this, they shouldn't be using it. Especially if the app is signed-out or otherwise out of order. Of course "it's for the customer experience" somehow, but come on.
Teams is VOIP. Legally they HAVE to allow for and setup 911 calling.*
Yes they royally screwed up. But its not like they could have just ignored Ray Baum Act/ Kari's Law.
*I think for non static location devices like cellphones or softphones the law does not kick in for a bit. For deskphones or say a voip phone you take home from work it has been in effect for a while now.
> Teams is VOIP. Legally they HAVE to allow for and setup 911 calling.*
No-one's saying they shouldn't allow for it. The issue here is they're hijacking an external app, effectively going out of its way to prevent the user from calling 911.
So I guess they're in the wrong twice.
For the record, no, I don't think this was done on purpose. But it just shows why it's an issue they screw around with things they shouldn't.
How else can they do it? As I understand with android they have to list themselves as a dialer to make and receive calls.
Not trying to defend the programming screwup. Just the idea that they can magically send and receive 911 calls without being interfaced somehow with the dialer.
And its not like they can always pass to the native dialer in all cases. There are plenty of no signal zones with wifi. (And before you say that 911 can use any network when I say no signal I mean exactly that.)
> they have to list themselves as a dialer to make and receive calls
Why would they have to do that? All they need to do is show a keypad and capture the microphone and speakers just like any voice chat application does. Why does any dialer API have to be involved for that?
Presumably they want to take advantage of other functionality in the native dialer, and faking out the whole dialer interface will probably produce a huge number of other bugs. It's not unreasonable to integrate with native functions and in most cases we complain about apps that don't do that.
> in most cases we complain about apps that don't do that.
In this case I don't think that thinking applies. As I understand those APIs are there so that you can create replacements for the stock dialer app, which is not what Teams is. If that's how it's been designed then I believe it is trying to take on too much responsibility.
How else can they do it? As I understand with android they have to list themselves as a dialer to make and receive calls.
Not trying to defend the programming screwup. Just the idea that they can magically send and receive 911 calls without being interfaced somehow with the dialer.
Can't the app have an internal dialler? They have their own iOS. I seem to remember Whatsapp on Android had this, but it was a long time ago, and I may be mistaken.
Under the hood I would expect it to still be hooked into the dialer system api that google exposes. Likely this was where the undefined behavior showed up.
Android allows VOIP apps to register as a dialer. They have allowed this for YEARS. One company I worked with some years back was looking at working with phone vendors who based their phones on Android about replacing the default dialer. It didn't happen, but it was an option even a decade ago.
The programming screwup? Yes, that is a Teams thing.
I personally wonder if this situation gets even goofier with Work/Personal profiles on Android. It's not something I have looked into. I have a Pixel 5 as my "work" phone and it has the profiles. But I rarely use it for anything but messsaging/Teams meetings/etc.
> Based on our investigation we have been able to reproduce the issue under a limited set of circumstances. We believe the issue is only present on a small number of devices with the Microsoft Teams app installed when the user is not logged in, and we are currently only aware of one user report related to the occurrence of this bug. We determined that the issue was being caused by unintended interaction between the Microsoft Teams app and the underlying Android operating system. Because this issue impacts emergency calling, both Google and Microsoft are heavily prioritizing the issue, and we expect a Microsoft Teams app update to be rolled out soon
Let me zoom in...
> we expect a Microsoft Teams app update to be rolled out soon
It's a Google issue no matter what. No matter what Microsoft did in their Teams app, the fact that it was (and still is!) possible is a critical flaw in Google code which Google has the duty to fix ASAP. The problem is not fixed until it is impossible for 911 calling to break even if the old Microsoft Teams app is used, and until emergency calling is certain to work even if someone else intentionally made a malicious app trying to hijack 911 in a similar manner.
I mean, that's literally a top priority without compromise - if it turns out that for some reason they can't implement third party dialing in a way that ensures proper handling of emergency calls even in the presence of buggy or even actively malicious third party apps, then an acceptable solution would be to kill all third party dialing; there is no permissible tradeoff whatsoever between features and emergency calling.
Amazed that you managed to draw this conclusion! It doesn't matter what apps I have installed and what they do, NOTHING should prevent me from getting a 911 call out if I have battery and coverage.
False. Microsoft is not responsible for ensuring that 911 is available - Google is, as they are the phone hardware and OS manufacturer. Teams can only use the APIs exposed to it by Android - if use of those APIs allows 911 calling to be disabled, that's a bug in Android, not Teams.
Similarly, if an application using the standard Linux kernel APIs is improperly elevated to root because of a bug in the kernel, that's the fault of the kernel, not the application. The kernel is responsible for ensuring that even misuse of its API or a buggy application doesn't violate certain constraints that the user expects to be upheld.
This is kind of like saying if an app crashes an operating system it is the app's fault.
The app's code may have caused the crash but the fact that a modern OS would allow an app to take down the entire system is a flaw in the operating system, and the significantly more important problem to have fixed than whatever is wrong with that one specific app that highlighted the issue.
Likewise Microsoft's code may be what is causing this issue to surface, but Android should have better protection against this happening in the first place.
Consider that if the Microsoft Teams app is doing this on accident other apps could do this on purpose, and that failure lies squarely with Google/Android.
So it can make VoIP calls from your work phone number. Now that nobody has a desk phone, such a thing is needed, especially if you don't want to pay for cell phones for your employees but do want them to get calls.
The issue here is that Android has failed to exclude emergency calls from being routed to a VoIP provider. If it wasn't MS Teams causing this issue it could well have been another registered VoIP provider on that phone.
It's simple. Force it to go through the regular cellular network first, and if it doesn't exist (e.g. because you're on a WiFi-only tablet) or is unreachable then try to fall back to another app.
Why would you have one device for work and another for private life? I use dual SIMs on my work phone. I used to use two phones but that was just very, very, very inconvenient.
Why try to cram in two lifes into the one life you have?
I don't want to have anything personal on a device someone else has full control over.
I don't want any work-related notifications after I clock out. If I'm being paid to work 8h/day, company has my attention for 8h/day. Overtimes can be arranged, but doing so on my own will and not being paid for it will never happen.
I don't want to be held liable for leaking company secrets in case I lose my personal device.
"I don't want to have anything personal on a device someone else has full control over."
You don't want a smartphone then. From the ground up these things are closed source with smatterings of OSS in highly visible places which can be negated utterly by lower level software.
At some point we all have to realise that anything we posess electronically is only a copy of the version the three letter guys have in our files.
If the choice is between sharing my data with a three letter agency thousands of kilometres away and sharing my data with a three letter agency and my employer, you're damn right I'm choosing the former.
I even refused an otherwise sensible request from my former employer to install WhatsApp on my phone because I was not interested in using it personally, and they were not interested in providing me a work phone for it.
Weren't emergency services numbers supposed to be available, not matter whether the phone is locked or not, and does not even require a SIM card?
Then how come an user mode app can block calling numbers that were supposed to be available where is there is cellular coverage?
Yes. There are lots of specific technical requirements from the FCC on this. First, even if the phone is locked, calls to 911 have to work. If there's no SIM card, calls to 911 have to work. For 911 calls, the phone's transmitter goes to full power and the receive side will attempt to connect even if the signal is too weak. If you're subscribed to one carrier and they're down, the phone has to try other carriers in range. If no talk channel is available, the cell site has to free one up, kicking off a non-emergency call if necessary. If the billing system is down in the cellular system, the call has to go through anyway. For newer technologies, VOIP has to support 911, with location info.
"Oh, we decided to divert all calls to Teams first" is just not going to fly.
Then this seems to mean that the 'Dialer' function in a lot of Android phones separates functionality at the wrong point, is that right? Having 'Dialer' as selectable should not include the ability to select what ought to be a hardware requirement to be able to dial 911. If this is true the whole pachanga falls firmly in Google's court.
that's one of my biggest reasons for not using android - i appreciate the risk that comes with "options", "choice" and "customisation".
I want my phone to work - especially during a time-critical emergency. An app crashing or bugging out is not an acceptable trade-off. That said, i have my gripes with iOS but at least Apple's thought process towards these issues is similar.
An android app isn't modal in that way. There is no "user mode". There are permissions instead, and the closest thing to "user mode" would be an app that has the 2-3 most common permissions, and no others.
https://play.google.com/store/apps/details?id=com.microsoft.... lists what Teams does or can do, and it's a long list that includes "directly call phone numbers". That means to call phone numbers without the usual indirection through the phone app, ie. Teams can replace the phone app.
I can't answer that but I run Teams on Android and it's just a terrible app. Its problems have affected my entire phone before. Like for example when it wouldn't stop blinking and each blink reset whatever I was doing so I had to quickly switch out of it between blinks and then force kill it from Settings.
Teams is the absolute worst piece of software I have ever used. Simply logging in only works about 50% of the time. This wouldn't be a big deal if I wasn't randomly forced to the login screen every few days. I experience a different bug every other day. I can't be signed into multiple orgs at once (on desktop) meaning I have to fully sign out/sign in when I want to switch and it takes forever. Notifications are unreliable. I miss Slack so much.
I only installed the teams app on my phone, because their web app only works in selected invasive browsers on the desktop, but not in Firefox, which I found already infuriating.
Why can't we have open standards for communication in 2021, where everyone can just use the software that they trust? I would never use teams if I had a choice, besides looking for another job.
I also know the number for local emergency, but needing to wait for my phone to reboot during a stroke (and my phone takes a looong time to sounds really scary.
How is this relevant? The bug was in this instance triggered by teams, but it could have been any other calling app. And I know at least a few organizations that use teams to communicate with people engaging in a private capacity - our childcare for example uses it to communicate with parents, schools to teach remote, our kids hockey team,…
Work is not the only reason reason someone may use Microsoft Teams. People in school or university use it too, and they sure as hell won't provide you a "school phone".
While I agree it is mainly the fault of Google here with not properly sandboxing, it would not surprise me if mobile management software has the ability to block phone calls to other countries and with that accidentally banning emergency numbers. I get all kinds of big (bit less serious) issues with my phone after installing corporate mobile management software and the incorrect configuration of it.
My feeling is that Google is not capable of fixing fundamental problems of Android. Every year they change some colors and rounded edges (it's starting to get hilarious seeing the design of their apps being revamped over and over again), and add features invented by their designers nobody asked for. But the keyboard lag, the storage footprint (why must an ever so slightly older phone with 16GiB internal memory be discarded because His Majesty Android demands almost all of its space for itself?), those will only get worse every release. I think they simply don't care. It's all about futuristic colorful stuff that sells. Android will never be a humble, efficient, reliable platform.
As for this issue. All I can think of is the tragedies it may cause. It's a cliché: software developers are not responsible, except when their PR forces them to take action.
Google has popularized the practice of keeping hordes of UI designers on payroll and changing the UI every single release. It's fucking cancerous. Nothing can ever just stay the same and work. Users have to be in a constant state of headache to relearn shit for the nth time.
Funnily enough I was reading the other day how some BMWs will come without a touchscreen due to the silicon/chip crisis and I actually thought that was a plus. Seriously, whomever thought it was a good idea to make cars use touch controls and going through 5 menus to turn the heat down should be just shipped to Antarctica to explain their thought process to the penguins.
I saw a car commercial where the driver appears to divert their attention from the road, lean over the center console towards the passenger seat to swipe across a large, wide touch screen while operating the vehicle.
Meanwhile 10-12 years ago my cousin was ticketed for distracted driving in the midwest because the trucking company he worked for bolted a laptop to the dashboard of his semi tractor. Though somehow these mostly useless screens are okay to have? I dont get it.
There was actually a court case in Germany, where it was ruled that enabling/disabling certain functionality, on some Tesla Models (I think it included even changing some wiper settings?) was illegal while driving, as you’re not allowed to operate devices that require looking at them (e.g. touchscreens) while driving.
I used a couple of induction hobs and couldn’t get used to them because the interfaces just didn’t work with my brain. Press a ‘button’ - maybe it will work. Move a pan slightly - now you’ve pressed a ‘button’ with and something has happened but you will have to figure out what. Spill some water? Now another change has happened. Maybe the whole thing has switched off and you’re wondering why everything seems to be ruined.
I tried to buy one with physical knobs but was told that the manufacturers who make them are moving to the touch controls.
We decided to upgrade from a terrible old coil range to induction. Since our wiring is old, it was just barely the minimum amperage for a lot of the brands, but the one brand we liked with knobs needed more power. So we're paying an electrician to come upgrade our wires, because touch controls are that terrible.
I have a cheap one. The slightest hint of grease on it or on my hands and it doesn't detect my touch. Sometimes it needs several pass from different dry clothes to activate.
> Spill some water? Now another change has happened.
That's exactly what happened to me while staying in a serviced apartment. It's hilarious, ridiculous, and sad all at the same time. As a software developer I died a little inside that day.
Fortunately I haven't had to put up with that crap once I checked out of there.
> Move a pan slightly - now you’ve pressed a ‘button’
With mine moving the pan on the wrong plate will trigger a lock button, in other words it locks the whole interface. So even if you want to switch the whole thing off you first have to press a button that's now as hot as your pan.
I have not been able to. I don't want notifications on my lock screen, i just want time. Small time. Like before.
I'm on a Pixel6. It is kind of an upgrade to my previous 4 year old phone and I sort of like it but no, it does not have a better battery and it barely has any better performance, but other Android phones are ad-ingested junk ( looking at you, f!cking Samsung ) or a joke of a software ( Looking at you, OnePlus), plus they arent whitelisted on major US carriers in Feb 2022, so Pixel it was.
The new UI is total junk compared to the UI of 11. To make it somewhat better I replaced the launcher with ActionLauncher 3, disabled gestures and disabled Google Assistant.
What I want to know is if "Now Playing" can be made into a widget/app-tap, because no, I do not want it always listening.
You're not wrong, but the intention is to keep users confused. It makes users feel lost and powerless. Then to find something they have to "discover" it; which I'm pretty sure involves endorphins.
Is there any product being developed by a giant company for >10 years that isn't a bloated mess at this point?
I see feature creep and sloppy functionality in the core as a symptom of the usual tech project management style, where there's pressure to make up random metrics to have flashy results over maintaining existing functionality.
Proper testing has the same impact for your performance than just ignoring the metrics you are supposed to test. You can also get praised when you fix the problem your sloppiness caused.
I developed on Android in ~'11 and it was a mess then. Again in ~'17 and it was... also a mess.
There seems to be something fundamentally wrong with it that resists change. Plus in some cases Google simply doesn't seem to give a shit about the platform, letting it lag behind JS versions of their service SDKs for fairly basic functionality, or announcing big UI overhauls but then severely half-assing the developer-facing side of those features.
Well, it's a walled garden. Half of it locked down in the name of security. (While "free VPN"[0] apps steal your data while you play 30 seconds of some "game".) The other half is for performance and "consistent user experience" reasons. Oh, the remaining is just the battery saver killing everything for good measure. The docs are shit. The IDE is okay, but the build system, tooling, emulator and everything provided by Google (Flutter stuff! Flutter web!) always turns out to be just a bunch of interdependent unfinished binary blobs with a laughably DIY "installer".
Sure, devs get used to it fast and can be productive in no time. But it's ridiculous how much hoops they invent out of sheer corporate-ness. (Importing projects? Nah, it never works on the first time. Upgrading projects? That basically only works if you recently sacrificed someone's firstborn. Adding some 3rd party library and getting the build system and the IDE work without spending hours fighting them? I hope you started this journey with two kidneys.)
[0] I just made it up, but wouldn't be surprised if someone does that
I'd like to meet some of those people. iOS changed, but not in a way that it hampers usability - and by this I mean basic usability. Texts, calls -> these are the important bits in a phone, not 5000 weather apps that do the same thing and flood you with ads as a bonus.
Android is a bloated mess and this bug should be a giant red flag for both Google and MS to get their shit together. Windows is currently a huge mess as well, bloated beyond repair and with "features" nobody ever asked for, but hey, who doesn't like advertising on their login screen and unrelenting telemetry?
My SIL is one of them. She is a graphic designer and has been a 100% loyal apple user for 15 years. She had everything apple, including an iPhone. But for her last phone she decided to go for an android because she was fed up with several things on IOS.
Give her a cycle or two of getting used to something, then having the rug pulled out from under you with a cancelled product or service, an inferior UI overhaul, etc. and she'll be back.
I went through that over and over again for the better part of the decade before finally jumping to an iPhone and swearing off joining any new Google services. Being a Google user is being in a perpetual state of beta testing where you pay them with your data. I'm convinced they're never gonna learn their lesson.
As someone who did the same move with the release of Pixel Pro 6, I deeply regret it. Google Maps in a minimized view fared worse than my iPhone 8 plus for multitasking, that is bound to cause some traffic accidents if a driver tries multitasking while on a car mount.
Frustrating how the best software engineers can't compete with a hardware company (Apple Inc).
> Frustrating how the best software engineers can't compete with a hardware company (Apple Inc).
Allowing for a moment for a moment the premise that Google has the best software engineers, the company seems to be structured to ensure they output mediocre work. Awful performance, poor to terrible UX, poor documentation, weird or ill-advised implementations of public-facing interfaces (say, libraries), et c. There are exceptions, but "high quality software" is not something I associate with Google.
In my experience, major iOS updates don't contain drastic changes and at first glance they don't look too different. Each update feels like a refinement of the previous release, especially compared to Android.
> it's starting to get hilarious seeing the design of their apps being revamped over and over again
I can't stand that anymore. Every single updates make things more and more unusable, they hide settings, they make buttons bigger for no reasons, &c.
They even managed to butcher the alarm app... it looks like an app designed for visually impaired people (which would be fine if it was an option and not the default/only choice).
At least they changed the options when an alarm is going off from icons to text. I swear every morning it was a challenge to figure out which button was snooze and which one would turn the alarm off completely.
Android has grown too big for google to maintain, which is why most change seem to be looks and user-goodies, rather than focusing on bug fixes or stability.
I've experienced the severe decline in stability over the last 10 years of use, and on flagship phones, not outdated.
Currently my Pixel sometimes displayes an open app partially off screen, or scaled wrong and clipped --- this is basic UI that worked for years and is now broken again.
> Android has grown too big for google to maintain
My theory is Google was never setup to maintain such a thing.
I think an operating system running on customers hardware requires quite a bit different, more stringent, responsible approach to development and release process.
Microsoft seems to have it (albeit with their own flaws and in recent years they went rogue - when they fired their testers, shoot it was almost 10 years go).
Google is not setup in same way and internal incentives are not like that, judging by hoard of messaging apps. They are simply setup to make very short projects that do not require long-term commitment. When people move on, projects get abandoned, neglected and killed. Their incentives structure is like that. It is one thing to change a webapp willy-nilly and another thing to change and support code that you ship to millions of devices you know nothing about.
During 90th Windows had a lot of growth problem that Microsoft was figuring out, now Google's doing the same with Android but I don't think that they will succeed unless they change their incentive structure.
Now having said that about Google, one has to admit that it is _vast_ and there are a lot of different teams and I suppose there are plenty of teams that work in different way. But still, they can't be shielded from corporate overall culture.
The thing that has frustrated me for a long time is google discover showing the temparature in Fahrenheit. Predictably there is a support issue with all sorts of people saying they suffer from the same issue and no resolution[0].
The problem is that there are about 5 different ways to get the temperature through google now, probably all built by different teams, so everyone suggests a different way to set your temperature units, but they're all wrong.
Pretty sure the same thing is happening internally at google with every team just trying to blame each other one, and no-one caring enough to fix the issue.
Yeah, I'm seeing the same clipping issues since upgrading to Android 12. Lots of other bugs too.
For example, since upgrading when I use my "<Car Company Name> Remote App" to lock my car the phone will crash to the lock screen and get stuck there. The only way to get out of it is a hard reboot. Shocking.
I've luckily not seen a crash-to-lock-screen, that really sucks. And of course these things usually happen when you actually need them.
While driving to NYC recently, I briefly lost all signal between two bridges; the whole phone slowed down rapidly and hung within a couple of seconds, google maps frozen on screen.
Every Android device I’ve ever had since the early days lagged like crazy. I got my first iPhone recently and it’s smooth as butter. I was a fool for sticking with Android for so long.
For Android most of the lag (IME) is artificial. To disable it, enable the Developer Options panel, and set "Window animation scale", "Transition animation scale", and "Animator duration scale" to off (or minimum value if you still want some animation). Suddenly it's much more responsive!
Totally shit design. And could still have lower input lag. But instead of reducing it they added slow animations to try to hide it, which makes it take even longer!
What to expect from a company that systematically goes above and beyond in effort to avoid having to answer support requests from their largest user base; the common end user...
Thats exactly on topic, and the current issue. Google doesn't care about performance or testing, just new features to advertise, a new clock face, and phone sales. They've left functionality by the wayside
My point is that, instead of being a sign of a reliable phone, it is a feature that is required as a bare minimum.
Another example is the fact that it has some sort of human input device and output as well. That's also a "bare" requirement, regardless of how bad the phone is and how unreliable it is.
In the same way, food needs to be edible, a mirror needs to be in some way reflective, etc.
I've owned multiple Android phones starting with the Nexus S, Nexus Galaxy, various Samsung and LG devices but I'll never forget my experience with the Nexus 5. After a poor experience with an LG phone, I decided enough was enough. I dropped a bunch of money for a brand new Nexus 5 on day 1 of release. I swore not to mess with the phone, (no root, no custom roms, nothing) because I was tired of unexpected surprises from my previous phones and just assumed that since I was not following the mainline it was my fault.
Well one day when prepping for a life changing trip across Europe, I received an upgrade to the latest Android. I just went ahead and updated and then went on the trip. Little did I know, there was a bug in the firmware such that all video recordings were put through some sort of audio filter. That bug essentially garbled all the audio of all video recordings. I only realized to my utter horror after getting back that all my videos were ruined. I couldn't believe that Google didn't properly test basic functionality and released this garbage update. During the trip my friend had an iPhone 5 and it continually lasted her through the day. Meanwhile my Nexus was running low after 1-2 hours screen on time. It was a constant headache that I never realized before because before this trip I always just took the phone to work where there would be a charger and then back home where there would be a charger. I never realized that real world battery life of this phone was utter garbage.
EDIT: I also want to add that I recall watching a bunch of reviews of this phone by the "tech vloggers" and I am dumbfounded as to how they praised this phone or only lightly criticize things like the battery life. I received a totally false impression of this phone before purchasing. This experience basically put me off of tech vloggers as well. I still watch them but only for a cursory view on a product I am already considering getting. Looking back at MKBHD and others after dropping this phone I am just disgusted that I felt like I was duped.
After I got back I was fuming for a while over what had happened. I asked about this on the Nexus5 and Android forums and was met with a lot of hostile responses when I complained about how badly Google messed this up. I just couldn't stop thinking about my friend's iPhone 5. I never bought an Apple product in my life because I was conditioned to believe that they are just lifestyle devices for dumb people with too much money. I took a risk and ordered a pre-owned iPhone 5S. WOW what a night and day difference. This phone lasted me another 4 years and caused me to fall in love with phones again. I never realized that I was unconsciously avoiding having to use my Nexus5. With the iPhone I looked forward to using it.
This was a gateway drug to me taking a chance on an Macbook. I really wanted to continue using a *nix based environment but I HATED the constant challenges with keeping my Ubuntu environment going and the the equally toxic Linux community (I bet the terrible Android community overlaps with Linux).
I took the risk on a Macbook and there was moment where I felt like my mind jettisoned some dead weight. I could finally just walk away from both communities and not have to depend on them when my system/phone messed up. I occasionally load the latest Ubuntu/Ubuntu MATE/Linux Mint on a spare PC, find that some serious bug either didn't get fixed or reintroduced and then put it aside for another year. I'm not sure how to explain this feeling but Apple has given me the freedom to "not" be a part of the Linux/Android ecosystem and that freedom is the most valuable thing they provide.
I always dread whenever Google pushes an update to any of their products. I try my best to use extensions to remove their web based updates but sometimes I don't have a choice for their web based products. They have pushed so much useless garbage onto me over the years that I utterly despise their engineering groups. The latest screwup is "Reading Lists". Like come on man, Bookmarks worked perfectly fine! They had to muck up bookmarks?! Now I am stuck setting a flag to disable it(and repeat every time Chrome updates or I switch computers).
I can't fathom how a company of Google's stature has such a poor design and QA culture. There must be a lot of grifters who have spent so much time trying to get through their tough interviews such that all they know well is how to pass those interviews but not actually how to make great products.
The Nexus 5 was probably the best (in an exciting, non-practical way) phone I ever owned.
However, I found myself in a similar situation as yourself with my Nexus 6P. Newlywed on a beautiful island all by ourselves ready to record some memories. 6P took phenomenal pictures and we were all ready with tripod and remote clicker. 6P just died. Luckily still had the wife's old iphone which managed to capture the moments, but not in all its glory.
Went through one more iteration of Android with a Motorola, that they stopped supporting about 3 months after buying.
As I've said in other posts, the amount of ewaste I generated while in the Android/Google ecosystem is criminal.
Switched to an iphone and haven't looked back. I'm still on the same iphone years later, still getting updates, still chugging along.
In all honesty, I preferred the Android OS, but it's too expensive to tolerate in so many ways; money, time (learning the new UX every time there's an update), environment/ewaste, privacy (google and affiliates vacuuming up all my personal information), convenience (it doesn't breakdown when i need it the most).
>As I've said in other posts, the amount of ewaste I generated while in the Android/Google ecosystem is criminal.
This is an unspoken downside of that ecosystem. I have also generated many phones worth of ewaste when I give up on them in less than a year. Its one of the reasons I stopped playing games with all these manufacturers and just bought an "official" Google phone and not touch it software wise. It obviously still wasn't enough.
I was recently cleaning through my attic and I found a lot of these old Android phones. Its amazing how many of them didn't get anywhere near the support that iPhones phones do. I told myself that I would eventually find a custom rom for them and then reuse them for something else but lets be real, that is just another time sink that probably won't happen. Now I am left staring at these phones wishing there was an easy way to deconstruct all the components into their base materials. I know that it is possible to break down the plastics via pyrolysis but no one is really doing this. Secondly there are the circuit board. FR-4 is ground up and used as filler from what I understand. What that means is that even if this phone is recycled, it will never really fully go away. Put in that context, the Android ecosystem just seems even sillier.
This is where I struggle to agree. Cheaper how? The way that I look at it is that the iphone is cheaper bc it's going to last 3-4x longer than the android phone. (3-4x less ewaste)
Moreover, when it comes eventually replacing the iphone, I'm going to get a better trade in value than the android even if it's 3-4x older. Thus lowering the cost of my next phone. (less ewaste bc i know the iphone will end up in someone else's pocket, not in a landfill)
Maybe Samsung is different, but when I went to trade in my $7-800 Motorola after 8-12 months of use, I was offered $28 trade-in value.
My time is also worth money. I don't have time (money) to waste on dealing with android.
Samsungs provides 3-5 years of updates for current mid and high end phones. Does your iPhone last 5x4=20 years? Will it be worth much even in 5 years? But if you trade it only after one year, how does that in any way reduce ewaste?
When I got my current phone it was 1/3 of an iphone and 1/5 of the most expensive Samsung (the fold thingy). It works well and is guaranteed at least 3 years of updates. But I plan to use it as my daily driver for 2 years, maybe 2.5. After which I will probably keep it and use it for something else around the house.
Like I said, I don't know if it was a Motorola thing and Samsung is different. Seems like that is the case since Samsung is considered the high-end option for android.
But that was to stop them restarting because the battery wasn't powerful enough after being so old. Android phone makers barely remember they made a phone 3 days after they stop selling it
They mucked up the delivery, but the feature that patch provided to the iPhone 6 and up is really great. It's just most people don't know enough about how electronics behave under unstable voltages that they only see the top layer of "Apple made my phone slow!", and ignore the fact that what Apple did was to ensure that the phone could continue working (albeit a little slower) even though its battery had degraded.
What they should have done is include the toggle from day one, clearly explained why the feature was built, and then presented users with a prompt to enable it if the phone detected it may be necessary. Shoving it down peoples throats just made for terrible optics and "planned obsolescence" was a very well fitting and easy explanation in the absence of the real one that few understood.
Like, people still talk about it like it was a bad thing, see this thread for evidence, and this is one of the places where I would expect to find one of the largest concentrations of people that do understand what that patch did and why it was necessary.
No, Apple got sued because they deserved to get sued. At no point did they do what courts determined would have been the right thing, which was to tell the user to get a new battery. And make 50% margins or what have you, that kind of profit, like what they get for their chargers, that would have been fine. They did not want to do that.
I mean I'm just voicing my own opinion here, and I respect yours and even agree with you on some level. Apple has been charging through the nose for battery replacement for a long time, though at the time all this happened (or shortly after at least) they did have a very good battery replacement program, and they recently announced a new replacement parts program which hopefully ends up doing some good on that front, but we'll see.
Personally I think it's pretty great to know that I can use my iPhone even with a degraded battery and not have it shut down unexpectedly.
I've had both iPhones and Androids do that in the past, often in cold weather and during bursts of high load (like on a chairlift at a ski resort, which my example here is based on).
Cheap battery replacements, the option to disable the "feature", etc, only happened after they were sued.
The idea was good, but it was implemented in a way that created issues for some users (eg: my iPhone 5 being sluggish all the time) and benefited Apple as most users would simply buy a new iPhone because no one knew what was going on.
Yeah plus their geniuses, lol like every one of their entry level employees won a Nobel prize in order to become a sales clerk, were scripted into shunting customers to buying new iPhones. Oh oh the gadget is fucky? Hmm what could possibly motivate such a malfunction? Oh I did just so happen to witness one customer, very peculiar, the device was clearly rotten. Happens after one year. I'm afraid a new battery, which MAY SEEM AT FIRST GLANCE like the OBVIOUS SOLUTION, but COUNTERINTUITIVELY is not, will not work. You need a new battery, but as a part of a comprehensive unit, complete with a new CPU, a new screen, a new chassis, in short, a new thing of every part of this device. You need a new device.
It's not just battery decay. It's also MORE software forced into the phone via updates, requiring more resources. You can't opt out of new features while getting the security fixes.
Apple messed up the explanations and messaging on that incident big-time, but I'm convinced that they made the correct engineering tradeoff, and I feel like not enough people (even techies) really understood and appreciated that.
As this thread illustrates, a phone is a life-saving device. The priority must be to function when you absolutely need it. You will literally die if you can't call for help when you're stuck in a blizzard and need to call for a rescue.
Apple slowing down phones with weak batteries so that the CPU always has enough juice and doesn't crash is 100% the right engineering tradeoff for a life-saving device.
The last thing you need when you're bleeding out on the kitchen floor and dialing 911 is for your battery to not supply enough power and then force a phone restart or worse when seconds are counting down.
The idea was good, but the implementation was terrible. It slowed down some phones a lot (my iPhone 5 was always lagging), there was no information about the feature, no setting to disable it, etc.
I actually started to hit this problem on my iPhone 5S. Not the slow down but the original issue that caused Apple to slow down phones. Old batteries that were really degraded would cause the phones to just die and shut off when the CPU had a spike in usage. I'm sure thats not great for the file system when that keeps happening. However it must be noted that it only started to occur after the phone was 5 years old and the battery had dropped to about 50% of its original design capacity. In fact this was one the reasons I eventually upgraded the phone...that plus I got a new job so it was time to finally upgrade the iPhone 5S to something better (a 1st gen iPhone SE ha ha). I could have just replaced the battery and continued using the 5S for another 1-2 years (as it had 1-2 more years of software updates from what I recall).
The 5s has been given security patches for iOS 12, the last being September 23rd.
That's 8 years of support if it's the last. It was the first 64-bit ARM phone, and the first to have a Secure Enclave, so it might be a bit of a favourite child.
Not sure what you mean with life changing, but from experience: if you ever find yourself in a situation where you go on a trip and your health might depend on the ability to call or navigate, don't ever use a smartphone for that ability :)
No, it was a life changing trip in the sense that I made so many memories and redefined the direction I wanted my life to take. Not physically in the sense of health being damaged.
First of all, I love you French people. Paris has a reputation for being cold and hostile to outsiders but it is not true at all for me. I've met so many wonderful people there that I still keep in touch with. Walking around the streets of Montmarte at 3AM with my friend just somehow helped reset the mind. It was life changing because I was stuck in a dead end job not even in the career I studied for. I was a CS major but ended up in tech support and then software QA. It was a really depressing time for me and my friend who was also going through the same issues as she was an Engineering grad but ended up in marketing. It was also this feeling of no real goals in life. Just traveling, meeting people with different lifestyles and breaking that chain of daily driving 1+ hour to a terrible underpaid job helped to reimagine what was possible.
Also got to do a lot of deep thinking while traveling across Europe. Wish they were more united. There are so many unbelievably talented people in Europe. It would be interesting if they could compete head on with the US and help to keep us more on our toes sort of like a second super power. I think that would be good for the world. Alas I saw how things like this are just not possible because people do not believe in it. The same problem I had before I came to Europe! Its unfortunate because Europe has all the components to be just as competitive as the US (in my opinion). :)
What a weird response. Modern smartphones are absolutely valid lifelines. You might as well tell travelers to leave their money behind because they should be able to build their own shelter.
Hmm, I see what I mean wasn't super clear. Of course they are valid lifelines as long as they work. My point was about that working condition though; think battery charge not being exceptional, seems to drop dead easier than when dropiing a brick phone. Then again maybe I just had bad luck.
Honestly my thinking was that this was a "Google" phone and it was advertised as such. All the software came from Google...or so I thought. Turns out as with everything from this trash company(Google), I was duped. The bug was eventually traced to a fault in the way the Qualcomm driver handled mixing and I guess they introduced a regression in the firmware. Yeah...I was super pissed so I looked into where the failure was occurring. I seem to also recall which file in the Android source was causing the problem. All they had to do was record a video and play it back! They obviously do not do real QA testing on each firmware release. Or maybe they automated it(like they do with all their crap) and their test rig missed this bug.
It was eventually fixed in subsequent firmware releases(while other things broke). After getting the iPhone as my daily driver, I opened up and started using the Nexus 5 as a tinkering testbed for custom roms. The smoothest firmware I have seen was a Cyanogen Mod release in late 2015 although it still had rough edges compared to my iPhone from what I recall.
Original iPhone (2007), iPhone 3GS (2009), iPhone 4S (2011), HTC One X (2011, not because the iPhone broke, a friend convinced me I should try Android, and on paper it seemed like I would love that so why not?), Samsung Galaxy S3 LTE (2012), Sony Xperia Z (2013), Sony Xperia Z1 Compact (also 2013), (LG) Google Nexus 5X (2015), iPhone SE (2016), iPhone X (2018), iPhone 12 mini (2020).
I actually knew I was done with Android by the time my Z1 Compact broke in the same way it had already been repaired for once (small crack in the display glass which the digitiser was glued to meaning touch stopped working on one side of the crack, unfortunately about 90% of the screen), but I figured maybe I've just been buying the wrong brands and figured I should give Google, the premium brand, a chance before I went back to iPhones for good.
Alas, the Nexus 5X was so bad (laggy, terrible battery life) I actually went back to my iPhone 4S (which I had also been using between the Z1 Compact and the 5X) within the first year, and then bought the iPhone SE when it came out and never looked back. That iPhone SE actually went to my little brother when I bought the iPhone X, and he stopped using it in 2020 after the screen finally cracked (still usable because Apple doesn't glue the digitiser to the display glass like many Android manufacturers do, a practice I personally think is to force repairs since it becomes impossible to use them without a repair).
That behavior only occurs when you learn to distrust your device enough that you learn that lesson. In IT you learn it when an update borks your production. In Phones you shouldn't have to learn it. Yes it is a computing device but it should be built like an appliance that does not need to be rolled back. Thats where the disconnect between Android and iOS is. Sounds like you haven't given iOS an honest look. (As in actually owning a device and using it in real world usage for a while).
I've got an old gen1 Pixel xl 128g, which was working well. I'd been putting off the os upgrade nag messages for a long time, but in a moment of weakness I capitulated. Now the phone is basically a shadow of it's former self with an endless list of issues. I suppose I need to try a factory reset if I want to resurrect it, but not sure I'll find the time.
To be clear, I don't expect google to actively support such an old phone, but I do expect them to properly test updates if they decide to send them to a particular model.
My Gen1 Pixel is still going strong here. 2-3 days battery life with light use and monthly AOSP updates via Pixel Experience ROM. Hope to use it another 5 years.
Yes, it's "relatively" easy. They had over-the-air delta updates with Android 10, but not for 11. Here my current steps for each ROM upgrade. Installation would be similar:
- Connect USB
- Boot in Fastboot: Press and hold Volume Down, then press and hold Power
I've only just upgraded to android 11, and every single new feature, without exception, is a usability nightmare in some sense. I wouldn't mind so much if they redesigned often and the result wasn't so awful
They're particularly not capable of fixing the problems on the enormous mass of Android phones that are no longer receiving any updates and in many cases, due to manufacturer/carrier disinterest, never were.
Last time i looked Google posts updates for their apps every couple of weeks. Of course nothing more than "Bug fixes and speedy performance improvements".
Now, if they need an OS update to fix dialing 991, they need to fix their development process.
It would be downloading gigs (tens of gigs?) of useless updates every week. Kills my aging battery, slows down my phone/wifi at inopportune times, etc.
I'm happy to download a quarter gig of gMail updates if they've actually updated something. Abstract "bug fixes and security improvements" doesn't seem like a worthwhile gig of updates every week.
Upgraded my Pixel 4 to Android 12 and told my wife to stay on Android 11. Bugs and questionable design changes. I do not think she will miss any feature ... erh actually what are the new features in 12?
In fact they stripped lot of features by trying to hide stuff in layers with that god awful UI. Sometimes I feel like Android tries too hard to be iOS and loses its identify completely. If I wanted an iOS experience I might as well use iPhone.
"Based on our investigation [...] We determined that the issue was being caused by unintended interaction between the Microsoft Teams app and the underlying Android operating system. [...] If you have the Microsoft Teams app downloaded, but are not signed in, uninstall and reinstall the app. While this will address the problem in the interim, a Microsoft Teams app update is still required to fully resolve the issue. [...]"
Now I'm really curious as to what that "unintended interaction" was.
Why does Android even allow third-party apps to handle 911? This isn't just a Teams bug, this is a design bug in Android. I have Teams installed and now I'm worried about this too.
I like this feature, it means I don't need to use the crappy dialer that some manufacturer made for me. It's also a good feature for VoIP apps because Android's built-in SIP client works but isn't very clear when something goes wrong.
It could be that there is some kind of design bug (no way for a dialer to indicate that emergency numbers cannot be dialed) but it could also be an actual Teams bug (Teams indicates that it can dial 911, sets up a connection that dies in the background).
Because it specifically happens with Teams installed but not signed in, my guess is that the latter is the problem: Teams tells the OS "yeah sure let me dial that for you" but then doesn't complete the call because it wants you to log in to MS first. Reinstalling the app, as suggested, would kill all associations with the standard dialer, but an update from MS is necessary to fix the main bug. I have a feeling the promised update for 2022-01-04 will remove the ability for these dialers to call emergency numbers all together.
In my opinion there should at least be a setting (enabled by default) to send emergency calls through the system dialer, if it's not enforced automatically already.
Android lets third-party apps replace the entire calling process, so depending on the setup there is no OS component that even knows what number you are trying to dial before the dialer actually tells the OS about it.
Not sure if Teams does that, if not I guess it would be possible, although I'm not sure if there aren't cases where suddenly a different (=an OS component) app than the user expects taking over also would be bad, e.g. if someone used a special dialer for accessibility purposes. Maybe this should be behind special review and testing, at least this specific bug here seems like it'd have been easy to catch if emergency calling behavior was tested.
Maybe they thought, we could be like Apple and force everyone to use our apps or else... Or we can allow 3rd party dialer apps and notify the user of the risk deep in a ToS agreement.
I am looking forward to people getting outraged once again when Android does not allow third-party apps to handle 911. There'd be dozens of articles on HN about how Google is being anti-competitive and outrage will keep pouring in.
HN might bean outrage machine some days, but like every Voip thing ever says you can't call emergency services with them. I always believed it to be a SLA deficiency in consumer internet? I'm guessing a strong preference for the real cell network to handle the calls would be necessary until this changes. Unless you can actually swap out the "phone" app on Android to have a 3rd party app make a real phone call?
Yes, any app can be a phone app ("dialer" in Android parlance), and there is a user preference to determine the default dialer app for sending and receiving calls.
In fact, Google has themselves made several available over the years; Hangouts and Google Voice are two examples.
In fact Teams itself has E911 support, you have to enable it if you setup a phone number PBX.
What is missing is a way to say “emergency call failed” and pass it to another handler (perhaps even a low-level one built into the cellular part of the phone itself).
Microsoft made a special point of getting people used to the idea that nothing can be expected to work right. Before Microsoft, if something didn't work, you sent it back for a refund, angrily. Since, it is "Have you tried rebooting it?" No refunds, ever.
Everybody else relaxed into a Microsoft level of expectation. Anybody who doesn't, spends money their competitors don't.
(If you are too young to remember: this is literally true.)
This is not accurate. All complex software has had bugs since Grace Hopper's moth, at least, and it was never common to seek refunds because of software errors. Microsoft is only notable because DOS and Windows became ubiquitous in a way that no previous software had, exposing the whole world to unreliable software.
(I've been a professional programmer since the mid 1980's, so I do remember. )
Have you used Office? Whatever those apps are now, online, in Teams, stand-alone, it’s a steaming mess. Various functions work in various places and things like moving an image are just ridiculously broken.
I never said Microsoft makes good software. Indeed, Office is often very buggy.
My point is that Microsoft isn’t unusual in this regard at all, except that their software has become very popular. In other words, people experience Microsoft bugs very often, not because Microsoft software is unusually bad, but because Microsoft’s software is unusually prevalent in the world.
This is unfair. The requirements for consumer software have become exponentially more complex during Microsoft's tenure as leader. Hardly anything worked quite right in the 90s or 00s.
Microsoft predated the Apple ][ too, but it's moot either way. Was MS-DOS so buggy and so profoundly influential that it dramatically lowered Apple's standards - and everyone else's - over the course of the two and a half years between the launch of the IBM PC and the launch of the Macintosh?
Macintosh and Amiga, without any sort of memory protection, could easily be made to crash by bugs in any program. But crashing was the exception, and an embarrassment to be fixed as quickly as possible.
Windows, instead, absolutely routinely crashed every day, or even several times a day. A few people managed to keep it up for days between crashes. It would crash even when you weren't using it.
I had an Apple A/UX system that stayed up for months at a stretch. That was simply normal for Unix, and later Linux. Even in the mid '90s it was expected that a Linux system would be rebooted only after you deliberately shut it down to upgrade to a new release or install new gadgets. (This was before there was USB.)
Microsoft ended up redefining crashing to mean, not just needing to reboot, but failing to reboot so you would need to re-install the OS, because something got corrupted on disk. It was totally normal and expected to need to reinstall Windows every few weeks or, sometimes, months, and everyone got used to that.
Look up "monopoly". Users are not the customer. Equipment had, as it still does, MS pre-installed. You could not buy a system without, and contracts were written such that vendors could not afford to offer an alternative.
Microsoft worked fine for the actual customers, the system integrators, because all it needed to do was install and register. Once the system was delivered to their customer, software failures were Somebody Else's Problem, and did not affect the actual customer.
Economically speaking, software failure costs were exported to the hapless users, who were not sophisticated enough to blame anybody, and not in a position to demand satisfaction from anybody.
Star Trek was always upheld as a model of the future. But instead of transporters and replicators and space travel, we got all the bad stuff from Star Trek.
Everything breaks all the time. Technology doesn't do what we expect it to do. The latest, greatest inventions are held together with gum and bailing wire. Computers let us down when we need them the most.
I've been using video conferencing software, and hardware in a few cases, for about 20 years, and I don't remember the last time it failed to connect first time. It definitely used to but that hasn't been a problem for a very long time.
I run into problems with video conferencing applications on a semi-weekly basis. The most common is when the dialin number (I use a desk phone for the sound quality) connects to one of their "bad" lines and [doesn't connect, is delayed, can't hear anyone, nobody can hear me, etc... pick your failure of the day]. But there's many times where it fails in other, purely software ways.
That isn't true at all. If you read the postmortems on the USS McCain and USS Fitzgerald collisions, you'll find that one of the contributing factors was the fact that both ships had lots of issues with the computers and software controlling their sensors and communications. This post (https://fixvms.com/) on the mapping software for the US submarine fleet doesn't raise confidence either.
Issues with software controlling communications isn't the same as issues sending communications.
If you're telling me there are ships running in the defence force that can't actually communicate with other people at the drop of a hat, at all times, then how is that even possible? That requires some serious negligence.
In a lot of instances, if the system fails, the plane falls out of the sky, so I am pretty sure we're doing that well.
If you're telling me there are ships running in the defence force that can't actually communicate with other people at the drop of a hat, at all times, then how is that even possible? That requires some serious negligence.
Indeed it does, but unfortunately ships have to be designed to constraints other than, "Works perfectly all the time, even in combat." For example, one of the reasons that the British lost HMS Sheffield during the Falklands War is because, due to issues with her antenna layout, she was unable to use her radar and satellite communications at the same time. When the Argentine planes launched an Exocet at her, she was in the middle of using the satellite antenna, and thus missed the incoming missile. Why was the antenna layout so boneheaded? Budget cuts during the shipbuilding program, which forced a reduction in size and consolidation of antennas.
In a lot of instances, if the system fails, the plane falls out of the sky, so I am pretty sure we're doing that well.
The numerous issues we've had with communication and sensor fusion on the F-35 indicate that we aren't. Now, the military absolutely assures us that those issues have been resolved and the F-35 is great now, but I think I can be forgiven for not taking their word 100% at face value.
The person was able to make other calls right before the attempted 911 call, though, so while it could be something like this it seems like it might be more complicated.
IMO while Microsoft and Google should work together to solve this as soon as possible, the longer term solution should not involve Microsoft. This sounds like something Google should fix at their end.
No customization done by the user, including installation of apps should prevent a user from being able to call 911, period.
That's actually a real issue that needs addressing. Any phone that makes 911 calls should still get security updates. All phones that can reach the cell network can still make 911 calls per FCC requirement.
Imagine the worse case scenario where malware infects the phone but requires a credit card to call 911.
Maybe congress will get around to this to make Google and everyone else do the right thing, but from my perspective Google should have done the right thing here.
Worst case scenario? Sounds like best case scenario to me so long as no one is harmed.
It will take some horribly idiotic event like that to get the manufacturers to actually address that when you sell a phone you're selling hardware and software.
If Google are concerned they could fix it more easily that a software update for older, unsupported phones - they could just mark every app that registers itself as a third party dialer as incompatible with older Pixel devices in the Play Store, and remotely remove them from Pixel phones presumably. It'd be a bit "user hostile" but you have to remember that you don't really control the code on your phone if you use Google services, so it's entirely possible for them to act this way.
The thing I think people are missing is that the response from Google indicates that this isn't a Pixel issue. This is a "all android phones on Android 10+" issue.
Without full cooperation from manufacturers, there's really not a lot that can be done outside of blacklisting all dialer apps on the Play store and even that would do little for anything already installed.
I think you miss the point here. Security updates for phones need to be longer than 3 years -- for that reason.
The pixel 2 is already EOL'd 4 years after it's release, but it can still make 911 calls. I believe there are people that still depend upon that phone to make phone calls -- and therefore need 911 when they need it.
Oh definitely. I wasn't disagreeing with that aspect. Everybody had been focusing on how the Pixel line would be able to solve this issue which kinda ignores that bigger issue that the entire industry needs to be maintaining these security updates. There's no good reason for OS security updates to be gated behind manufacturer control.
EOL does mean something. I don't believe 3 years is long enough personally, but even if it was 10 years the same problem would exist, just for older phones. Then it becomes a semantic argument about where phones should ever have an EOL date for critical fixes.
I think Google would argue that malware interfering with your phone after its EOL date is a reason why you should upgrade your phone to a newer model rather than use that as a reason to extend the life of their phone software indefinitely.
What would you like them to do? Google couldn't retroactively make it possible to patch every phone on the planet even if they wanted to, and the phone manufacturers aren't likely to treat this as any more special than the other bugs that they aren't patching
Well, I'd expect them to bring the phones into compliance with the law. Quoting section 22.921:
> Mobile telephones manufactured after February 13, 2000... must incorporate a
special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call...
If a phone can't access 911, it's not legal. Frankly, it's an indictment of the system architects that this bug is possible at all.
But what if I as the user install software on my phone that isn't capable of calling 911?
I own the phone and I am able to install whatever software and whatever operating system I like. I don't want it to seem like I'm defending Google here, but should manufacturers really be responsible for the software someone installs on their portable computer?
Moreso than most, this regulation is written in blood. The reason this and other FCC 911 rules came about was that there were numerous cases of people trying to call 911 and failing due to software "issues". The FCC said enough and mandated that if it were possible to complete a call, the phone is required to.
Installing your own OS that intentionally doesn't support 911 handling would be in the "not possible" category just like a user who cut their antenna. For anything less than that, Google (and other manufacturers) are absolutely responsible for ensuring the 911 code path can't be disrupted. People have literally died from this.
So you are advocating to put anyone who has a rooted phone that doesn't get this dumb update to fix an issue with Microsoft Teams in jail?
Seriously, this sounds like a Teams issues. Google does by default incorporate what is required and it isn't until Teams takes permission from the phone app that an issue even occurs.
I don't think anyone is expecting google to patch every phone on the planet (assuming you mean every android device ever released). But they should be able to patch every phone of theirs including every old pixel and nexus.
And if they can't, they should make it clear to the user/owner that their phone isn't supported and that means that their lives or the lives of others could be in jeopardy as a result. In fact, perhaps their phones should have an expiration date and should just stop working after sometime. Or at least disable critical functionality that their required to be in compliance with (FCC regulations) since they've decided to no longer support the device. Moreover, this date and timeline should be clear from the point in time when you purchase the device.
Of course this could all be done by the network providers only allowing supported devices on their network, but we all know how that would end up.
This isn't just some bug, and if google wants to participate and be taken seriously in this industry, they should stand by their products and customers.
If they can determine that any phone in usage today running Android software may be prone to this bug they should issue an immediate recall on all devices. That's likely to be almost every Android device purchased in the past couple of years. This scale of recall is not without precedent.
I wouldn’t jump to conclusions before we fully understand what’s happening. Maybe this issue was introduced in the latest version of android (that would be my guess seeing that it was just discovered) thus fixing it in a patch release on that version would fix it for everyone. You with an older pixel have nothing to worry about because you couldn’t update to this version anyhow.
It would also be quite cool is 3rd party apps didn't need and use permissions like "listen to who am I calling". Why a chat/online calling application even need that? Only to collect metadata about their users?
There is a reason this materialized with teams and not with any one of the 10's of thousands of other apps out there: Teams is by far the most invasive piece of shit there is, it tries to hook into everything it can get its grubby little endpoints into.
Both parties are to blame. Teams shouldn't have behaved the way it did, Android should have failsafes to prevent this from happening. A great example of not letting developers do what they want...
Sure, Android should absolutely not allow any apps to interfere with 911 calls, and so however Teams achieves this, should not be possible. But some blame certainly goes to Teams here as well for causing the situation by trying.
One thing I do want to point out is that "not allowing any apps to interfere with 911 calls" is much more complex than it sounds:
1. What about someone who has a tablet (with no cellular functionality) but has a VoIP app installed?
Clearly, the only way to call 911 on such a device would be for it to go through the VoIP app, so it seems like Android at the very least still needs VoIP apps to be able to handle 911 calls under certain circumstances, such as when there is no cellular functionality.
2. How about a situation where a cellular phone has no communication with any cell towers (for any network) but has a VoIP app installed and access to wifi?
Unlikely, to be sure, but possible. In this case, the only way for the phone to reach 911 would, again, be through the VoIP app. If 911 access must get through no matter what, Android would have to let the call go through the app, despite that the phone has cellular functionality.
Those are likely just a couple of instances and there's almost certainly others I haven't thought of.
A solution could be to give the Android system dialer first preference. If it fails to call the number (network issues, no signal) it could automatically pass off the call to the first registered VoIP app
That said, the Google Play store should also have more stringent reviews for apps that want dialer access. Their review should verify whether emergency services can be called regardless of signed-in status, and location
I would be happy to get that somewhere in Google someone is either signing off on such a review requirement right now or has done so in the last couple of days.
I suspect that this little tidbit here is the root cause:
"If a Teams client is not located at a tenant-defined dynamic emergency location, emergency calls from that client are screened by a national call center to determine the location of the caller before transferring the call to the PSAP serving that geographic location."
Also, "If a Teams client for a United States Calling Plan user doesn't dynamically acquire an emergency address within the United States, then the registered emergency address is used to help screen and route the call. However, the call will be screened to determine if an updated address is required before connecting the caller to the appropriate PSAP."
Which is a clear violation of Kari's Law. A business phone system in the US is absolutely not allowed to intercept and divert 911 calls.
Maybe you other reasons to drop Teams, but this would not be one.
Google/Android are clearly tasked with handling 911/emergency calls. Teams is not - I doubt that it is even in their spec - they should expect 911 to route right past them.
Google effed up this one big time.
They need to fix it for every app, not just Teams.
It literally does not matter what Teams does - even if Teams maliciously did every wrong thing they possibly can, it's the duty of the phone manufacturer to ensure that 911 still works, it's Google's duty to ensure that Teams or any other app can't break emergency calls no matter how they try; the law literally requires the phone to recognize that a 911 is being made and override any programming (e.g. Teams) that may interfere with that. If Google can't do that with an over-the-air update, they can issue a full recall for all the affected Pixel phones.
My understanding is that emergency calls for any global locale are supposed to be an entirely separate band of communication from regular phone calls — e.g., they must work even without a SIM card, an account, etc.
So, emergency calls should be ENTIRELY OUT OF SCOPE FOR ANY APP software. Period.
It should be a low-level override/bypass, and NO app software software should ever be allowed to even touch emergency calls, let alone required to handle them.
Expecting all apps to handle life-critical emergency calls correctly is a profoundly stupid idea, guaranteed to produce a multiplicity of failures (and if that expectation did exist, Google must damn well announce it as a deadly serious requirement in bold, uppercase, red flashing letters to anyone wanting to use phone_call_handling permissions, but they don't, afaik).
So, we don't need to know anything about Teams or other app software in this case, only about the emergency calls side/back channel, and that any app, including Teams, will ZERO responsibility for handling emergency calls, or even ability to touch them.
So, it is Google that effed up big time here (regardless of Teams' other issues). Unless you make a solid case for the profoundly stupid idea that all phone-related app software should be responsible for handling life-critical emergency calls, your statement is plainly wrong.
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
It doesn't matter what Teams does. Android is required to ignore Teams in the case of an emergency call. That's the law.
I worked at Motorola's cellular division 20 years ago. I recall a "stop ship" incident when a 911 bug was discovered. That is, we halted the factory and shipments until the bug was fixed and a new software image was available.
The phone's callstack takes a lot of special actions when calling 911, including locking onto any tower even if it is not in the preferred roaming list. As with many exceptional conditions, these code paths are often not as well tested.
I wonder if there should be a 911-like test number that would cause the phone and the network to go through the emergency call procedure, just not connect to the actual call center.
Yes please.
I develop Android custom ROMs and I have no idea whether I'm putting people's lives in danger. And it's not just whether calling works, but also E911.
Even when I used to work at a smartphone maker we didn't have any process for that.
Just call 911, and when connected state that it's a test call and hang up. 911 calls have plenty of capacity for occasional test calls, and the need to test them clearly is important to reduce the risk of them not working when needed.
If you need to do automated tests, there is a test flag in the android dialer API which will make the call but mark it with some test flag so you get a recorded message not a human answering.
Do not do this - I believe it may even be illegal in the UK without per-arranging.
In the UK you need to email BT (who operate the emergency system) and arrange a window to place a series of test calls to both 999 and 112. They will give you a time, a date and a script to exactly follow. If you pre-schedule with them it's supported.
Remember that an OS ROM (especially a custom one) may not be just for one particular country or region. Here in the UK the emergency number is 999 (and also 112 on mobiles) and we are constantly told that the emergency services are understaffed, so making test calls would be irresponsible.
"We believe the issue is only present on a small number of devices"
-> Reads like damage limitation. Don't believe it, say why!
"we are currently only aware of one user report"
-> Irrelevant. Damage limitation. Don't ever write this. Most users will never be able to recognise it as an Android problem, even fewer will have the ability to bug report it.
The resolution is to wait for the teams app to update. How many people will even get the update? Many have disabled automated updates. Don't call it a phone if it can not dial 911!
Since I don't use Find My Phone often enough, my Pixel 3 helpfully decided to remove location permissions from it. Would've been in for a surprise the next time I lose my phone had I not caught the notification.
Oh wow, this is true for me as well. Need to check if the app permission is required or if the location tracking works separately through some system service.
If you mean the Find My Device app it only asks for foreground location permission so I would assume the actual device "beacon" is part of the system not that app.
I've lost a phone with location tracking turned off. You can still disable the phone remotely and assign a lock screen message for the findee to contact you.
Problems I had on Android phones at various times in the 10 years I owned them (mostly Nexus / Pixel):
* Can't make calls
* Can't receive calls
* Can't send text messages
* Can't receive text messages
* Receiving text messages out of order or days late
* Can't take pictures
* Can take pictures, but they don't save
* Phone randomly shuts down when cold
* Phone randomly shuts down when hot
As much as I liked Android when it worked well, in the end I realized the bugs in the OS were putting me at risk of physical harm or, at the very least, incredibly damaging data loss or missed communication.
I bought myself a $400 iPhone SE. It may not have every feature I loved from Android but it's 100x smoother and more reliable. I don't regret the move.
The only thing I regret after switching to an iPhone SE this year is the ability to use Firefox with uBlock. I regret not buying an iPhone sooner. It just works.
When Apple argues why a phone is not a general purpose computer (and therefore should not allow sideloading), this is an example of why. A phone is a general purpose computer until you need it in an emergency, in which case it _must not be_ a general purpose computer.
I'm not at all surprised by this. For a 5 year span I used probably 4-5 different Android phones, from HTC & Samsung. All of them had this kind of glitch, where some kind of race condition gets the system stuck in an unanticipated state. UI elements that were supposed to scroll smoothly off the screen would get stuck halfway. Some system app would lock out touch events temporarily while loading something, and it would stay locked until a hard reboot.
I think it's a symptom of a system that's designed as a stack of abstraction layers, with developers who don't communicate. The developers of project A think a bug is a minor issue, not knowing that project B relies on it for something critical.
It's hard to write an app for a platform like this, too. Instead of one cohesive target, you have discontinuous abstraction layers.
Looks like Microsoft Teams was part of the problem here. I assume they had to hook into some semi-documented functionality that Google wasn't aware of or thought no one would use. On iOS, where Apple keeps tight control over their API surface, this is less likely to happen.
Android has the concept of an Intent[0] which are basically a category of apps that can fulfill a functionality like sending an email, browsing the internet, or dialing a number, etc.
So a developper can create contacts/caller app so that for example, when you click on a call button from say a google search, the OS asks the user to pick one app that was declared to be able to ACTION_CALL.
If I had to guess, I'd say it's something having to do with Teams being given priority on calls followed by failure to having priority for emergency calls and no way to gracefully recover.
Quickly browsing the documentation I see comments like
Note: there will be restrictions on which applications can initiate a call; most applications should use the ACTION_DIAL.
Note: this Intent cannot be used to call emergency numbers. Applications can dial emergency numbers using ACTION_DIAL, however.[1]
I have yet to use any system where the UI can’t get stuck. Usually any menu/whatever that appears on mouse over will remain open when some other action overlays another GUI element over it. But there are myriad other small bugs like this on windows to ios to even tiny tiling wms.
A similar thing happened to me a few years ago when calling the Swedish equivalent (112). As soon as the operator picked up the dialer just crashed and there was no trace of the call in the log.
I did this three times before switching to a friend's phone. I don't remember what apps I had or even what phone it was (except being Android) but it was a pretty bizarre and scary experience.
I see a lot of bashing of teams for touching the dialer. Please take a look at https://www.fcc.gov/mlts-911-requirements before you say that they should not touch the dialer.
Yes they royally f'd up. However Teams is a voip carrier among other things. As of Jan. 6, 2022 they are not allowed to ignore 911 anymore. They HAVE to allow 911 calls. Even being a non fixed device. And on android this does mean interacting with the dialer.
(I have no affiliation with google or microsoft. I however did switch our small company to voip earlier this year and had to take a deep dive into the legalities.)
Supporting 911 calls with the bare 911 number is not the same as overriding the phone's default 911 handling and I doubt the FCC has any regulation that says a provider functioning as a third party on a phone is required to _replace_ & disable a working built in emergency dialing function with a broken app function.
I say this as a former android dev, whose app was #1 in paid A/V apps back when Flash was still a thing... Couldn't convince me to use and android device these days.
I stopped trusting Android when a constantly crashing media scanner service prevented all system sounds from playing (which means no ringers or alarms went off).
This is Microsoft at fault for building a terrible app (and why are we surprised about this), not Android.
I have used my Android phone to call 911 and it worked correctly (though I don't remember if it was the year I had a Pixel or after I went back to Samsung).
It is not Microsoft’s fault. No app should be able to intercept 911 calls. Teams should not have received an actionable event at all here. Microsoft should not have to test the 911 call path.
That the thing though - and I should have been more clear in my original comment.
What if a user installs a third party phone app, with the intention of never using the standard one? That app would have to be able to send 911 calls.
A bug in how the hand off works - yes that's a serious issue. But certainly that's something that we should still hold Teams accountable for testing before they released their app, too.
If a regular user application can break the ability to call 911 from the default dialer, Android is at fault. Microsoft may also have messed up, but the OS failed by letting the bug manifest.
It should be Android’s task to not pass emergency calls to third party apps. Even if you “fix” Teams, any other app still can do it, and you’ll never know.
It really isn't; the fact that these things are called "phones" is a quirk of history and English etymology, not a reflection of how they're actually used. IMO the fact that we treat voice calls as some sort of special case priority that needs to be implemented in the base system increases the rate of these bugs (personal moan: why can't I use translate on emergency notifications? You'd think that that would be the most important thing to be able to translate...).
(In advance, I apologize if this seems unnecessarily harsh, but it is description of a real event and the thought process of younger me)
Unrelated, but in 2012 or something like that, I was out walking, on my way to a meeting. I literally stopped mid walk, and turned another direction, went to a store and bought an iPhone.
My, at the time, state of the art Samsung galaxy S3 had just prevented me from answer an incoming call due to a software bug. As the S3 froze and then crashed, a crushing realization hit me; what I was holding wasn't a phone, but something else. I was even a poor student at the time, but due to engagements, I was completely dependent on my phone working, or as I then realized: "Having a phone".
Not being able to call emergency services with a phone is completely unacceptable.
I am only posting to add that with my pixel 3 I am having issues with incoming calls being dropped or the interface not allowing me to accept an incoming call. Especially since the new re-design of the caller app a few months ago. Even an old phone should always be able to call and accept calls.
Due to the emergency use-cases, I really think call functions should be the highest priority of smart phones and I cannot understand why there is so much sloppiness in QA with this. There is going to be kids out there that try to call their parents and their calls get dropped, same with elderly or otherwise vulnerable. You don't always want then to call 911 as first resort. But hopefully they remember to do it if cannot get through to their carer..
Before people suggest it, getting a second phone that guarantees handling incoming calls in not practical, as they would have to dial a different number than usual in an emergency.
Android is traditionally an open system that allows you to mess with the system in all sorts of ways. I've previously replaced the default launcher and I know that you can replace the default lock screen if you want to. But that means that you can install a lock screen that prevents people without your password from making emergency calls, here's the first set of instructions I found Googling it.
Normally I feel like it's a strength of the Android operating system that users are allowed to make whatever changes they want, including handing off all responsibility for phone calls to Microsoft or whatever. But in cases like this where users might not understand what that means I wonder how we can put in better guardrails while still maintaining the systems flexibility.
One more reason to give to people when they ask me why I don't want to use Microsoft Teams. What shitshow that product is. Besides being so unreliable that it is unusable for its intended purpose it is invasive to a degree that insults me as a person that tries to have a reasonable degree of control over the software executing on my machines.
Absolutely, Google has the end responsibility here, their handsets are simply not compliant.
But MS has f*ckd up their testing, they should have definitely caught this before it was shipped and they should have been the ones to alert Google, not some random end user.
No matter how messed up an app is it should never be able to interfere with essential functions like calling 911. IMO Microsoft bears zero responsibility for this bug or testing for it. Android is entirely to blame here.
Yes, I don’t think “test they with the user logged out, the phone can still dial 911” is a test that any sane person would come up with, nor should they be expected to. The permutations that level of paranoia unlocks are basically infinite.
No, Teams is about as invasive an app as there is, and Microsoft may have had a much better chance of knowing that they were doing something with a great chance of destabilizing the system than Google ever did.
If Teams were any other app and simply playing nice this would have never happened. I'll bet you when the fix is released Google is going to drop one or more API calls that Teams hooked into.
Of course it should have never been possible for an App to do this to something that even the dumbest of dumb phones is required to be able to do. But Teams is a special kind of evil and it wants access well over and beyond what it needs to function.
How does an app developer test 911 functionality without actually placing a 911 call? I'm sure 911 operators would not be amused by such test calls; do companies have special testing cell networks that don't connect 911 calls through?
The linked Reddit thread has a whole subthread about that. A bunch of people who claim to be phone system installers say they regularly call 911 to test that it works. Apparently it's fine as long as you tell them that it's just a test and maybe ask to verify observed phone number and location. They probably don't like it if you just call and hang up and then don't answer any callbacks.
You can do a 911 test call. Make sure to tell them it's not an emergency instead of just hanging up. To play it safe, you can call your local non-emergency number and ask them how to do a test call. Sometimes they will schedule a test, sometimes they will just ask you to call outside of peak hours.
Companies have (and I don’t know the right terminology here, but you’ll get the idea) local test microcells that they use to test phones without actually connecting to the real network.
Where I live, if you want to test 911 there's a non-emergency number you can call to setup a test in advance. I think they do it all manually though, but I'm sure Microsoft could work something out for automatic testing, especially if they donated a few thousand dollars to buy whatever equipment the 911 operators needed.
Everyone seems to be blaming either Microsoft or Google in this thread, but I disagree.
I think _both_ are culpable. Microsoft teams shouldn't crash when making a 911 call. Google shouldn't hand 911 calls off to microsoft teams (though I'm not 100% clear on what the interaction should be if you have a custom phone app... maybe it should be able to handle the 911 calls? what if you install a custom phone app because the default one is broken... you'd definitely want your non-broken preference to be respected for important calls like 911).
> though I'm not 100% clear on what the interaction should be if you have a custom phone app... maybe it should be able to handle the 911 calls?
Thankfully, the law is completely unambiguous and tells us exactly how it should be handled:
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
Android is required to handle emergency calls differently.
People are jumping all over Microsoft Teams, but the problem is really that any arbitrary app can interfere with emergency calls. That’s fundamentally an OS problem.
It is both. If it is VOIP it should always allow emergency calls period. But Google ALSO screwed up by not ensuring emergency numbers go through even if the configured dialer is trying to eat it.
Obviously each one had a problem, but they are categorically different. The problem that <no emergency call could be made> was an OS problem. The problem that <Microsoft Teams could not make an emergency call> was an application problem.
Lot of people making comments about Google and Android here, and I can understand why, but they aren't the only company who make an operating system where Teams interacts unfavourably with the core OS.
No matter how many Windows updates I install, or how many times I update drivers and firmware, Teams on Windows 10 on my Dell laptop is a very unstable combination. When on video calls it causes problem conditions in the graphics drivers that destabilise Teams, sometimes other applications such as Firefox, and will fairly regularly bluescreen the OS.
Again on video calls it also interacts poorly with Killer WiFi drivers leading to:
- intermittent drop-outs in network connectivity affecting all applications, including Teams (but not other devices on my network),
- total loss of WiFi connection, requiring disable/reenable of my wireless network adapter, and occasionally a machine reboot to resolve
- again, OS bluescreens
These problems only happen during Teams video calls, and most regularly (though not always) after the system has slept and woken at least once since its last reboot.
I'm not even going to dive in to the multitude of application level problems (failing to load calendar, failing to join meetings, breaking copy & paste, and on, and on). My point is that, as much as Google is at fault here, so is Microsoft: Teams is not good software. It is not built with safe interaction with the OS in mind, and it is not well tested.
Feature-wise Teams is far and away ahead of alternatives such as Zoom, and call quality is generally better than some alternatives, such as Google Hangouts, but it's let down by poor engineering and, as I've already said, inadequate testing. In the case of OP, with very serious results.
Thanks for the tip. Weird thing is I'm not the only one experiencing these issues with the same model of laptop. Possibly a bad batch, but worthy of further investigation, for sure.
How is this issue only related to Pixel phones? If the issue is in the platform level and Teams app (or other apps that act as catalyst to this issue), how are other manufacturer phones safer?
I couldn't understand this point on why only Pixel users are affected?
I would say, accidentally dialing 911 is somewhat more acceptable than the current issue in discussion. One thing that sounds unacceptable is, Google expecting this issue to be fixed by MS Teams. At least their response should be accepting the situation and providing a security fix asap.
I've had a similar issue where no interaction worked and then physical buttons have a long-press to dial emergency. I just stayed quiet and 911 recognized it as a pocket dial and hung up.
My Pixel 3aXL called 911 on me last week out of nowhere while I was browsing the web. I have no explanation, it just started doing weird, random, frustrating p things after I upgraded to Android 12.
I hung up immediately, but they called back. I apologized profusely and explained my phone had done it, the guy sounded skeptical but let me go. Sigh.
I don't understand why everyone is blaming pixel here. If it hijacked 911 and refused to let your app that provides your actual phone service dial it or similar, people would be up in similar arms. Especially from an antitrust / competitive angle. This is what I expect to happen honestly when apps (teams in this case) register as phone services and then refuse to call some numbers.
Sure there should be a way for the call handler to reject some dials and have it go to the next in chain, but honestly this seems like a mess to me overall.
Your phone can be locked, your SIM can be invalid, but you will still be able to place an emergency call because an emergency is a crisis, by definition. I believe that there is actual regulation governing this - a phone must be able to try and place an emergency call.
The expectation is that the phone will absolutely "hijack" an emergency number to ensure that it takes place. It's a critical path that _should_ ignore everything else going on with the device.
If, instead, you allow any call-handler to take control of whether or not an emergency phone call takes place, you open the door for malware to prevent emergency calls. You open the door for subversive apps, like those used by abusive spouses, to fake emergency calls, and report the victim to their abuser. You allow a malfunctioning app to prevent someone from getting help before going through a debugging process, which isn't reasonable if you've fallen and broken a leg.
You insert the platform, in this case Google, into situations where they may become liable for allowing someone to be in danger. Possibly even actively assisting. That's a legal bombshell that should terrify the platform.
It shouldn’t happen though on an architectural level at least.
Also, don’t forget that Teams as a VOIP app also has a legal responsibility of handling 911. But of course in this case the OS call should win and the other branch should not even be taken.
It's the platform's responsibility to properly sandbox apps. It should not allow apps to intercept emergency calls under any circumstances.
Alternatively, you could have a completely open platform, and then the onus is on Microsoft Teams and the user--but neither Android nor iPhone are like that; both choose to sandbox apps by default. When I install an app on a Pixel that isn't rooted, I expect that Android will keep it from intercepting 911.
That isn’t what happened or is happening here. It’s not like the guy couldn’t make regular phone calls, if Teams had taken over as the phone service then he would have noticed the issue long ago. This is 100% an Android bug.
This makes a lot of sense from a swdev perspective (sadly).
The 911 feature is probably the least used on any android phone, so real-world testing and reporting are limited for multitude of reasons.
Developing and testing this feature is probably less convenient than normal calls, since it requires you to either have a fake 911 setup (meaning operating the phone in an rf shielded environment and with a fake tower) or actually disturbing real 911 services.
I'm in BC, Canada. The people handling 911 in my province is E-Comm, and they don't seem to have a policy on this. I've sent them an e-mail asking if they accept test calls.
Guess: e911 requires location to be sent. There is probably a special provide_e911_location intent that teams handles (makes sense. In an office environment it could add cubicle number, floor, etc). When not logged in, teams likely crashes (probably nobody tested this case), OS doesn’t handle that crash well. No call.
Only slightly related: SF now texts you instead of calling back for a 911 hangup.
I called 911 at the Montgomery BART station when visiting SF last week, because someone was having a medical emergency. I got dead air (despite strong signal) for about 2 minutes before I spotted an elevator call box. That helped me get the station attendant; once she was on her way, I hung up on 911 so I could attend to the person in distress.
10 minutes later, I got a text:
we received a 911 hangup from your phone. if you need help, call back, tell us where you are and what happened. if that was a misdial, have a good night (capitalization from original, so probably not automated?)
I think this is a good thing, for example in a situation where someone needs help but is uncomfortable voicing their emergency aloud. But it was weird to get dead air and no immediate call back.
In any case, I found it an interesting experience.
WOW. Catastrophically bad. The details really don't matter; when it comes to something like this - literally the single most important function of the device - Google as the platform owner has sole, final, non-negotiable responsibility. SVP+ level heads should roll for a fuck-up of this magnitude
now imagine a game that intercepts phone calls (because everyone totally reads the permissions sheet) and is actually able to handle 911 calls. congrats, now OP just gave an attacker their physical address, and their grandma is dead because, well, i doubt the attacker will relay the call for them.
this is a huge, huge problem and has nothing to do with Teams.
You would have thought app sandboxing on android would simply not allow this at all. 911 is just too critical to allow any app to interfere with it. The code path should be simple and uninterruptible.
Someone in another thread here said Teams itself is required by the FCC to be able to make 911 calls and that is the root of the issue. MS teams implementation clashed with the OS dialer (iiuc).
I think Teams is required to take 911 calls because it incorporates Skype for Business/Lync's PBX capabilities, which makes Teams basically an office phone like Cisco Jabber.
That makes me wonder if Teams on iOS can make 911 calls...
Maybe phones should have a "Test" feature for emergency-services?
Smoke-alarms and GFCI-devices do, enabling folks to ensure that the device'll behave properly.
Presumably there'd need to be some sort of systemic support for a test-feature, where emergency-services would have recognition of the concept such that they'd filter out test-calls, but only at the very last stages. This way the entire system performs the test, but operators wouldn't be tied up.
Alternatively, route test-calls to a test-operator, that'd presumably be an automated system, as to not burden actual emergency-services.
Just have another number that gets treated by systems as an emergency number. Something like 822. Then it should work without a sim, and whilst the phone is locked. 822 can then give an automated response.
I like the idea. I wonder what requirements should placed on its use: 911 has features that could lead to denial-of-service https://news.ycombinator.com/item?id=29495078 (e.g. if a flashmob decided to 822 at the same time).
What is more worrisome than Google's response in that thread is fanboys defending it's a completely normal and expected for a 3rd party regular app to be able to take over emergency calls
Someone died in Philly years ago due to a 911 system error that sent emergency responders to the wrong location. The father was a local COBOL developer and was somehow able to fix the bug (no idea if source was available or if he rewrote the system). The city didn't want to implement his fix, so he had to sue them to have them use the fix. I wish I could find the article to provide more details.
Good. Pro tip: don't have anything google/MS/Apple near you,both SW and HW, especially 24/7.
Don't care about what's inside the product you buy?Why should other people care about what happens to you in the aftermath?Especially when repeatedly these companies have been abusive?
This is first about self-respect more than anything, even though it may not sound like it at first glance.
You don't need their product as much as those companies need you, contrary to the popular "they're billionaires, they don't care" belief.People who think in these terms don't realize every purchase is a vote, and the more aware you are with your wallet, the more power you have, even if you are less wealthy than these corporations.This is why ignorance about subjects like privacy, security, usability, censorship matter more than not.Because inaction will eventually turn into action against you.
This is one reason I advise people in our emergency service area to use a landline for dialing 911 if they can. Landlines are more reliable and they tend to provide better location information than cell phones because they are fixed to a service address.
Also, as many of the Reddit comments state it's perfectly okay to call 911 and immediately tell the dispatcher you're testing and ask them to read you the address that appears on their console. I do it all the time in various places around our service area for QC purposes.
> If you are unsure what Android version you are on, confirm you are running Android 10 or above
My Xperia X is still on 8.0.0, it only got a few months of updates before they just silently stopped sending them, displaying that my "device is up to date!". This is a widespread problem in the Android market, in comparison, my iPad Air 2 is still getting updates 8 years after release. Google keep saying that they want to work on this, but realistically, is it ever going to happen?
I don’t know the Android UI for it, but on iOS there’s a very fast path to emergency call even when the phone is locked, and when done manually it identifies the call as being an emergency.
My opinion is that given that the phone knows you’re making an emergency call it should immediately kill all non system apps (including Builtin apps like the browser, messaging, etc being killed) to minimize chance of something like this happening, and to maximize battery life
Based on the post timestamps it took up to 9 days for Google to respond publicly. In some ways this is impressively fast (but only for Google.) In others it's incredibly slow because revenue impacting production issues get addressed in hours.
Question for HN: Is there any formal critical contact network between Google, MS, Apple or other large companies? In incident responses like this are people relying on personal contacts?
I wonder if this affects emergency services in countries other than the U.S, for example in Denmark it is 112 in case of fire, accident, you need an ambulance.
Ugh, my toddler regularly dials 911 trying to brute force thru lock screen and here this person intended it. This FAANG grindset rotating door of talent has been producing some of the most shallow shovelware releases since the dotcom boom. Product Owners are shotgunning minimally viable everything inside of aggressive release dates atop a complex house of cards to hide the advertisement business.
I see people disagreeing if this is Microsoft or Google's fault. I think if there is a use case for using a 3rd party app for the 911 call, either A. Google should have some way of detecting if the 911 call went through and/or B. Have a popup when you call 911 through a 3rd party app that says "that didn't work, force my 911 call through" which uses the system phone app.
A lot of people are hesitant to call 911 to test things out. Thinking it's illegal or whatever.
My experience (Canada) has been that they don't like it when you call and hang up.
But I would sometimes call and say "Hi, I'm mig39 from my organization, and I'm just testing that I've programmed the phone system here to dial 911 properly." They had no problem with that at all.
One of the reasons why I bought an Amazon Ring + its monitoring subscription is to have a redundancy if something goes wrong at home. It's just easier to sleep feeling safer knowing I can reach to its panic button in the control pad and get in touch with someone, in case of an emergency (the alarm system has internal battery and has redundancy using cellular data).
I see a black squirrel, which is kinda rare .. I pull the phone to take a picture and somehow it gets stuck and asks me to enter my pin.. Suddenly it doesn't recognize ,y fingerprint.. I finally get the camera app to open... It takes another second to be able to take the picture.. By the time the phone is ready, the squirrel is gone!!
I'm from Australia and it currently looks like this prevented my mother calling an ambulance for her neighbour with a suspected heart attack about a month ago. I saw this article, told her to test dialing 000 (Australias 911 equivalent), it failed, then she uninstalled teams and the call went through. This was on a Galaxy Note 9.
Apparently this page is bugged as well, the full reply to the testing question is not fully visible on my mobile phone, rotating the phone to landscape revealed the full reply.
Practical Linux phones cannot come soon enough. I am done with this nonsense. It is abundantly clear that organically developed open source software for critical tasks such as this will always be superior and likely safer due to the informed user/developer-base's ability to deal with problems as they arise.
It's almost unbelievable.. If not even Google can make their own software work on their own hardware, can you trust Android phones at all? Not that I'm particularly impressed by Apple's phones or computers for that matter, it seems they refuse to work without a connection to phone back home to Apple.
This is bad, this is very bad. That Google needs a random reddit user to debug an issue that's this severe, how many issues are there that random reddit users haven't figured out yet?
I don't think Microsoft Teams is clear of blame as well. Apps trying to do more then what they are made for is a huge problem.
I wish 911 and European emergency phone calls were handled by a totally different piece of hardware, mostly separated from the rest of the phone and with maybe a certification process that guarantees it "just works".
Smartphones are now super cool mini computers but not phones first anymore :/.
Wow. I'm surprised this is still an issue. My friend was suicidal a few years ago and I couldn't call 911 on the original Google Pixel. Made a scary situation that much worse. Made sure the next phone I bought was an iPhone. You'd think it would be fixed by now.
I've used Island to put all work applications on to a work profile to keep it seperate from the main / personal profile. I wonder if Teams still could interfere with the dialer then or when the work profile is inactive.
Software updates have also been longer and more frequent. Wonder how many people have died because their phone was updating when they needed to call 911.
This is just an anecdote. Smart tech is a net positive for your safety in general. There have probably been millions of times where auto location transmission has saved lives or prevented harm. Companies don't have to invest more resources in testing. They already have metrics to prove their product is as functional as it needs to be.
> I'm supposed to trust that a phone will do the main thing is built for, and place the call, and let me speak to the human on the other end.
We are not in 1990. Smart phones are only similar to phones in that they have "phone" in the name.
Am I missing the joke or something? You quoted a sentence from just above the updated statement that Google has confirmed the issue and working on solving it.
They need to get that phone to the FCC so the FCC can get take a look and put Google's feet over the fire to get them to figure out what the heck happened.
Edit: I just read through some of the Reddit comments and see that Teams was the culprit, which is an insane bug: There is no way that a user space app should be able to do this.
I also still think the FCC should do their own work on it too. They need to make sure Google isn't downplaying this, and is actually taking steps at the highest priority to make sure an app can't do this.
It is worth pointing out that while Google will not push an emergency hotfix for this for a whole month (promised time: January 4 update), they did push a contract tracing malware for everyone in Massachusetts https://news.ycombinator.com/item?id=27558500 no problem. The latter even overrode all "please don't auto-update apps" settings.
The more complex a project is, the more difficult it becomes to make sure it's reliable.
I have way more trust towards an old nokia phone for that kind of thing than any smartphone. It's odd how security and reliability are better retained for more minimal softwares.
I guess this will always be true.
That's why it's always better to do one simple thing and do it well. The more feature you add, the more you need to increase constraints and add new rules, at an exponential rate.
Every phone should be required to make some sort of dry-run 911 call on a regular basis to make sure it works.
Have you tried to call 911 recently? I have. Both times, I had to wait on hold over five minutes for someone to answer. "Press 1 if you need police. Press 2 for fire. Press 3 for a medical emergency. Press 4 if this is a non-emergency and you will be transferred to 311." After that there's not even hold music to let you know you haven't been disconnected.
There are almost 300 million cell phones in America. Who's going to answer those test calls? The operators who are already too busy to answer emergency calls?
I assume GP envisioned some magic where it doesn't actually go to a human operator, it just somehow does a handshake with the 911 department's equipment instead.
Still not a good idea, since you don't want a bunch of phones DDoSing 911.
> it just somehow does a handshake with the 911 department's equipment instead.
> Still not a good idea, since you don't want a bunch of phones DDoSing 911.
Eh, it doesn't sound too bad as something to roll out eventually. About 240 million 911 calls per year vs. 280 million cellphones in the US, and a dry run test would be expected to use a fraction of the resources (short call, etc). So, to test once per year I'd think you'd need to make the call handling infrastructure a small percent wider, and that extra capacity is something you could even benefit from (because phones could avoid testing at peak times).
The big problem is that this tests the actual call handling (and perhaps address reporting, etc)-- but doesn't do much to test the actual UI, audio path, etc, under the circumstance of an emergency call.
I've only had to call once. Live operator, and somehow already knew exactly what I was calling for! (It had literally just happened, too, so I knew exactly how quick they'd gotten their info together. That, or I got the same operator that got someone else's call.)
(I agree that having them handle tests might overwhelm the system. Still, it would be comforting to have the ability to test.)
In Europe we had a different number for the tests when 112 was first introduced. 113 it was I think. With the same kind of routing but not going to a real person.
The number has been taken out of service but something like this could be put back.
I've called 911 before. The other end picked up instantly. It was a shock how fast they answered. I gave my location (cross streets) and the police were there in less than 30 seconds. Pretty impressive.
(The incident I called in was... I was looking at my window and saw this bus unloading. The passengers formed a big group and started pushing each other into traffic. After seeing a couple of cars swerve and narrowly avoid the innocent victim, I thought it was time for governmental intervention. The police arrived, ushered everyone onto the sidewalk, and that was that.)
The FCC regulates 911 service. Here's the form for filing a complaint about 911 service:
https://consumercomplaints.fcc.gov/hc/en-us/requests/new?tic...
States also regulate 911 service. Try your state's office of emergency services.
There's something called "Kari's Law" that may apply here. This was passed in 2018 after someone was being attacked in a hotel room and their 9 year old daughter tried to call 911. She couldn't get through because the phone system required dialing 9 for an outside line. So, now, all business phone systems are required to recognize and pass through 911 to the main phone network. There are criminal penalties. (Microsoft might argue that "Teams" is not a "multi-line telephone system". That probably wouldn't go far with a jury. The clear intent of the law is that if you interpose something between a phone handset and the 911 network, it has to pass through 911 calls.)
The whole 911 area is heavily regulated, since it requires that so many things interoperate reliably.