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.
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.