Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They need to release more technical details on this to restore confidence. How can a sandboxed user installed app with limited permissions cause dialing 911 to fail? How do they know other apps won't cause the same issue?

And they mentioned an Android update, but what about the millions of Android phones that aren't getting regular updates? Does that mean there's potentially millions of phones that can't dial 911?

I like Pixel and Android, but am seriously thinking of switching to iphone because I really need a phone I can trust will dial 911 when I need it.



What's really terrible here is that Google are saying they won't fix this until their regularly scheduled January release. SERIOUSLY..... They won't rush a fix out for this? Not even for this??? Unbelievable.


Note that Google is no longer providing updates (/maybe/ one more in 22Q1) for the OP's Pixel 3, a 3yo device which is otherwise still a great phone. It's simply not good enough. Google needs to support their own phone past three years and be the example to others that ship Android devices. How long are we going to ignore it and let those who can't afford a new phone every couple of years be left exposed?


Looks like it's only impacting phones from 2019 onwards and in very specific circumstances (still not great at all but a very specific bug):

If you are unsure what Android version you are on, confirm you are running Android 10 or above by following the steps here. If you are not running Android 10 or above, you are not impacted by this issue.

You are also not impacted if you have teams installed and are signed in:

If you have the Microsoft Teams app downloaded, check to see if you are signed in. If you have been signed in, you are not impacted by this issue, and we suggest you remain signed in until you’ve received the Microsoft Teams app update.

If you have the Microsoft Teams app downloaded, but are not signed in, uninstall and reinstall the app. While this will address the problem in the interim, a Microsoft Teams app update is still required to fully resolve the issue.

We advise users to keep an eye out for an update to the Microsoft Teams app, and ensure it is applied as soon as available. We will update this post once the new version of Microsoft Teams is available to 100% of users.

https://www.reddit.com/r/GooglePixel/comments/r4xz1f/pixel_p...


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


This isn't the first time I've heard this complaint.


Maybe I'm missing something, but it doesn't sound like it's _that_ specific. From the instructions, the conditions for the bug are:

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.


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.


> Blaming this on shitty code by a third party is not acceptable.

Sure, but I wasn't doing that.


Not you, Google, in their reply on the linked reddit thread.


Imagine if Ma Bell said they're no longer supporting your touch-tone phone because it's more than 3 years old, so 911 calls aren't guaranteed.

How did this ever become acceptable?


> Google needs to support their own phone past three years

It's not really Google's choice. Qualcomm gives up on their SOCs pretty quickly and unlike on Linux Android's license doesn't force them to publish driver sources.


You don't think Google could demand driver sources for the harware they use or use hardware with driver sources available? It is their choice.


Sure they could but they wouldn't get them. Not for release and without that they are useless.


And how many more years did they give people on the Google SOC?


Isn't the workaround to uninstall Teams?


I suspect millions of Android/Teams users will never hear of this bug. They won't realize there's action they could take.


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.


> teams doesn't have any special permissions

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.


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


Then Google should ban the app from play store and auto-delete it from phones until MS fixes it.


Because of a bug in Android? Great suggestion.


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.


No, to uninstall and reinstall.


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.


But Android has a list of emergency numbers you can dial without unlocking the phone, why wouldn't they use that?


Shipping the org chart. One team writes the Lock Screen dialer, some other people wrote the message bus thing that allows apps to intercept calls.


Why on earth would you want apps to be able to intercept calls on a phone?


On Android, you can replace the default phone app. That's by design.


Ah, so MS Teams is a phone app and Android couldn't decide which of the installed phone apps has precedence. Are there similar issues around WhatsApp, Signal,...?


Android use the default "Calling app" when the user wants to make a call. MS Teams is one such "Calling app": the first time you install any other than the default shipped with your phone, you (the user) are presented a choice to choose which one you want to use. After that, Android remembers your choice.

This means in this case, MS Teams was configured as the default "Calling app" and the issue could have been prevented at 2 level:

- at the Android level, if the user dials an emergency number, don't use the default "Calling app" and use a special "safe" calling app to ensure the call succeed even if a user-installed app is misbehaving.

- at the MS Teams level, allow emergency calls to succeed even if the user isn't logged in (or any other reason that could prevent an emergency call to be made, really).

As for WhatsApp, at least on my device, it's not a "Calling app", and as such cannot override the default calling app. I don't have Signal installed to check.


How exactly do you check your "calling apps"? I'm on Android 12 and have a list of "Phone apps". However, the only other app listed there (besides "Phone") is a VOIP app I specifically installed to make alternative phone calls with. Signal, WhatsApp, Telegram and not listed, even though I've used all of them to call other users on the respective apps.


First: I used "Calling apps" because that's how it's displayed on my Android 8 phone. The actual naming isn't consistent across Android versions, so yours is probably named "Phone apps". That's located in the settings, and again the exact way to access it varies according Android versions, manufacturer and whatnot (which is an endless source of pain to guide end-users by the way).

To appear there, apps have to declare they are phone apps and handle the proper calls (an "Intent" in Android jargon) when the system receive a request to make a phone call. WhatsApp, Signal and Telegram do not do that: you are only able to initiate a call when already inside the app.


I don't know about Android 12, but on Android 11 it's in Settings > Apps an notifications > Defaults Apps. This is where you choose which app you want as default for phone, browser, messages, etc


> at the Android level, if the user dials an emergency number, don't use the default "Calling app" and use a special "safe" calling app to ensure the call succeed even if a user-installed app is misbehaving.

That doesn't make sense, the user has to pick the app to dial with before they have an interface to enter the number.


Assuming that your hypothesis is correct: No. Signal doesn't have that permission and I think whatsapp doesn't either, and neither signal nor whatsapp can be signed out in the first place.


I wouldn't go so far as calling my post a hypothesis, it was like a guess. Another guess, wouldn't the fact that neither WhatsApp nor Signal are causing the same issues hint at MS Teams being the culprint?


Teams does the wrong thing, there's no question about that. But it's not clear to me that the Android core is unable to check that the phone app does the job, and has to trust it blindly.


> Why on earth would you want apps to be able to intercept calls on a phone?

Because there are housands of users even on HN that WANT apps like Signal to be able to manage secure encrypted calls like a first-party app with the same rights. Basic software freedom and all that.


Yes, but, in addition to not instead of... right?

I want Signal, Slack, Teams, my apartment buildings intercom system, etc, to be able to present their own native incoming calls through the same dialogs that regular calls come through. But not at the cost of potentially not being able to call emergency services...


> I want Signal, Slack, Teams, my apartment buildings intercom system, etc, to be able to present their own native incoming calls through the same dialogs that regular calls come through. But not at the cost of potentially not being able to call emergency services...

Understand that calling emergency services on VoLTE is essentialy VoIP as well - noone here disagrees that this is a horrifying bug. But the issue with this bug is not the APIs that allows VoIP apps to integrate into call system (after all, those APIs also make Signal/WhatsApp/Skype/Teams calls work over systems like smartwatches, Android Auto and Bluetooth car integrations) but the fact that Android somehow missed the fact that a buggy app can stop a call.


Agree completely.


Incoming calls or manually dialling a number directly through the respective app is a different matter, but when you click a stored number in your contacts list, or a phone link in your browser or another app, or anything like that, that app just hands the number to the OS and basically says "please call this number for me".

If you want to allow alternative VOIP apps and things like that to exist, at that point the OS must allow routing that number to any app that claims it can handle (outgoing) phone calls.


Yeah sure, and for most things it's fine if things break, irritating and bad press, but fine. Things like calling emergency services can never be allowed to break. It must have fallbacks, if it even needs to be allowed to be overridden in the first place.


According to this old bit of documentation (https://android-developers.googleblog.com/2013/05/handling-p...), the usual way of intercepting call requests should already handle emergency calls ("Note that the system broadcasts NEW_OUTGOING_CALL only for numbers that are not associated with core dialing capabilities such as emergency numbers."), so it'd be interesting to know what went wrong in this case (and why only on Android 10 and newer), but until then it's hard to say more and it's all just speculation…


There are many reasons why an app would want to be notified of a call taking place - e.g., a music app could use this event to auto-pause playback, Teams might set the availability status to "busy", etc.

The question is what should happen if such an app takes an excessively long time handling the event. In this case, the OS should not wait for the app and should directly go on making the call. The bug seems to be that the OS did wait, so a misbehaving app can effectively block phone calls by e.g. going into an infinite loop.


  > Why on earth would you want apps to be able to intercept calls on a phone?
My daughter enlightened me to this recently.

Android devices are not phones. They are computers that come preinstalled with some apps, one of which is a phone app. Importantly: They are not marketed as PHONES. They are marked as "Smartphones". Just search for the word "phone" on the websites of any major Android device manufacturers.

The distinction is important.

Be careful when punishing children from "using the phone". Today, this means that they cannot use the app called "phone". This incident is a stark reminder that "phone" is an app today, not a physical device.


You are right that many younger people (and not only younger people) primarly think of those little black rectangles as computers with several apps. As you say, in their minds, making voice calls in the classical way just happens to be one of those apps rather than the device's primary function.

But you are dead wrong about the word "phone". It still means those little black rectangles. If you primarily think of those little black rectangles as computers (or social media machines) then the word "phone" has shifted meaning to match that. If you punish a child by banning them from "using the phone" you will absolutely get the horrified reaction you'd expect.

Of course words vary in meaning throughout the world and maybe "phone" really does mean the classical phone app in your area, or in your daughter's social group. But that's exceptional, regardless of age.


I'm basing the definition on the usage of words by the companies which manufacture and market the devices. See the usage of the words "phone" and "smartphone" on the LG, Samsung, and Xiaomi websites.

Apparently, the "phone" in "smartphone" is about as relevant as is the "fun" in "funeral".


The evolution of the meaning is even more obvious in at least one other language: Japanese borrows the English word "smartphone" for those, but uses "denwa" (with its own kanji) for non-smartphones.


Sure, I agree with that. (But also, what marketer would miss an easy opportunity to include "smart" in their product's description.) I was just talking about your last paragraph.


I think you are right! Also thanks for reminding me that I'm pushing forty!


Android devices are more like appliances than computers. C compilers ? No. Shells ? No. There are some BASIC interpreters thoght, which is a start.


> Android devices are more like appliances than computers. C compilers ? No.

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.


Termux lets you run a sandboxed Linux system (can even include a desktop environment, rendered via VNC). You can run C compilers and whatever else.


Sure, I'll accept that. But the point isn't that the devices _are_ something specific, rather, the point was that the device _isn't_ considered a phone by the manufacturers. "Phone" is one function of the device, but no even its major selling point.


There is a fallback call flow for emergency calls in cases where the phone cannot register properly but it would be nice to be able to overlook missing bureaucratic elements and just save lives, and that’s what “Emergency Calls Only” signifies, but it probably only activates when normal flow fails.


> How can a sandboxed user installed app with limited permissions cause dialing 911 to fail?

No idea about this particular problem, but my takeaway was that Android apps are more similar to web extensions with service workers than to traditional executables.

An app can register itself for all kinds of OS hooks during install. When a hook is triggered, the OS will send an event to the appropriate process of that app. If no process is running, the OS will launch one.

This means there is not a lot of meaningful distinction between "running" and "not running" on Android: As long as the app is installed, the OS may run code from that app at any time.

(This is why you can have half a dozen messenger apps running "in the background" without draining your battery: There is no actual background process for each messenger, just entries in a database somewhere. When a new message comes in, the OS receives a push notification, displays a message to the user styled according to the app's configuration - and might eventually launch a process for the app if the user interacts with the message.)

So it's quite possible that the Teams app registers itself for some kind of "outgoing phone call" hook, and there was a bug in Teams' handling of that.


So, this implies that a serious bug in any program with the 'call' hook could prevent your phone from making a call, even 911? Seems like a big deal!

In software I write, the logic for 'emergency' priority events doesn't go through the same call chain for this reason.


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.

Seems that somewhere in there, someone messed up.


The issue is that you might have a device where emergency calls have to be routed through a VoIP app, per legal requirements, e.g. if no cellular emergency calling is available (e.g. on voip-enabled wifi-only devices, or on voip-enabled devices in locations without cellular signal))


> And they mentioned an Android update, but what about the millions of Android phones that aren't getting regular updates?

That's my concern as well. My phone stopped getting updates from the manufacturer after getting Android 10, which is affected by this bug according to the linked comment. How are they going to get this update out to phones that the manufacturers has abandoned after the usual two years of updates?


I have always had Pixels which get monthly updates, but this is a crucial point. Even if Google says "hey guys, we fixed it in AOSP, aren't you proud of us?" No Google, we're not. This AOSP fix won't come to millions and millions of users.


From what I understood, there will be two updates, one to Android and one to Teams. Either of these updates will be enough to fix this issue. So even if Android is no longer being updated for your phone, updating Teams will be enough to fix it.


I mean if it will never be updated again how could you fix any issue ever? Like yeah this one is particularly severe but any resolution will be an update of some kind to the software.


On the plus side, can a two year old phone even run the bloatware that is Teams?


Easily. My mid-range phone (OnePlus 5) is 4.5 years old, phones are powerful and have been for a long time.


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)


Fwiw my galaxy note 8 runs it perfectly. I think my iPhone xr is also more than 2 years and no issues.

I'm not saying I love the tool, but phone performance itself is not the reason for me. YMMV.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: