The FCC regulates 911 service. Here's the form for filing a complaint about 911 service:
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.
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.
> 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.
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:
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.
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.
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.
> 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.
"If 911 is dialed on anything that is a phone, your system must connect to 911."
This is less of a "oh it's just a bug" and more of a federal compliance issue.
Serious, 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
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.
Yes, I especially balked at this part:
>>and we are currently only aware of one user report related to the occurrence of this bug.
That is a fact about Google's awareness of the bug, or their ability to be ignorant of it, not a fact about its actually frequency of occurrence.
I'm pretty sure this isn't the only time it's happened. It's the only time someone forced them to notice.
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.
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 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.
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 am not the least surprised that it trigger crashes.
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.
Its strange how many companies believe their own lies about anything requiring an explicit account being a good idea...
The perils of treating phone as "just another app", lack of testing, etc.
0118 999 881 999 119 7253
I thought it had been changed for ages.
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...
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.
I don't see why Google is to blame here
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.
"Google Support reached out to me through here "
So multi million fine threats is how you get to a human at Google.
"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."
if fine cost * probability of fine being issued > cost to address then address else end.
Would you really give up one of your yachts this year just to save ten thousand lives?
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.
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.
I ran into a similar issue with software that was trying to dial 0 for an outside line, and then a number starting with 00.
Lots of very unhappy people.
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?
The dialer is like: no I'm trying to call Europe.
9-011-49-(German number) 
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 . So even in the above two cases, the sequence "911" should never occur.
Seems like we put too much stuff on the 9, it's not like we're still using rotary phones
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?
Of course you could make “91” be the code for outside lines, forcing someone to dial “91+1-XXX-XXX-XXXX”
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).
(There are special dialing codes like dialing 011 for international that are an exception to this, but no normal phone numbers.)
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 :
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.
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?
Can't be sure about that. If someone died because they were unable to call 911, who is going to know afterwards?
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.
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.
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.
he had contacted Google support, but unfortunately, he do not get response now.
i know it isn't a verizon problem, because google tried to blame teams.
I don't know your definition of playing it down.
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.
or where you can test it, but that testing is not sufficient to ensure the functionality works
then your design is not fit for purpose.
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.
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.
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 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.
Unless there is malicious intent, I do not really see the added benefit of a lawsuit or complaint to the regulator.
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)
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?
(googling says: https://developer.android.com/guide/topics/connectivity/tele... and hook up a test device )
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?
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.
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.
PS: At least where I live, emergency services will show up at your house if you make a few 0-second 911 calls
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.
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.
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.
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.
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.
1. Running Android 10 or higher
2. Has MS Teams installed
3. User is logged out of MS Teams
4. User hasn't reinstalled MS Teams _in a while_ (or perhaps they installed MS Teams in a particular time window in the past)
1-3 seem like fairly weak filters. Unless 4 is a particularly strong filter, this sounds like it would affect a bunch of people.
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.
Sure, but I wasn't doing that.
How did this ever become acceptable?
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.
Is that really true though?
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.
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.
In any case, it's Google that is responsible to fix the mess caused by broken sandboxing of their OS.
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.
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.
That doesn't make sense, the user has to pick the app to dial with before they have an interface to enter the number.
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...
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.
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.
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?
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.
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.
Apparently, the "phone" in "smartphone" is about as relevant as is the "fun" in "funeral".
> Shells ? No.
> There are some BASIC interpreters thoght, which is a start.
There are also Java, etc., IDEs with which you can develop full Android apps. And have been for nearly a decade, at least.
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.
In software I write, the logic for 'emergency' priority events doesn't go through the same call chain for this reason.
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.
Seems that somewhere in there, someone messed up.
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'm not saying I love the tool, but phone performance itself is not the reason for me. YMMV.
Let’s not forget - someone very nearly could have died thanks to this glitch. Thankfully, a landline was available.
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?"
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 an explanation here of what data is being sent to Microsoft Teams and now MS Teams can prevent phone calls is important here.
If my organization uses MS Teams, do my phone calls on my personal device go to my company?
I’m not a teams fan, but this is taking things a tad far.
Edit: dialer has been autocorrected to diaper
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.
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.
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.
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.)
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?
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.
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.
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.
As a 100% remote worker, this issue is completely unacceptable. Teams should have zero involvement in SIM dialing.
And Android is defective too, a user app should not have this level of access.
Let me zoom in...
> we expect a Microsoft Teams app update to be rolled out soon
Seems like a Microsoft issue to me.
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.
except that any app could do this, and it just happens to be Teams that did.
Why try to cram in two lifes into the one life you have?
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.
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.
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.
"Oh, we decided to divert all calls to Teams first" is just not going to fly.
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.
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.
So, Teams can do that because it isn't "user mode". There are others too, https://play.google.com/store/apps/details?id=com.simplemobi... is one.
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.