> 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.
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.
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.
> 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.
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.
> 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
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.
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.
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.
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.
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.
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.
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,...?
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.
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.
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
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.
> 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.
> 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".
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.
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'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.
> 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...
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…
> 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.
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.
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.
> 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?
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)
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.
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.
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.
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.
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.
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.
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.
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.)
> 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.
> 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))
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"
> "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?"
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.
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,…
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.
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".
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.
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 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.
IMO while Microsoft and Google should work together to solve this as soon as possible, the longer term solution should not involve Microsoft. This sounds like something Google should fix at their end.
No customization done by the user, including installation of apps should prevent a user from being able to call 911, period.
That's actually a real issue that needs addressing. Any phone that makes 911 calls should still get security updates. All phones that can reach the cell network can still make 911 calls per FCC requirement.
Imagine the worse case scenario where malware infects the phone but requires a credit card to call 911.
Maybe congress will get around to this to make Google and everyone else do the right thing, but from my perspective Google should have done the right thing here.
Worst case scenario? Sounds like best case scenario to me so long as no one is harmed.
It will take some horribly idiotic event like that to get the manufacturers to actually address that when you sell a phone you're selling hardware and software.
If Google are concerned they could fix it more easily that a software update for older, unsupported phones - they could just mark every app that registers itself as a third party dialer as incompatible with older Pixel devices in the Play Store, and remotely remove them from Pixel phones presumably. It'd be a bit "user hostile" but you have to remember that you don't really control the code on your phone if you use Google services, so it's entirely possible for them to act this way.
EOL does mean something. I don't believe 3 years is long enough personally, but even if it was 10 years the same problem would exist, just for older phones. Then it becomes a semantic argument about where phones should ever have an EOL date for critical fixes.
I think Google would argue that malware interfering with your phone after its EOL date is a reason why you should upgrade your phone to a newer model rather than use that as a reason to extend the life of their phone software indefinitely.
The thing I think people are missing is that the response from Google indicates that this isn't a Pixel issue. This is a "all android phones on Android 10+" issue.
Without full cooperation from manufacturers, there's really not a lot that can be done outside of blacklisting all dialer apps on the Play store and even that would do little for anything already installed.
I think you miss the point here. Security updates for phones need to be longer than 3 years -- for that reason.
The pixel 2 is already EOL'd 4 years after it's release, but it can still make 911 calls. I believe there are people that still depend upon that phone to make phone calls -- and therefore need 911 when they need it.
Oh definitely. I wasn't disagreeing with that aspect. Everybody had been focusing on how the Pixel line would be able to solve this issue which kinda ignores that bigger issue that the entire industry needs to be maintaining these security updates. There's no good reason for OS security updates to be gated behind manufacturer control.
What would you like them to do? Google couldn't retroactively make it possible to patch every phone on the planet even if they wanted to, and the phone manufacturers aren't likely to treat this as any more special than the other bugs that they aren't patching
Well, I'd expect them to bring the phones into compliance with the law. Quoting section 22.921:
> Mobile telephones manufactured after February 13, 2000... must incorporate a
special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call...
If a phone can't access 911, it's not legal. Frankly, it's an indictment of the system architects that this bug is possible at all.
So you are advocating to put anyone who has a rooted phone that doesn't get this dumb update to fix an issue with Microsoft Teams in jail?
Seriously, this sounds like a Teams issues. Google does by default incorporate what is required and it isn't until Teams takes permission from the phone app that an issue even occurs.
But what if I as the user install software on my phone that isn't capable of calling 911?
I own the phone and I am able to install whatever software and whatever operating system I like. I don't want it to seem like I'm defending Google here, but should manufacturers really be responsible for the software someone installs on their portable computer?
Moreso than most, this regulation is written in blood. The reason this and other FCC 911 rules came about was that there were numerous cases of people trying to call 911 and failing due to software "issues". The FCC said enough and mandated that if it were possible to complete a call, the phone is required to.
Installing your own OS that intentionally doesn't support 911 handling would be in the "not possible" category just like a user who cut their antenna. For anything less than that, Google (and other manufacturers) are absolutely responsible for ensuring the 911 code path can't be disrupted. People have literally died from this.
If they can determine that any phone in usage today running Android software may be prone to this bug they should issue an immediate recall on all devices. That's likely to be almost every Android device purchased in the past couple of years. This scale of recall is not without precedent.
I don't think anyone is expecting google to patch every phone on the planet (assuming you mean every android device ever released). But they should be able to patch every phone of theirs including every old pixel and nexus.
And if they can't, they should make it clear to the user/owner that their phone isn't supported and that means that their lives or the lives of others could be in jeopardy as a result. In fact, perhaps their phones should have an expiration date and should just stop working after sometime. Or at least disable critical functionality that their required to be in compliance with (FCC regulations) since they've decided to no longer support the device. Moreover, this date and timeline should be clear from the point in time when you purchase the device.
Of course this could all be done by the network providers only allowing supported devices on their network, but we all know how that would end up.
This isn't just some bug, and if google wants to participate and be taken seriously in this industry, they should stand by their products and customers.
I wouldn’t jump to conclusions before we fully understand what’s happening. Maybe this issue was introduced in the latest version of android (that would be my guess seeing that it was just discovered) thus fixing it in a patch release on that version would fix it for everyone. You with an older pixel have nothing to worry about because you couldn’t update to this version anyhow.
The longer term solution is not not use Microsoft Teams at all. I made this decision a while ago, previously I tried to accommodate customers that required 'Teams' for meetings but I figured it isn't worth the hassle. I lost one customer over this, good riddance, I'm sure they'll come to their senses some day.
Maybe you other reasons to drop Teams, but this would not be one.
Google/Android are clearly tasked with handling 911/emergency calls. Teams is not - I doubt that it is even in their spec - they should expect 911 to route right past them.
Google effed up this one big time.
They need to fix it for every app, not just Teams.
It literally does not matter what Teams does - even if Teams maliciously did every wrong thing they possibly can, it's the duty of the phone manufacturer to ensure that 911 still works, it's Google's duty to ensure that Teams or any other app can't break emergency calls no matter how they try; the law literally requires the phone to recognize that a 911 is being made and override any programming (e.g. Teams) that may interfere with that. If Google can't do that with an over-the-air update, they can issue a full recall for all the affected Pixel phones.
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
It doesn't matter what Teams does. Android is required to ignore Teams in the case of an emergency call. That's the law.
My understanding is that emergency calls for any global locale are supposed to be an entirely separate band of communication from regular phone calls — e.g., they must work even without a SIM card, an account, etc.
So, emergency calls should be ENTIRELY OUT OF SCOPE FOR ANY APP software. Period.
It should be a low-level override/bypass, and NO app software software should ever be allowed to even touch emergency calls, let alone required to handle them.
Expecting all apps to handle life-critical emergency calls correctly is a profoundly stupid idea, guaranteed to produce a multiplicity of failures (and if that expectation did exist, Google must damn well announce it as a deadly serious requirement in bold, uppercase, red flashing letters to anyone wanting to use phone_call_handling permissions, but they don't, afaik).
So, we don't need to know anything about Teams or other app software in this case, only about the emergency calls side/back channel, and that any app, including Teams, will ZERO responsibility for handling emergency calls, or even ability to touch them.
So, it is Google that effed up big time here (regardless of Teams' other issues). Unless you make a solid case for the profoundly stupid idea that all phone-related app software should be responsible for handling life-critical emergency calls, your statement is plainly wrong.
There is a reason this materialized with teams and not with any one of the 10's of thousands of other apps out there: Teams is by far the most invasive piece of shit there is, it tries to hook into everything it can get its grubby little endpoints into.
Both parties are to blame. Teams shouldn't have behaved the way it did, Android should have failsafes to prevent this from happening. A great example of not letting developers do what they want...
Sure, Android should absolutely not allow any apps to interfere with 911 calls, and so however Teams achieves this, should not be possible. But some blame certainly goes to Teams here as well for causing the situation by trying.
I suspect that this little tidbit here is the root cause:
"If a Teams client is not located at a tenant-defined dynamic emergency location, emergency calls from that client are screened by a national call center to determine the location of the caller before transferring the call to the PSAP serving that geographic location."
Also, "If a Teams client for a United States Calling Plan user doesn't dynamically acquire an emergency address within the United States, then the registered emergency address is used to help screen and route the call. However, the call will be screened to determine if an updated address is required before connecting the caller to the appropriate PSAP."
Which is a clear violation of Kari's Law. A business phone system in the US is absolutely not allowed to intercept and divert 911 calls.
One thing I do want to point out is that "not allowing any apps to interfere with 911 calls" is much more complex than it sounds:
1. What about someone who has a tablet (with no cellular functionality) but has a VoIP app installed?
Clearly, the only way to call 911 on such a device would be for it to go through the VoIP app, so it seems like Android at the very least still needs VoIP apps to be able to handle 911 calls under certain circumstances, such as when there is no cellular functionality.
2. How about a situation where a cellular phone has no communication with any cell towers (for any network) but has a VoIP app installed and access to wifi?
Unlikely, to be sure, but possible. In this case, the only way for the phone to reach 911 would, again, be through the VoIP app. If 911 access must get through no matter what, Android would have to let the call go through the app, despite that the phone has cellular functionality.
Those are likely just a couple of instances and there's almost certainly others I haven't thought of.
A solution could be to give the Android system dialer first preference. If it fails to call the number (network issues, no signal) it could automatically pass off the call to the first registered VoIP app
That said, the Google Play store should also have more stringent reviews for apps that want dialer access. Their review should verify whether emergency services can be called regardless of signed-in status, and location
I would be happy to get that somewhere in Google someone is either signing off on such a review requirement right now or has done so in the last couple of days.
It would also be quite cool is 3rd party apps didn't need and use permissions like "listen to who am I calling". Why a chat/online calling application even need that? Only to collect metadata about their users?
full link, that on mobile will only show some comments if you aren't using their app, if you try to view them all, will force you to sign in or use their app. For me, when telling it to use the app, takes me to the home screen instead of the thread I was trying to see. old.reddit.com works so much better than the new reddit when linking out
For mobile use, nothing really beats i.reddit.com. Clean simple interface, only a couple minor annoyances such as search not supporting all the options.
That's the link. It works for users of the site mobile or not, app or browser is a choice. If you want to use old you can change the url or actually sign in and set it as preferences instead of being a lurking non-participant. People can choose what way they view it but that's the real link. If you're really concerned about comments or mobile interface or whatever maybe you should sign in and be a user of the site otherwise you're opinion doesn't really matter now does it. Point is don't force ppl to the old.reddit link.
It's not "the" link. They are both valid links to the same thing.
> It works for users of the site mobile or not, app or browser is a choice.
No, it doesn't work properly.
> you can change the url
It's nice, when linking people to an article, to not give them extra work to see it.
> or actually sign in
Shouldn't have to, obviously!
> instead of being a lurking non-participant
Nothing is wrong with lurking.
> otherwise you're opinion doesn't really matter now does it
1. That's dumb, yes it does.
2. This is a different site from reddit. Even if we accept your participation premise, the link is on HN, so it's HN opinions that matter. Reddit accounts are totally irrelevant; only HN accounts matter here.
> don't force ppl to the old.reddit link.
What happened to "you can change the url"? (Not that I agree with that idea in general, but I think it's much more valid for a dislike of aesthetics and much less valid for making a site function properly.)
"Based on our investigation [...] We determined that the issue was being caused by unintended interaction between the Microsoft Teams app and the underlying Android operating system. [...] If you have the Microsoft Teams app downloaded, but are not signed in, uninstall and reinstall the app. While this will address the problem in the interim, a Microsoft Teams app update is still required to fully resolve the issue. [...]"
Now I'm really curious as to what that "unintended interaction" was.
Star Trek was always upheld as a model of the future. But instead of transporters and replicators and space travel, we got all the bad stuff from Star Trek.
Everything breaks all the time. Technology doesn't do what we expect it to do. The latest, greatest inventions are held together with gum and bailing wire. Computers let us down when we need them the most.
That isn't true at all. If you read the postmortems on the USS McCain and USS Fitzgerald collisions, you'll find that one of the contributing factors was the fact that both ships had lots of issues with the computers and software controlling their sensors and communications. This post (https://fixvms.com/) on the mapping software for the US submarine fleet doesn't raise confidence either.
Issues with software controlling communications isn't the same as issues sending communications.
If you're telling me there are ships running in the defence force that can't actually communicate with other people at the drop of a hat, at all times, then how is that even possible? That requires some serious negligence.
In a lot of instances, if the system fails, the plane falls out of the sky, so I am pretty sure we're doing that well.
If you're telling me there are ships running in the defence force that can't actually communicate with other people at the drop of a hat, at all times, then how is that even possible? That requires some serious negligence.
Indeed it does, but unfortunately ships have to be designed to constraints other than, "Works perfectly all the time, even in combat." For example, one of the reasons that the British lost HMS Sheffield during the Falklands War is because, due to issues with her antenna layout, she was unable to use her radar and satellite communications at the same time. When the Argentine planes launched an Exocet at her, she was in the middle of using the satellite antenna, and thus missed the incoming missile. Why was the antenna layout so boneheaded? Budget cuts during the shipbuilding program, which forced a reduction in size and consolidation of antennas.
In a lot of instances, if the system fails, the plane falls out of the sky, so I am pretty sure we're doing that well.
The numerous issues we've had with communication and sensor fusion on the F-35 indicate that we aren't. Now, the military absolutely assures us that those issues have been resolved and the F-35 is great now, but I think I can be forgiven for not taking their word 100% at face value.
I've been using video conferencing software, and hardware in a few cases, for about 20 years, and I don't remember the last time it failed to connect first time. It definitely used to but that hasn't been a problem for a very long time.
I run into problems with video conferencing applications on a semi-weekly basis. The most common is when the dialin number (I use a desk phone for the sound quality) connects to one of their "bad" lines and [doesn't connect, is delayed, can't hear anyone, nobody can hear me, etc... pick your failure of the day]. But there's many times where it fails in other, purely software ways.
Microsoft made a special point of getting people used to the idea that nothing can be expected to work right. Before Microsoft, if something didn't work, you sent it back for a refund, angrily. Since, it is "Have you tried rebooting it?" No refunds, ever.
Everybody else relaxed into a Microsoft level of expectation. Anybody who doesn't, spends money their competitors don't.
(If you are too young to remember: this is literally true.)
This is not accurate. All complex software has had bugs since Grace Hopper's moth, at least, and it was never common to seek refunds because of software errors. Microsoft is only notable because DOS and Windows became ubiquitous in a way that no previous software had, exposing the whole world to unreliable software.
(I've been a professional programmer since the mid 1980's, so I do remember. )
Have you used Office? Whatever those apps are now, online, in Teams, stand-alone, it’s a steaming mess. Various functions work in various places and things like moving an image are just ridiculously broken.
I never said Microsoft makes good software. Indeed, Office is often very buggy.
My point is that Microsoft isn’t unusual in this regard at all, except that their software has become very popular. In other words, people experience Microsoft bugs very often, not because Microsoft software is unusually bad, but because Microsoft’s software is unusually prevalent in the world.
This is unfair. The requirements for consumer software have become exponentially more complex during Microsoft's tenure as leader. Hardly anything worked quite right in the 90s or 00s.
Microsoft predated the Apple ][ too, but it's moot either way. Was MS-DOS so buggy and so profoundly influential that it dramatically lowered Apple's standards - and everyone else's - over the course of the two and a half years between the launch of the IBM PC and the launch of the Macintosh?
Macintosh and Amiga, without any sort of memory protection, could easily be made to crash by bugs in any program. But crashing was the exception, and an embarrassment to be fixed as quickly as possible.
Windows, instead, absolutely routinely crashed every day, or even several times a day. A few people managed to keep it up for days between crashes. It would crash even when you weren't using it.
I had an Apple A/UX system that stayed up for months at a stretch. That was simply normal for Unix, and later Linux. Even in the mid '90s it was expected that a Linux system would be rebooted only after you deliberately shut it down to upgrade to a new release or install new gadgets. (This was before there was USB.)
Microsoft ended up redefining crashing to mean, not just needing to reboot, but failing to reboot so you would need to re-install the OS, because something got corrupted on disk. It was totally normal and expected to need to reinstall Windows every few weeks or, sometimes, months, and everyone got used to that.
Look up "monopoly". Users are not the customer. Equipment had, as it still does, MS pre-installed. You could not buy a system without, and contracts were written such that vendors could not afford to offer an alternative.
Microsoft worked fine for the actual customers, the system integrators, because all it needed to do was install and register. Once the system was delivered to their customer, software failures were Somebody Else's Problem, and did not affect the actual customer.
Economically speaking, software failure costs were exported to the hapless users, who were not sophisticated enough to blame anybody, and not in a position to demand satisfaction from anybody.
Why does Android even allow third-party apps to handle 911? This isn't just a Teams bug, this is a design bug in Android. I have Teams installed and now I'm worried about this too.
I am looking forward to people getting outraged once again when Android does not allow third-party apps to handle 911. There'd be dozens of articles on HN about how Google is being anti-competitive and outrage will keep pouring in.
HN might bean outrage machine some days, but like every Voip thing ever says you can't call emergency services with them. I always believed it to be a SLA deficiency in consumer internet? I'm guessing a strong preference for the real cell network to handle the calls would be necessary until this changes. Unless you can actually swap out the "phone" app on Android to have a 3rd party app make a real phone call?
Yes, any app can be a phone app ("dialer" in Android parlance), and there is a user preference to determine the default dialer app for sending and receiving calls.
In fact, Google has themselves made several available over the years; Hangouts and Google Voice are two examples.
In fact Teams itself has E911 support, you have to enable it if you setup a phone number PBX.
What is missing is a way to say “emergency call failed” and pass it to another handler (perhaps even a low-level one built into the cellular part of the phone itself).
I like this feature, it means I don't need to use the crappy dialer that some manufacturer made for me. It's also a good feature for VoIP apps because Android's built-in SIP client works but isn't very clear when something goes wrong.
It could be that there is some kind of design bug (no way for a dialer to indicate that emergency numbers cannot be dialed) but it could also be an actual Teams bug (Teams indicates that it can dial 911, sets up a connection that dies in the background).
Because it specifically happens with Teams installed but not signed in, my guess is that the latter is the problem: Teams tells the OS "yeah sure let me dial that for you" but then doesn't complete the call because it wants you to log in to MS first. Reinstalling the app, as suggested, would kill all associations with the standard dialer, but an update from MS is necessary to fix the main bug. I have a feeling the promised update for 2022-01-04 will remove the ability for these dialers to call emergency numbers all together.
In my opinion there should at least be a setting (enabled by default) to send emergency calls through the system dialer, if it's not enforced automatically already.
Android lets third-party apps replace the entire calling process, so depending on the setup there is no OS component that even knows what number you are trying to dial before the dialer actually tells the OS about it.
Not sure if Teams does that, if not I guess it would be possible, although I'm not sure if there aren't cases where suddenly a different (=an OS component) app than the user expects taking over also would be bad, e.g. if someone used a special dialer for accessibility purposes. Maybe this should be behind special review and testing, at least this specific bug here seems like it'd have been easy to catch if emergency calling behavior was tested.
Maybe they thought, we could be like Apple and force everyone to use our apps or else... Or we can allow 3rd party dialer apps and notify the user of the risk deep in a ToS agreement.
The person was able to make other calls right before the attempted 911 call, though, so while it could be something like this it seems like it might be more complicated.
One more reason to give to people when they ask me why I don't want to use Microsoft Teams. What shitshow that product is. Besides being so unreliable that it is unusable for its intended purpose it is invasive to a degree that insults me as a person that tries to have a reasonable degree of control over the software executing on my machines.
Absolutely, Google has the end responsibility here, their handsets are simply not compliant.
But MS has f*ckd up their testing, they should have definitely caught this before it was shipped and they should have been the ones to alert Google, not some random end user.
How does an app developer test 911 functionality without actually placing a 911 call? I'm sure 911 operators would not be amused by such test calls; do companies have special testing cell networks that don't connect 911 calls through?
Companies have (and I don’t know the right terminology here, but you’ll get the idea) local test microcells that they use to test phones without actually connecting to the real network.
You can do a 911 test call. Make sure to tell them it's not an emergency instead of just hanging up. To play it safe, you can call your local non-emergency number and ask them how to do a test call. Sometimes they will schedule a test, sometimes they will just ask you to call outside of peak hours.
Where I live, if you want to test 911 there's a non-emergency number you can call to setup a test in advance. I think they do it all manually though, but I'm sure Microsoft could work something out for automatic testing, especially if they donated a few thousand dollars to buy whatever equipment the 911 operators needed.
The linked Reddit thread has a whole subthread about that. A bunch of people who claim to be phone system installers say they regularly call 911 to test that it works. Apparently it's fine as long as you tell them that it's just a test and maybe ask to verify observed phone number and location. They probably don't like it if you just call and hang up and then don't answer any callbacks.
No matter how messed up an app is it should never be able to interfere with essential functions like calling 911. IMO Microsoft bears zero responsibility for this bug or testing for it. Android is entirely to blame here.
Yes, I don’t think “test they with the user logged out, the phone can still dial 911” is a test that any sane person would come up with, nor should they be expected to. The permutations that level of paranoia unlocks are basically infinite.
No, Teams is about as invasive an app as there is, and Microsoft may have had a much better chance of knowing that they were doing something with a great chance of destabilizing the system than Google ever did.
If Teams were any other app and simply playing nice this would have never happened. I'll bet you when the fix is released Google is going to drop one or more API calls that Teams hooked into.
Of course it should have never been possible for an App to do this to something that even the dumbest of dumb phones is required to be able to do. But Teams is a special kind of evil and it wants access well over and beyond what it needs to function.
Everyone seems to be blaming either Microsoft or Google in this thread, but I disagree.
I think _both_ are culpable. Microsoft teams shouldn't crash when making a 911 call. Google shouldn't hand 911 calls off to microsoft teams (though I'm not 100% clear on what the interaction should be if you have a custom phone app... maybe it should be able to handle the 911 calls? what if you install a custom phone app because the default one is broken... you'd definitely want your non-broken preference to be respected for important calls like 911).
> though I'm not 100% clear on what the interaction should be if you have a custom phone app... maybe it should be able to handle the 911 calls?
Thankfully, the law is completely unambiguous and tells us exactly how it should be handled:
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
Android is required to handle emergency calls differently.
Every phone should be required to make some sort of dry-run 911 call on a regular basis to make sure it works.
Have you tried to call 911 recently? I have. Both times, I had to wait on hold over five minutes for someone to answer. "Press 1 if you need police. Press 2 for fire. Press 3 for a medical emergency. Press 4 if this is a non-emergency and you will be transferred to 311." After that there's not even hold music to let you know you haven't been disconnected.
There are almost 300 million cell phones in America. Who's going to answer those test calls? The operators who are already too busy to answer emergency calls?
I was more thinking that there should be a system for making dry run calls, such that no human actually has to be involved, and that phones should be required to exercise that system on a regular basis, so that edge cases that weren't caught in automated testing will eventually be caught.
I assume GP envisioned some magic where it doesn't actually go to a human operator, it just somehow does a handshake with the 911 department's equipment instead.
Still not a good idea, since you don't want a bunch of phones DDoSing 911.
> it just somehow does a handshake with the 911 department's equipment instead.
> Still not a good idea, since you don't want a bunch of phones DDoSing 911.
Eh, it doesn't sound too bad as something to roll out eventually. About 240 million 911 calls per year vs. 280 million cellphones in the US, and a dry run test would be expected to use a fraction of the resources (short call, etc). So, to test once per year I'd think you'd need to make the call handling infrastructure a small percent wider, and that extra capacity is something you could even benefit from (because phones could avoid testing at peak times).
The big problem is that this tests the actual call handling (and perhaps address reporting, etc)-- but doesn't do much to test the actual UI, audio path, etc, under the circumstance of an emergency call.
In Europe we had a different number for the tests when 112 was first introduced. 113 it was I think. With the same kind of routing but not going to a real person.
The number has been taken out of service but something like this could be put back.
I've only had to call once. Live operator, and somehow already knew exactly what I was calling for! (It had literally just happened, too, so I knew exactly how quick they'd gotten their info together. That, or I got the same operator that got someone else's call.)
(I agree that having them handle tests might overwhelm the system. Still, it would be comforting to have the ability to test.)
I've called 911 before. The other end picked up instantly. It was a shock how fast they answered. I gave my location (cross streets) and the police were there in less than 30 seconds. Pretty impressive.
(The incident I called in was... I was looking at my window and saw this bus unloading. The passengers formed a big group and started pushing each other into traffic. After seeing a couple of cars swerve and narrowly avoid the innocent victim, I thought it was time for governmental intervention. The police arrived, ushered everyone onto the sidewalk, and that was that.)
This is not an issue I have ever had. Ever. I use to call 911 quite frequently, as well as part of my job duties (I worked in a group home with individuals who had developmental disabilities and were quite violent). I'm sorry to hear about your situation, but this should most definitely not be happening. Pick-up should be instantaneous.
I'm not at all surprised by this. For a 5 year span I used probably 4-5 different Android phones, from HTC & Samsung. All of them had this kind of glitch, where some kind of race condition gets the system stuck in an unanticipated state. UI elements that were supposed to scroll smoothly off the screen would get stuck halfway. Some system app would lock out touch events temporarily while loading something, and it would stay locked until a hard reboot.
I think it's a symptom of a system that's designed as a stack of abstraction layers, with developers who don't communicate. The developers of project A think a bug is a minor issue, not knowing that project B relies on it for something critical.
It's hard to write an app for a platform like this, too. Instead of one cohesive target, you have discontinuous abstraction layers.
Looks like Microsoft Teams was part of the problem here. I assume they had to hook into some semi-documented functionality that Google wasn't aware of or thought no one would use. On iOS, where Apple keeps tight control over their API surface, this is less likely to happen.
Android has the concept of an Intent[0] which are basically a category of apps that can fulfill a functionality like sending an email, browsing the internet, or dialing a number, etc.
So a developper can create contacts/caller app so that for example, when you click on a call button from say a google search, the OS asks the user to pick one app that was declared to be able to ACTION_CALL.
If I had to guess, I'd say it's something having to do with Teams being given priority on calls followed by failure to having priority for emergency calls and no way to gracefully recover.
Quickly browsing the documentation I see comments like
Note: there will be restrictions on which applications can initiate a call; most applications should use the ACTION_DIAL.
Note: this Intent cannot be used to call emergency numbers. Applications can dial emergency numbers using ACTION_DIAL, however.[1]
I have yet to use any system where the UI can’t get stuck. Usually any menu/whatever that appears on mouse over will remain open when some other action overlays another GUI element over it. But there are myriad other small bugs like this on windows to ios to even tiny tiling wms.
Good. Pro tip: don't have anything google/MS/Apple near you,both SW and HW, especially 24/7.
Don't care about what's inside the product you buy?Why should other people care about what happens to you in the aftermath?Especially when repeatedly these companies have been abusive?
This is first about self-respect more than anything, even though it may not sound like it at first glance.
You don't need their product as much as those companies need you, contrary to the popular "they're billionaires, they don't care" belief.People who think in these terms don't realize every purchase is a vote, and the more aware you are with your wallet, the more power you have, even if you are less wealthy than these corporations.This is why ignorance about subjects like privacy, security, usability, censorship matter more than not.Because inaction will eventually turn into action against you.
People are jumping all over Microsoft Teams, but the problem is really that any arbitrary app can interfere with emergency calls. That’s fundamentally an OS problem.
It is both. If it is VOIP it should always allow emergency calls period. But Google ALSO screwed up by not ensuring emergency numbers go through even if the configured dialer is trying to eat it.
Obviously each one had a problem, but they are categorically different. The problem that <no emergency call could be made> was an OS problem. The problem that <Microsoft Teams could not make an emergency call> was an application problem.
Since I don't use Find My Phone often enough, my Pixel 3 helpfully decided to remove location permissions from it. Would've been in for a surprise the next time I lose my phone had I not caught the notification.
Oh wow, this is true for me as well. Need to check if the app permission is required or if the location tracking works separately through some system service.
I've lost a phone with location tracking turned off. You can still disable the phone remotely and assign a lock screen message for the findee to contact you.
If you mean the Find My Device app it only asks for foreground location permission so I would assume the actual device "beacon" is part of the system not that app.
I don't understand why everyone is blaming pixel here. If it hijacked 911 and refused to let your app that provides your actual phone service dial it or similar, people would be up in similar arms. Especially from an antitrust / competitive angle. This is what I expect to happen honestly when apps (teams in this case) register as phone services and then refuse to call some numbers.
Sure there should be a way for the call handler to reject some dials and have it go to the next in chain, but honestly this seems like a mess to me overall.
It's the platform's responsibility to properly sandbox apps. It should not allow apps to intercept emergency calls under any circumstances.
Alternatively, you could have a completely open platform, and then the onus is on Microsoft Teams and the user--but neither Android nor iPhone are like that; both choose to sandbox apps by default. When I install an app on a Pixel that isn't rooted, I expect that Android will keep it from intercepting 911.
Your phone can be locked, your SIM can be invalid, but you will still be able to place an emergency call because an emergency is a crisis, by definition. I believe that there is actual regulation governing this - a phone must be able to try and place an emergency call.
The expectation is that the phone will absolutely "hijack" an emergency number to ensure that it takes place. It's a critical path that _should_ ignore everything else going on with the device.
If, instead, you allow any call-handler to take control of whether or not an emergency phone call takes place, you open the door for malware to prevent emergency calls. You open the door for subversive apps, like those used by abusive spouses, to fake emergency calls, and report the victim to their abuser. You allow a malfunctioning app to prevent someone from getting help before going through a debugging process, which isn't reasonable if you've fallen and broken a leg.
You insert the platform, in this case Google, into situations where they may become liable for allowing someone to be in danger. Possibly even actively assisting. That's a legal bombshell that should terrify the platform.
It shouldn’t happen though on an architectural level at least.
Also, don’t forget that Teams as a VOIP app also has a legal responsibility of handling 911. But of course in this case the OS call should win and the other branch should not even be taken.
That isn’t what happened or is happening here. It’s not like the guy couldn’t make regular phone calls, if Teams had taken over as the phone service then he would have noticed the issue long ago. This is 100% an Android bug.
I stopped trusting Android when a constantly crashing media scanner service prevented all system sounds from playing (which means no ringers or alarms went off).
This is Microsoft at fault for building a terrible app (and why are we surprised about this), not Android.
I have used my Android phone to call 911 and it worked correctly (though I don't remember if it was the year I had a Pixel or after I went back to Samsung).
It is not Microsoft’s fault. No app should be able to intercept 911 calls. Teams should not have received an actionable event at all here. Microsoft should not have to test the 911 call path.
That the thing though - and I should have been more clear in my original comment.
What if a user installs a third party phone app, with the intention of never using the standard one? That app would have to be able to send 911 calls.
A bug in how the hand off works - yes that's a serious issue. But certainly that's something that we should still hold Teams accountable for testing before they released their app, too.
It should be Android’s task to not pass emergency calls to third party apps. Even if you “fix” Teams, any other app still can do it, and you’ll never know.
If a regular user application can break the ability to call 911 from the default dialer, Android is at fault. Microsoft may also have messed up, but the OS failed by letting the bug manifest.
I say this as a former android dev, whose app was #1 in paid A/V apps back when Flash was still a thing... Couldn't convince me to use and android device these days.
It really isn't; the fact that these things are called "phones" is a quirk of history and English etymology, not a reflection of how they're actually used. IMO the fact that we treat voice calls as some sort of special case priority that needs to be implemented in the base system increases the rate of these bugs (personal moan: why can't I use translate on emergency notifications? You'd think that that would be the most important thing to be able to translate...).
I worked at Motorola's cellular division 20 years ago. I recall a "stop ship" incident when a 911 bug was discovered. That is, we halted the factory and shipments until the bug was fixed and a new software image was available.
The phone's callstack takes a lot of special actions when calling 911, including locking onto any tower even if it is not in the preferred roaming list. As with many exceptional conditions, these code paths are often not as well tested.
I wonder if there should be a 911-like test number that would cause the phone and the network to go through the emergency call procedure, just not connect to the actual call center.
Yes please.
I develop Android custom ROMs and I have no idea whether I'm putting people's lives in danger. And it's not just whether calling works, but also E911.
Even when I used to work at a smartphone maker we didn't have any process for that.
Just call 911, and when connected state that it's a test call and hang up. 911 calls have plenty of capacity for occasional test calls, and the need to test them clearly is important to reduce the risk of them not working when needed.
If you need to do automated tests, there is a test flag in the android dialer API which will make the call but mark it with some test flag so you get a recorded message not a human answering.
Remember that an OS ROM (especially a custom one) may not be just for one particular country or region. Here in the UK the emergency number is 999 (and also 112 on mobiles) and we are constantly told that the emergency services are understaffed, so making test calls would be irresponsible.
Do not do this - I believe it may even be illegal in the UK without per-arranging.
In the UK you need to email BT (who operate the emergency system) and arrange a window to place a series of test calls to both 999 and 112. They will give you a time, a date and a script to exactly follow. If you pre-schedule with them it's supported.
How is this issue only related to Pixel phones? If the issue is in the platform level and Teams app (or other apps that act as catalyst to this issue), how are other manufacturer phones safer?
I couldn't understand this point on why only Pixel users are affected?
now imagine a game that intercepts phone calls (because everyone totally reads the permissions sheet) and is actually able to handle 911 calls. congrats, now OP just gave an attacker their physical address, and their grandma is dead because, well, i doubt the attacker will relay the call for them.
this is a huge, huge problem and has nothing to do with Teams.
You would have thought app sandboxing on android would simply not allow this at all. 911 is just too critical to allow any app to interfere with it. The code path should be simple and uninterruptible.
Someone in another thread here said Teams itself is required by the FCC to be able to make 911 calls and that is the root of the issue. MS teams implementation clashed with the OS dialer (iiuc).
I think Teams is required to take 911 calls because it incorporates Skype for Business/Lync's PBX capabilities, which makes Teams basically an office phone like Cisco Jabber.
That makes me wonder if Teams on iOS can make 911 calls...
Apparently this page is bugged as well, the full reply to the testing question is not fully visible on my mobile phone, rotating the phone to landscape revealed the full reply.
I would say, accidentally dialing 911 is somewhat more acceptable than the current issue in discussion. One thing that sounds unacceptable is, Google expecting this issue to be fixed by MS Teams. At least their response should be accepting the situation and providing a security fix asap.
I've had a similar issue where no interaction worked and then physical buttons have a long-press to dial emergency. I just stayed quiet and 911 recognized it as a pocket dial and hung up.
Guess: e911 requires location to be sent. There is probably a special provide_e911_location intent that teams handles (makes sense. In an office environment it could add cubicle number, floor, etc). When not logged in, teams likely crashes (probably nobody tested this case), OS doesn’t handle that crash well. No call.
I'm in BC, Canada. The people handling 911 in my province is E-Comm, and they don't seem to have a policy on this. I've sent them an e-mail asking if they accept test calls.
Can you imagine a more cancerous, dysfunctional software stack than a Microsoft app on a Google platform?
I cannot stress how insane it is that these megacorps suck up some the best talent on earth and then saddles them with a corporate culture that throttles their abilities to the point that they might as well be actual retards.
Only slightly related: SF now texts you instead of calling back for a 911 hangup.
I called 911 at the Montgomery BART station when visiting SF last week, because someone was having a medical emergency. I got dead air (despite strong signal) for about 2 minutes before I spotted an elevator call box. That helped me get the station attendant; once she was on her way, I hung up on 911 so I could attend to the person in distress.
10 minutes later, I got a text:
we received a 911 hangup from your phone. if you need help, call back, tell us where you are and what happened. if that was a misdial, have a good night (capitalization from original, so probably not automated?)
I think this is a good thing, for example in a situation where someone needs help but is uncomfortable voicing their emergency aloud. But it was weird to get dead air and no immediate call back.
In any case, I found it an interesting experience.
688 comments
[ 3.1 ms ] story [ 367 ms ] thread> 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.
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.
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.
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.
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.
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.
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.
except that any app could do this, and it just happens to be Teams that did.
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.
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.
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.
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.
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".
Yes, actually.
> Shells ? No.
Also, yes.
> 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.
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...
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.
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.
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.
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.
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.
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.
https://www.reddit.com/r/GooglePixel/comments/r4xz1f/pixel_p...
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.
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.
How did this ever become acceptable?
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.
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?"
"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.
Let’s not forget - someone very nearly could have died thanks to this glitch. Thankfully, a landline was available.
No customization done by the user, including installation of apps should prevent a user from being able to call 911, period.
Imagine the worse case scenario where malware infects the phone but requires a credit card to call 911.
Maybe congress will get around to this to make Google and everyone else do the right thing, but from my perspective Google should have done the right thing here.
It will take some horribly idiotic event like that to get the manufacturers to actually address that when you sell a phone you're selling hardware and software.
It's hard to see how that wouldn't cause some ugly delays, so yes people will be harmed.
It's not just some bad-app on the play store (though that is one approach I believe google could use).
It's the fact that the android OS is EOL after 3 years, and the user is still using it as his main phone -- and needs 911 services.
I think Google would argue that malware interfering with your phone after its EOL date is a reason why you should upgrade your phone to a newer model rather than use that as a reason to extend the life of their phone software indefinitely.
Without full cooperation from manufacturers, there's really not a lot that can be done outside of blacklisting all dialer apps on the Play store and even that would do little for anything already installed.
The pixel 2 is already EOL'd 4 years after it's release, but it can still make 911 calls. I believe there are people that still depend upon that phone to make phone calls -- and therefore need 911 when they need it.
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call...
If a phone can't access 911, it's not legal. Frankly, it's an indictment of the system architects that this bug is possible at all.
Seriously, this sounds like a Teams issues. Google does by default incorporate what is required and it isn't until Teams takes permission from the phone app that an issue even occurs.
I own the phone and I am able to install whatever software and whatever operating system I like. I don't want it to seem like I'm defending Google here, but should manufacturers really be responsible for the software someone installs on their portable computer?
Installing your own OS that intentionally doesn't support 911 handling would be in the "not possible" category just like a user who cut their antenna. For anything less than that, Google (and other manufacturers) are absolutely responsible for ensuring the 911 code path can't be disrupted. People have literally died from this.
And this is an app issue anyway (Microsoft teams).
And if they can't, they should make it clear to the user/owner that their phone isn't supported and that means that their lives or the lives of others could be in jeopardy as a result. In fact, perhaps their phones should have an expiration date and should just stop working after sometime. Or at least disable critical functionality that their required to be in compliance with (FCC regulations) since they've decided to no longer support the device. Moreover, this date and timeline should be clear from the point in time when you purchase the device.
Of course this could all be done by the network providers only allowing supported devices on their network, but we all know how that would end up.
This isn't just some bug, and if google wants to participate and be taken seriously in this industry, they should stand by their products and customers.
1. This is _mainly_ an app issue (Teams). It will be fixed via the store.
2. It affects very few people (installed teams but not logged in).
3. There is already a workaround (just reinstall the app)
4. Google has in past patched even older devices in case of a serious problem or vulnerability.
Google/Android are clearly tasked with handling 911/emergency calls. Teams is not - I doubt that it is even in their spec - they should expect 911 to route right past them.
Google effed up this one big time.
They need to fix it for every app, not just Teams.
It doesn't matter what Teams does. Android is required to ignore Teams in the case of an emergency call. That's the law.
My understanding is that emergency calls for any global locale are supposed to be an entirely separate band of communication from regular phone calls — e.g., they must work even without a SIM card, an account, etc.
So, emergency calls should be ENTIRELY OUT OF SCOPE FOR ANY APP software. Period.
It should be a low-level override/bypass, and NO app software software should ever be allowed to even touch emergency calls, let alone required to handle them.
Expecting all apps to handle life-critical emergency calls correctly is a profoundly stupid idea, guaranteed to produce a multiplicity of failures (and if that expectation did exist, Google must damn well announce it as a deadly serious requirement in bold, uppercase, red flashing letters to anyone wanting to use phone_call_handling permissions, but they don't, afaik).
So, we don't need to know anything about Teams or other app software in this case, only about the emergency calls side/back channel, and that any app, including Teams, will ZERO responsibility for handling emergency calls, or even ability to touch them.
So, it is Google that effed up big time here (regardless of Teams' other issues). Unless you make a solid case for the profoundly stupid idea that all phone-related app software should be responsible for handling life-critical emergency calls, your statement is plainly wrong.
Sure, Android should absolutely not allow any apps to interfere with 911 calls, and so however Teams achieves this, should not be possible. But some blame certainly goes to Teams here as well for causing the situation by trying.
"If a Teams client is not located at a tenant-defined dynamic emergency location, emergency calls from that client are screened by a national call center to determine the location of the caller before transferring the call to the PSAP serving that geographic location."
Which is a clear violation of Kari's Law. A business phone system in the US is absolutely not allowed to intercept and divert 911 calls.
1. What about someone who has a tablet (with no cellular functionality) but has a VoIP app installed?
Clearly, the only way to call 911 on such a device would be for it to go through the VoIP app, so it seems like Android at the very least still needs VoIP apps to be able to handle 911 calls under certain circumstances, such as when there is no cellular functionality.
2. How about a situation where a cellular phone has no communication with any cell towers (for any network) but has a VoIP app installed and access to wifi?
Unlikely, to be sure, but possible. In this case, the only way for the phone to reach 911 would, again, be through the VoIP app. If 911 access must get through no matter what, Android would have to let the call go through the app, despite that the phone has cellular functionality.
Those are likely just a couple of instances and there's almost certainly others I haven't thought of.
That said, the Google Play store should also have more stringent reviews for apps that want dialer access. Their review should verify whether emergency services can be called regardless of signed-in status, and location
It's not "the" link. They are both valid links to the same thing.
> It works for users of the site mobile or not, app or browser is a choice.
No, it doesn't work properly.
> you can change the url
It's nice, when linking people to an article, to not give them extra work to see it.
> or actually sign in
Shouldn't have to, obviously!
> instead of being a lurking non-participant
Nothing is wrong with lurking.
> otherwise you're opinion doesn't really matter now does it
1. That's dumb, yes it does.
2. This is a different site from reddit. Even if we accept your participation premise, the link is on HN, so it's HN opinions that matter. Reddit accounts are totally irrelevant; only HN accounts matter here.
> don't force ppl to the old.reddit link.
What happened to "you can change the url"? (Not that I agree with that idea in general, but I think it's much more valid for a dislike of aesthetics and much less valid for making a site function properly.)
"Based on our investigation [...] We determined that the issue was being caused by unintended interaction between the Microsoft Teams app and the underlying Android operating system. [...] If you have the Microsoft Teams app downloaded, but are not signed in, uninstall and reinstall the app. While this will address the problem in the interim, a Microsoft Teams app update is still required to fully resolve the issue. [...]"
Now I'm really curious as to what that "unintended interaction" was.
Also, everything is awful.
Not so much awful as "Star Trek."
Star Trek was always upheld as a model of the future. But instead of transporters and replicators and space travel, we got all the bad stuff from Star Trek.
Everything breaks all the time. Technology doesn't do what we expect it to do. The latest, greatest inventions are held together with gum and bailing wire. Computers let us down when we need them the most.
We are living Star Trek.
Big difference. One is a purpose built machine, the other is an app on your multi-purpose computer.
And is pleased when it isn’t.
If you're telling me there are ships running in the defence force that can't actually communicate with other people at the drop of a hat, at all times, then how is that even possible? That requires some serious negligence.
In a lot of instances, if the system fails, the plane falls out of the sky, so I am pretty sure we're doing that well.
Indeed it does, but unfortunately ships have to be designed to constraints other than, "Works perfectly all the time, even in combat." For example, one of the reasons that the British lost HMS Sheffield during the Falklands War is because, due to issues with her antenna layout, she was unable to use her radar and satellite communications at the same time. When the Argentine planes launched an Exocet at her, she was in the middle of using the satellite antenna, and thus missed the incoming missile. Why was the antenna layout so boneheaded? Budget cuts during the shipbuilding program, which forced a reduction in size and consolidation of antennas.
In a lot of instances, if the system fails, the plane falls out of the sky, so I am pretty sure we're doing that well.
The numerous issues we've had with communication and sensor fusion on the F-35 indicate that we aren't. Now, the military absolutely assures us that those issues have been resolved and the F-35 is great now, but I think I can be forgiven for not taking their word 100% at face value.
Microsoft made a special point of getting people used to the idea that nothing can be expected to work right. Before Microsoft, if something didn't work, you sent it back for a refund, angrily. Since, it is "Have you tried rebooting it?" No refunds, ever.
Everybody else relaxed into a Microsoft level of expectation. Anybody who doesn't, spends money their competitors don't.
(If you are too young to remember: this is literally true.)
(I've been a professional programmer since the mid 1980's, so I do remember. )
Have you used Office? Whatever those apps are now, online, in Teams, stand-alone, it’s a steaming mess. Various functions work in various places and things like moving an image are just ridiculously broken.
It isn’t this bad with other vendors.
My point is that Microsoft isn’t unusual in this regard at all, except that their software has become very popular. In other words, people experience Microsoft bugs very often, not because Microsoft software is unusually bad, but because Microsoft’s software is unusually prevalent in the world.
Windows, instead, absolutely routinely crashed every day, or even several times a day. A few people managed to keep it up for days between crashes. It would crash even when you weren't using it.
I had an Apple A/UX system that stayed up for months at a stretch. That was simply normal for Unix, and later Linux. Even in the mid '90s it was expected that a Linux system would be rebooted only after you deliberately shut it down to upgrade to a new release or install new gadgets. (This was before there was USB.)
Microsoft ended up redefining crashing to mean, not just needing to reboot, but failing to reboot so you would need to re-install the OS, because something got corrupted on disk. It was totally normal and expected to need to reinstall Windows every few weeks or, sometimes, months, and everyone got used to that.
Microsoft worked fine for the actual customers, the system integrators, because all it needed to do was install and register. Once the system was delivered to their customer, software failures were Somebody Else's Problem, and did not affect the actual customer.
Economically speaking, software failure costs were exported to the hapless users, who were not sophisticated enough to blame anybody, and not in a position to demand satisfaction from anybody.
In fact, Google has themselves made several available over the years; Hangouts and Google Voice are two examples.
What is missing is a way to say “emergency call failed” and pass it to another handler (perhaps even a low-level one built into the cellular part of the phone itself).
It could be that there is some kind of design bug (no way for a dialer to indicate that emergency numbers cannot be dialed) but it could also be an actual Teams bug (Teams indicates that it can dial 911, sets up a connection that dies in the background).
Because it specifically happens with Teams installed but not signed in, my guess is that the latter is the problem: Teams tells the OS "yeah sure let me dial that for you" but then doesn't complete the call because it wants you to log in to MS first. Reinstalling the app, as suggested, would kill all associations with the standard dialer, but an update from MS is necessary to fix the main bug. I have a feeling the promised update for 2022-01-04 will remove the ability for these dialers to call emergency numbers all together.
In my opinion there should at least be a setting (enabled by default) to send emergency calls through the system dialer, if it's not enforced automatically already.
Not sure if Teams does that, if not I guess it would be possible, although I'm not sure if there aren't cases where suddenly a different (=an OS component) app than the user expects taking over also would be bad, e.g. if someone used a special dialer for accessibility purposes. Maybe this should be behind special review and testing, at least this specific bug here seems like it'd have been easy to catch if emergency calling behavior was tested.
It shouldn't really register itself as a phone app IMO. And on my oneplus it doesn't appear to have even tried.
No matter how much things change, the solutions remain the same.
Lol, Google claims no responsibility?
But MS has f*ckd up their testing, they should have definitely caught this before it was shipped and they should have been the ones to alert Google, not some random end user.
If Teams were any other app and simply playing nice this would have never happened. I'll bet you when the fix is released Google is going to drop one or more API calls that Teams hooked into.
Of course it should have never been possible for an App to do this to something that even the dumbest of dumb phones is required to be able to do. But Teams is a special kind of evil and it wants access well over and beyond what it needs to function.
I think _both_ are culpable. Microsoft teams shouldn't crash when making a 911 call. Google shouldn't hand 911 calls off to microsoft teams (though I'm not 100% clear on what the interaction should be if you have a custom phone app... maybe it should be able to handle the 911 calls? what if you install a custom phone app because the default one is broken... you'd definitely want your non-broken preference to be respected for important calls like 911).
Either way, I still think they're both culpable.
Thankfully, the law is completely unambiguous and tells us exactly how it should be handled:
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
Android is required to handle emergency calls differently.
Have you tried to call 911 recently? I have. Both times, I had to wait on hold over five minutes for someone to answer. "Press 1 if you need police. Press 2 for fire. Press 3 for a medical emergency. Press 4 if this is a non-emergency and you will be transferred to 311." After that there's not even hold music to let you know you haven't been disconnected.
There are almost 300 million cell phones in America. Who's going to answer those test calls? The operators who are already too busy to answer emergency calls?
Still not a good idea, since you don't want a bunch of phones DDoSing 911.
> Still not a good idea, since you don't want a bunch of phones DDoSing 911.
Eh, it doesn't sound too bad as something to roll out eventually. About 240 million 911 calls per year vs. 280 million cellphones in the US, and a dry run test would be expected to use a fraction of the resources (short call, etc). So, to test once per year I'd think you'd need to make the call handling infrastructure a small percent wider, and that extra capacity is something you could even benefit from (because phones could avoid testing at peak times).
The big problem is that this tests the actual call handling (and perhaps address reporting, etc)-- but doesn't do much to test the actual UI, audio path, etc, under the circumstance of an emergency call.
Not sure I entirely agree. I would want an emergency system to be resilient to DDoS, and frequently tested for that.
The number has been taken out of service but something like this could be put back.
In Italy (still in the transition phase) we have historically:
113 Police
112 Carabinieri (transitioning to unique emergency numbers)
The police won't be happy about your tests on 113, a few other countries have 113 for police:
https://en.wikipedia.org/wiki/112_(emergency_telephone_numbe...
(I agree that having them handle tests might overwhelm the system. Still, it would be comforting to have the ability to test.)
(The incident I called in was... I was looking at my window and saw this bus unloading. The passengers formed a big group and started pushing each other into traffic. After seeing a couple of cars swerve and narrowly avoid the innocent victim, I thought it was time for governmental intervention. The police arrived, ushered everyone onto the sidewalk, and that was that.)
I think it's a symptom of a system that's designed as a stack of abstraction layers, with developers who don't communicate. The developers of project A think a bug is a minor issue, not knowing that project B relies on it for something critical.
It's hard to write an app for a platform like this, too. Instead of one cohesive target, you have discontinuous abstraction layers.
Looks like Microsoft Teams was part of the problem here. I assume they had to hook into some semi-documented functionality that Google wasn't aware of or thought no one would use. On iOS, where Apple keeps tight control over their API surface, this is less likely to happen.
So a developper can create contacts/caller app so that for example, when you click on a call button from say a google search, the OS asks the user to pick one app that was declared to be able to ACTION_CALL.
If I had to guess, I'd say it's something having to do with Teams being given priority on calls followed by failure to having priority for emergency calls and no way to gracefully recover.
Quickly browsing the documentation I see comments like
Note: there will be restrictions on which applications can initiate a call; most applications should use the ACTION_DIAL.
Note: this Intent cannot be used to call emergency numbers. Applications can dial emergency numbers using ACTION_DIAL, however.[1]
[0] https://developer.android.com/guide/components/intents-commo...
[1] https://developer.android.com/reference/android/content/Inte...
I snorted when I read this. Trust me, iOS has plenty of broken and poorly-documented APIs.
Don't care about what's inside the product you buy?Why should other people care about what happens to you in the aftermath?Especially when repeatedly these companies have been abusive?
This is first about self-respect more than anything, even though it may not sound like it at first glance. You don't need their product as much as those companies need you, contrary to the popular "they're billionaires, they don't care" belief.People who think in these terms don't realize every purchase is a vote, and the more aware you are with your wallet, the more power you have, even if you are less wealthy than these corporations.This is why ignorance about subjects like privacy, security, usability, censorship matter more than not.Because inaction will eventually turn into action against you.
I don't think it affects finding that device from other devices.
Sure there should be a way for the call handler to reject some dials and have it go to the next in chain, but honestly this seems like a mess to me overall.
Alternatively, you could have a completely open platform, and then the onus is on Microsoft Teams and the user--but neither Android nor iPhone are like that; both choose to sandbox apps by default. When I install an app on a Pixel that isn't rooted, I expect that Android will keep it from intercepting 911.
Your phone can be locked, your SIM can be invalid, but you will still be able to place an emergency call because an emergency is a crisis, by definition. I believe that there is actual regulation governing this - a phone must be able to try and place an emergency call.
The expectation is that the phone will absolutely "hijack" an emergency number to ensure that it takes place. It's a critical path that _should_ ignore everything else going on with the device.
If, instead, you allow any call-handler to take control of whether or not an emergency phone call takes place, you open the door for malware to prevent emergency calls. You open the door for subversive apps, like those used by abusive spouses, to fake emergency calls, and report the victim to their abuser. You allow a malfunctioning app to prevent someone from getting help before going through a debugging process, which isn't reasonable if you've fallen and broken a leg.
You insert the platform, in this case Google, into situations where they may become liable for allowing someone to be in danger. Possibly even actively assisting. That's a legal bombshell that should terrify the platform.
It shouldn’t happen though on an architectural level at least.
Also, don’t forget that Teams as a VOIP app also has a legal responsibility of handling 911. But of course in this case the OS call should win and the other branch should not even be taken.
And yes calling 911 is “the basics”
What if a user installs a third party phone app, with the intention of never using the standard one? That app would have to be able to send 911 calls.
A bug in how the hand off works - yes that's a serious issue. But certainly that's something that we should still hold Teams accountable for testing before they released their app, too.
edit: typing too fast on a phone...
It should not happen as per the documentation, so it may be a bug on an OS implementation level, but not on an architectural one.
It really isn't; the fact that these things are called "phones" is a quirk of history and English etymology, not a reflection of how they're actually used. IMO the fact that we treat voice calls as some sort of special case priority that needs to be implemented in the base system increases the rate of these bugs (personal moan: why can't I use translate on emergency notifications? You'd think that that would be the most important thing to be able to translate...).
The phone's callstack takes a lot of special actions when calling 911, including locking onto any tower even if it is not in the preferred roaming list. As with many exceptional conditions, these code paths are often not as well tested.
If you need to do automated tests, there is a test flag in the android dialer API which will make the call but mark it with some test flag so you get a recorded message not a human answering.
That is not an assumption I would want to make. There are plenty of accounts out there of sporadic staffing problems at emergency call centers.
It appears the right way to do this is to get an appointment. More details here:
https://www.911.gov/frequently_asked_questions.html
In the UK you need to email BT (who operate the emergency system) and arrange a window to place a series of test calls to both 999 and 112. They will give you a time, a date and a script to exactly follow. If you pre-schedule with them it's supported.
Their email is 999testcalls@bt.com
Not sure if US have a system like it.
Google already special-cases it in the dialler.
this is a huge, huge problem and has nothing to do with Teams.
Completely unacceptable on Google's part.
That makes me wonder if Teams on iOS can make 911 calls...
edit: so apparently some people can schedule test calls: https://news.ycombinator.com/item?id=29494197
I'm in BC, Canada. The people handling 911 in my province is E-Comm, and they don't seem to have a policy on this. I've sent them an e-mail asking if they accept test calls.
I cannot stress how insane it is that these megacorps suck up some the best talent on earth and then saddles them with a corporate culture that throttles their abilities to the point that they might as well be actual retards.
I called 911 at the Montgomery BART station when visiting SF last week, because someone was having a medical emergency. I got dead air (despite strong signal) for about 2 minutes before I spotted an elevator call box. That helped me get the station attendant; once she was on her way, I hung up on 911 so I could attend to the person in distress.
10 minutes later, I got a text:
we received a 911 hangup from your phone. if you need help, call back, tell us where you are and what happened. if that was a misdial, have a good night (capitalization from original, so probably not automated?)
I think this is a good thing, for example in a situation where someone needs help but is uncomfortable voicing their emergency aloud. But it was weird to get dead air and no immediate call back.
In any case, I found it an interesting experience.
> u/KitchenPicture5849 should be awarded a sum in line with what a bug bounty hunter would be awarded for discovering a bug of comparable severity.