Hacker News new | ask | show | jobs
by judge2020 1661 days ago
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.
1 comments

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.

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

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.

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

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.