Pixel prevented me from calling 911
old.reddit.com
old.reddit.com
The FCC regulates 911 service. Here's the form for filing a complaint about 911 service:
https://consumercomplaints.fcc.gov/hc/en-us/requests/new?tic...
States also regulate 911 service. Try your state's office of emergency services.
There's something called "Kari's Law" that may apply here. This was passed in 2018 after someone was being attacked in a hotel room and their 9 year old daughter tried to call 911. She couldn't get through because the phone system required dialing 9 for an outside line. So, now, all business phone systems are required to recognize and pass through 911 to the main phone network. There are criminal penalties. (Microsoft might argue that "Teams" is not a "multi-line telephone system". That probably wouldn't go far with a jury. The clear intent of the law is that if you interpose something between a phone handset and the 911 network, it has to pass through 911 calls.)
The whole 911 area is heavily regulated, since it requires that so many things interoperate reliably.
Google may blame Microsoft but there is no way an app should be able to disable 911 calling on a phone. This means that other apps could disable 911 intentionally. This is Google's problem to fix. A phone OS needs to guarantee certain things and 911 is one of them.
The perils of treating phone as "just another app", lack of testing, etc.
0118 999 881 999 119 7253
I thought it had been changed for ages.
I am not the least surprised that it trigger crashes.
Its strange how many companies believe their own lies about anything requiring an explicit account being a good idea...
I do not currently use a Microsoft account for anything. I have one, and once in a while, I log in with it for some reason or other.
Everything else is a Office 365 account tied to an email provided by the people funding that access.
For me personally, using OSS gets the job done for all my computing needs otherwise.
https://web.archive.org/web/20211209094433/https://www.reddi...
https://archive.vn/20211209094437/https://www.reddit.com/r/G...
> We will also be providing an Android platform update to the Android ecosystem on January 4.
They postpone the fix to the next regular patch release, while fully knowing that other apps could trigger the same bug, including malware. This is criminal negligence.
Google also has the power to immediately disable Microsoft Teams on most Android devices, until the fix is rolled out. They are taking down apps for dubious reasons all the time. But when a popular app triggers a life-threatening bug, then let's wait for them to issue an update, here are some tricks to avoid the bug, don't forget to tell grandma.
> Out of an abundance of caution, in the meantime, we suggest
Does that suggest urgency to you?
> Because this issue impacts emergency calling, both Google and Microsoft are heavily prioritizing the issue, and we expect a Microsoft Teams app update to be rolled out soon – as always we suggest users keep an eye out for app updates to ensure they are running the latest version. We will also be providing an Android platform update to the Android ecosystem on January 4.
I believe heavy prioritization shouldn't involve planning to wait an entire month to issue an Android update.
Personally, I frown on Google/Apple/whoever mass disabling apps for all users without warning, but if there is ever a case for a mass disabling, this is absolutely it IMO.
"If 911 is dialed on anything that is a phone, your system must connect to 911."
https://www.fcc.gov/mlts-911-requirements
This is less of a "oh it's just a bug" and more of a federal compliance issue.
https://www.google.com/search?q=dial+phone
Serious, the cryptic statement could mean your message above should have called 911 instead of letting you enter the digits 9, 1, 1 into a message
https://www.google.com/search?q=dial+phone
Seriously, the cryptic statement could mean your message above should have called 911 instead of letting you enter the digits 9, 1, 1 into a message
this highlights that phones are now multi use. What's "making a phone call" is no longer clear. I "call my friends" via zoom/meet/fb messenger/line/slack/discord. I don't use phone numbers to call people. are all those varied services required to handle 911? I can "call people" via dating apps. Are the also required to handle this situation?
Federal regulations are not something you want to be afoul of. Think of Eye of Sauron, but with the ability to take your money, and not for a reason you respect.
Below is one of the comments on the original reddit thread that gives more context of how this could happen. u/rbrome on reddit thread[0]:
Teams is a wide-ranging service that includes VoIP phone service. I believe it is designed to replace your company's phone system if you want it to. So it makes sense that it registers with Android as a VoIP service.
There are situations where someone might want/need Teams to handle a 911 call. Perhaps you have an Android device with Teams that's designed to be a campus-only phone, without cellular service. Any device that presents as a phone and can make calls, is required by the FCC to be able to complete a 911 call.
[0]: https://www.reddit.com/r/GooglePixel/comments/r4xz1f/comment...
Unless it lacks a cellular radio entirely, I find it unlikely that voip would be a better option than cellular service on any college campus I'm aware of.
I feel I don't care about vanishingly rare use case of a wifi-only Android device on a campus network. If a device has a cell phone radio in it, it should be able to make a 911 call, and letting an app block that is inexcusable.
This seems heavy handed and unreasonable. Disrupting millions of people's lives to fix an unusual use-case (even if it might be life or death) is not proportionate.
Yes, and Google product managers can always choose to not act immediately, continue to allow the disruption of emergency calls on Android devices until the next app and scheduled OS update, and become felons.
Only in our dystopian software hellscape where we rely on software for absolutely everything, but get considered a rube for expecting anything to actually be reliable.
Yes, I especially balked at this part:
>>and we are currently only aware of one user report related to the occurrence of this bug.
That is a fact about Google's awareness of the bug, or their ability to be ignorant of it, not a fact about its actually frequency of occurrence.
I'm pretty sure this isn't the only time it's happened. It's the only time someone forced them to notice.
Google runs a battery of automated tests on any app before admitting it to the Play Store. A part of this testing should be simulated 911 calls. Failing to do so could open Google to liability through negligence.
For example, a voip android desk phone - it relies on voip to make calls. Android is agnostic about it and allows third party software to handle underlying calls, whether it is Qualcomm/Samsung/etc software for cell calls or Microsoft Teams for VOIP.
There isn't a straightforward approach here for Android. It's not like iOS where Apple owns the entire software stack, including modem software.
And when you say area codes [can't] start with a 1, is that only when you include a 0 prefix?
Country codes can start with 1. There doesn't seem to be a +11~, but is it forbidden? Are there no US or Canada (+1) numbers that start with even a single 1?
(There are special dialing codes like dialing 011 for international that are an exception to this, but no normal phone numbers.)
https://en.m.wikipedia.org/wiki/List_of_North_American_Numbe...
Of course you could make “91” be the code for outside lines, forcing someone to dial “91+1-XXX-XXX-XXXX”
Well, kinda... The thing is, even if not required by standard (It is, there's a Numbering Plan for the US and Can), most 9-to-dial-out systems would fail to call such a number, redirecting 911-anything to immediately dial out 911 once the second 1 is dialed.
IIRC, I've seen POTS also skip the inter-digit tone wait (the time between your last dial and the system going "okay, that's all the numbers, let's call!") when calling x11 numbers, generally considering "911" and other emergency/service numbers to be a magic triple that doesn't wait for other numbers to dial out.
There are no area codes starting with 1 in the US nor Canada to my knowledge since any dialing in a system with 9-to-call-out should end up being dialed as follows :
* 9 (leave system)
* 1 (country code)
* 1 (first digit of the area code)
And there is no step 4, because 911 is a special number like 411 and 311, that has a special dial plan. Since there is a possibility of issues if we make the treatment any less dumb, we don't do that. 999 is a special, unassigned code in the US too. 112 is likewise impossible to clash with here in NA since calling that with a corp system just means typing 9112, which ends up being 911, and dialing it on its own can also be allowed to be a special case since there are no area codes with 1 because of 911.
In fact, even "small area codes" or, officially, "office codes" are also required to not be X11. You used to be able to call locally in your area code without dialing the area code, too. It ends up being that xxx-911-xxxx is also an invalid number. Because locally, you would have had to type "911" to start dialing that number. There are also other limitations that can be seen here as well as allocation for future expansion : https://en.wikipedia.org/wiki/North_American_Numbering_Plan#... https://en.wikipedia.org/wiki/North_American_Numbering_Plan_...
There's also probably a physical, legacy reason it's probably much more difficult to make a physical 911 switch when "911" is also a valid part of a phone number. It means you need to figure out "Is it what they meant, or are there more numbers coming?" It means the sequence of operations "<open line><9><1><1>" always means emergency, fast connect, and probably easier to implement as a side-channel than as a part of the dial logic? This is speculation, I haven't actually opened a POTS PBX with a physical implementation of the 911 dialing logic.
No country code (or phone number) can be a prefix of another. There cannot be a +11 country code, since after the first 1 you are already within the NANP "country" (and it seems the NANP rules disallow area codes starting with 0 or 1, so the next digit can only be on the 2-9 range).
Way, way back in the day when dial-up was a thing, I worked at a company that had an automated system that called a large bank of test numbers to make sure they were still working. This system ran 24/7. It required you to put in the numbers as <areacode>-<number> without a prefixed 1. The code would add the 1 automatically. Because it operated in a lab inside of our phone system, it dialed 9 to dial out. Well, at some point someone had to reconfigure this system and I guess thought it would be good to add a 1 before each # in the configuration.
This resulted in thousands of 911 calls being made to our local call center. We had accidentally created a 911 war-dialer.
The moral of this story is don't dial 9 to get an external line. You're literally a keystroke away from calling 911 every single day.
I ran into a similar issue with software that was trying to dial 0 for an outside line, and then a number starting with 00.
Lots of very unhappy people.
The dial out in corporate, usually you used 9. Then you google how to dial in Europe because the numbers are not natural. Google mentions dial 11 + country code + phone number.
So people hit 9 to dial out, then 11 to dial in Europe. Instantly you hear: Emergency 911, is this an emergency?
The dialer is like: no I'm trying to call Europe.
9-011-49-(German number) [3]
For long-distance domestic, the national trunk prefix should be used instead. For the US, this is 1 (unrelated to the US country code, which is also 1):
9-1-(10-digit US number)
For local calls, you do not need the trunk prefix, so you would dial:
9-(7-digit US number)
However, no US (or North American) area code nor central office code starts with a 1 [4]. So even in the above two cases, the sequence "911" should never occur.
[1] https://en.wikipedia.org/wiki/List_of_international_call_pre...
[2] https://en.wikipedia.org/wiki/List_of_country_calling_codes#...
[3] https://dcloud-cms.cisco.com/help/outbound_dial_patterns
[4] https://en.wikipedia.org/wiki/North_American_Numbering_Plan#...
Seems like we put too much stuff on the 9, it's not like we're still using rotary phones
What would filing a complaint improve to this process?
Unless there is malicious intent, I do not really see the added benefit of a lawsuit or complaint to the regulator.
It’s not like this is some random Joe shop that missed a small feature. This is Google and Microsoft, two of the biggest tech companies out there, making billions while not even caring to follow society’s rules (move fast and break things right? All in the name of scaled super fast profit)
What’s the alternative? Just have 911 calls fail every once in a while since everybody is too busy with their feature work to look into it?
(googling says: https://developer.android.com/guide/topics/connectivity/tele... and hook up a test device )
PS: At least where I live, emergency services will show up at your house if you make a few 0-second 911 calls
You're supposed to do this when setting up new VOIP service too, to make sure location information is reported correctly. It's quite a normal thing and they're not at all surprised by it.
I would go so far as to say there are 2 types of phone people: Those who've placed a lot of 911 test calls, and those who're placing their users at risk.
I've no idea how exactly this bug happened and therefore whether the following has any relation to that issue or not, but if you want VOIP apps and similar things to work, you do need to allow the "I've got a phone number and I want to place a call" step to be intercepted, because otherwise how are you supposed to make a call via VOIP etc. when selecting a number from your contacts list, a phone link in a browser, etc. if that step was hardcoded to the regular phone app?
Android already differentiates between normal calls and emergency calls. Normal will be intercepted, emergency shouldn't be. And an emergency call is required to still work even if a SIM card is not present in your device.
Emergency is required to work a certain way, by law, and is documented to work that way, but didn't happen in the case of this bug. The OS is responsible for emergency calls, the dialler, which may be third party, for normal calls.
I assume you see this through the lens of "bugs happen, as long as developers make a sincere effort that's fine" under which most software development takes place. But this is absolutely the wrong way to look at this, and I bet you wouldn't apply this framework to physical engineering artifacts which are subject to legislation ensuring safety standards like bridges, cars or heaters.
If they've BUILT a system where apps can interfere with the ability to place calls, AND NOT written appropriate exceptions for 911 calls to bypass all such interference, AND NOT tested such exceptions, then there's a huge problem. That is absolutely the regulator's business.
I can't speak to the way modern phones are designed, but in earlier ones, 911 calls have all sorts of special status. They override pretty much all the phone's self-preservation mechanisms:
Transmitter deck too hot, normal calls can't be placed? 911 overrides that; the phone will melt itself if that's what it takes to get your call through.
Battery too low, normal call would be dropped so the phone can shut itself down without corrupting its flash filesystem? 911 overrides that, it will run until the circuitry physically ceases to function, in case that buys you a few more minutes of contact with the operator who might save your life.
Power control? Some phones would allow higher wattage when docked in a car-kit, but limit themselves to a lower power level when hand-held, to comply with tissue absorption regulations. Guess what limits go out the window when you call 911! Of course it's not gonna use the power unless it needs it, but if weak signal would cause a normal call to drop, 911 calls can tap into extra capability.
They will do ANYTHING to make that call go through.
And for software to fuck it up in the name of some obscure feature that clearly didn't get adequate testing, is unconscionable and spits in the face of literal decades of engineering effort.
Because it should never have gotten to this point. They are lucky that somebody has not already died.
> What would filing a complaint improve to this process?
It would encourage proper testing, and proper development practices that would prevent such a bug from occurring. Why was the system so poorly designed that Microsoft Teams could cause a hang during a 911 call in the first place?
It needs to be a carefully managed feature, but it's certainly not "zero need".
911/112/etc. calls should just not be screenable or blockable by apps or susceptible to third party app crashes. They should be short-circuited to just happen on the default phone app, with little possibility for any interference from apps on the system.
or where you can test it, but that testing is not sufficient to ensure the functionality works
then your design is not fit for purpose.
Usually there's a hidden config register where we can change "the number for 911", so for some portion of testing, we'll set that to "Chris's phone" and inundate a coworker with calls, but once we've been through a shakedown with that, it's time to coordinate with the local PSAP and identify a slow time when they can field some real test calls from us.
There are all sorts of safeguards here -- they want a regular phone number for one of the testers, so if the test phone malfunctions in any way (say, calls complete but audio doesn't open), they can reach us out-of-band. And it's always perfectly clear that they can cancel the activity at any time, if enough real 911 calls come in that they don't have spare operators for our testing.
It's been a long time since I was on the carrier side, but I remember doing tower turn-ups, we'd also place one test call per carrier-sector, to make sure the location info was transferred correctly. Similar coordination but it was largely a formality because it was usually just 3 or 6 calls, and very brief ones at that.
In the instant case, both the phone maker (Google) and the carrier (unsure) should've exercised this in their acceptance testing. Since it sounds like a Teams bug, it's understandable that they didn't catch it, but also unacceptable that Teams could interfere with the ability to dial 911. Since we've now learned that apps can interfere with that, this hugely balloons testing requirements until/unless they fix the OS so apps cannot interfere.
When I worked at Motorola doing mobile infrastructure, you couldn't even merge your code into a release candidate branch unless it was tested against emergency calls, for all the reasons you listed (plus more).
We used giant attenuators screwed on to the antenna plugs because everything had to be running at full power to ensure that it was as life-like as possible. Every once in a while, though, someone didn't screw the attenuator on tight enough and the emergency call would be picked up on the real mobile network and the fire department would show up in our parking lot.
There is most likely an issue but we don't really know what it is. how do you know it's not on the Verizon side?
Most likely half the 911 calls in the US are made from Android phones and we never heard of common issues.
i know it isn't a verizon problem, because google tried to blame teams.
I don't know your definition of playing it down.
he had contacted Google support, but unfortunately, he do not get response now.
Can't be sure about that. If someone died because they were unable to call 911, who is going to know afterwards?
This is such a stupid argument, so out of the billions of android phone, it should never never happen? If you don't want hardware / software to fail never use it then.
Next you use a landline phone, for some reason 911 does not work, oops. But I was told 911 should work 100% of the time.
Problem will always happen to some degree.
And this is an even dumber argument. Yes software can fail, but a critical piece of software like this should have as few failure modes as possible. This bug would have been preventable through proper design and testing. There is no good reason to allow any third party integrations to interfere or become involved with dialing an emergency number, and oh so many reasons to outright forbid it.
You wouldn't pass a bug in a pacemaker off as "oh, shit happens". So why would you take that stance on a bug may prevent people calling emergency services in a potential life or death situation? Are you even listening to yourself?
This is critical software and it needs to be tested. Tested properly. It's thinking like this that gives software engineering a poor reputation as a discipline and leads to incidents like the Therac-25.
Like Microsoft with Windows, Google releases their security fixes for Android monthly. And January 4 is obviously the date for the next one (it goes out at the beginning of each month, and AFAIK the December one has already gone out). So the fix (which might even be ready already) is going to be released on the first opportunity.
This is at the same time as we head into a) the holiday season in much of the world, b) winter in much of the world, c) an ongoing pandemic that is dealing with the spread of a new variant and the roll out of not only initial vaccines but also boosters.
Having emergency calls not go through because of a bug needs to be fixed immediately, not subject to some update cycle.
"Google Support reached out to me through here "
So multi million fine threats is how you get to a human at Google.
if fine cost * probability of fine being issued > cost to address then address else end.
Would you really give up one of your yachts this year just to save ten thousand lives?
The obvious fix is some kind of government/regulatory involvement that introduces additional fines/costs for bad behaviour, whether specific to endangering the public or more broad. And of course, sometimes this is upfront standards stuff like we have for emissions, lighting, seatbelts, etc, whereas other times it's prosecuted as a negligence charge after that fact.
"Android 14 is here! Android 13 had some bugs that led to an inadvertent use of deadly force. The error has been rectified and lethality should decrease in this version."
But Microsoft is certainly not going to try and argue that Teams doesn't have to be able to make emergency calls, at least not when it's used as a VOIP solution - they have plenty of documentation to help ensure emergency calls are routed properly: https://docs.microsoft.com/en-us/microsoftteams/what-are-eme...
Ironically, Microsoft wrote a lot about compatibility in Windows and all the tricks they used to make sure apps that were using APIs wrong (or just flat out pulled crazy stunts to hook themselves into Windows) could still run fine even on newer versions. Sad to see Google didn't apply the same engineering principles and are trying to shift the blame. Maybe because most Pixel phones are outside of their two years of updates...
> But Microsoft is certainly not going to try and argue that Teams doesn't have to be able to make emergency calls, at least not when it's used as a VOIP solution - they have plenty of documentation to help ensure emergency calls are routed properly
Teams can also run on devices where it's maximized and the only app available from the UI (think conference rooms). In this case it makes sense for it to handle emergency calls. But on Android where the user can be signed-in to N different phone apps at the same time? Not so much.
I don't see why Google is to blame here
There are so many regulated, built-in fallbacks to ensure anyone can reach emergency services from any cellular device that is within any network range. You don’t need a SIM, an active plan, and you don’t even need to unlock the phone first.
Google should be handling emergency services calls on the cellular network, and should have always prevented any third-party software from interfering.
> 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.
> Why on earth would you want apps to be able to intercept calls on a phone?
Android devices are not phones. They are computers that come preinstalled with some apps, one of which is a phone app. Importantly: They are not marketed as PHONES. They are marked as "Smartphones". Just search for the word "phone" on the websites of any major Android device manufacturers.
The distinction is important.
Be careful when punishing children from "using the phone". Today, this means that they cannot use the app called "phone". This incident is a stark reminder that "phone" is an app today, not a physical device.
But you are dead wrong about the word "phone". It still means those little black rectangles. If you primarily think of those little black rectangles as computers (or social media machines) then the word "phone" has shifted meaning to match that. If you punish a child by banning them from "using the phone" you will absolutely get the horrified reaction you'd expect.
Of course words vary in meaning throughout the world and maybe "phone" really does mean the classical phone app in your area, or in your daughter's social group. But that's exceptional, regardless of age.
Apparently, the "phone" in "smartphone" is about as relevant as is the "fun" in "funeral".
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.
As for this issue. All I can think of is the tragedies it may cause. It's a cliché: software developers are not responsible, except when their PR forces them to take action.
Got gmail, drive, translate, maps, and home? That’ll be a gigabyte of “bug fixes and performance improvements” every week or two.
I'm happy to download a quarter gig of gMail updates if they've actually updated something. Abstract "bug fixes and security improvements" doesn't seem like a worthwhile gig of updates every week.
Well one day when prepping for a life changing trip across Europe, I received an upgrade to the latest Android. I just went ahead and updated and then went on the trip. Little did I know, there was a bug in the firmware such that all video recordings were put through some sort of audio filter. That bug essentially garbled all the audio of all video recordings. I only realized to my utter horror after getting back that all my videos were ruined. I couldn't believe that Google didn't properly test basic functionality and released this garbage update. During the trip my friend had an iPhone 5 and it continually lasted her through the day. Meanwhile my Nexus was running low after 1-2 hours screen on time. It was a constant headache that I never realized before because before this trip I always just took the phone to work where there would be a charger and then back home where there would be a charger. I never realized that real world battery life of this phone was utter garbage.
EDIT: I also want to add that I recall watching a bunch of reviews of this phone by the "tech vloggers" and I am dumbfounded as to how they praised this phone or only lightly criticize things like the battery life. I received a totally false impression of this phone before purchasing. This experience basically put me off of tech vloggers as well. I still watch them but only for a cursory view on a product I am already considering getting. Looking back at MKBHD and others after dropping this phone I am just disgusted that I felt like I was duped.
After I got back I was fuming for a while over what had happened. I asked about this on the Nexus5 and Android forums and was met with a lot of hostile responses when I complained about how badly Google messed this up. I just couldn't stop thinking about my friend's iPhone 5. I never bought an Apple product in my life because I was conditioned to believe that they are just lifestyle devices for dumb people with too much money. I took a risk and ordered a pre-owned iPhone 5S. WOW what a night and day difference. This phone lasted me another 4 years and caused me to fall in love with phones again. I never realized that I was unconsciously avoiding having to use my Nexus5. With the iPhone I looked forward to using it.
This was a gateway drug to me taking a chance on an Macbook. I really wanted to continue using a *nix based environment but I HATED the constant challenges with keeping my Ubuntu environment going and the the equally toxic Linux community (I bet the terrible Android community overlaps with Linux).
I took the risk on a Macbook and there was moment where I felt like my mind jettisoned some dead weight. I could finally just walk away from both communities and not have to depend on them when my system/phone messed up. I occasionally load the latest Ubuntu/Ubuntu MATE/Linux Mint on a spare PC, find that some serious bug either didn't get fixed or reintroduced and then put it aside for another year. I'm not sure how to explain this feeling but Apple has given me the freedom to "not" be a part of the Linux/Android ecosystem and that freedom is the most valuable thing they provide.
I always dread whenever Google pushes an update to any of their products. I try my best to use extensions to remove their web based updates but sometimes I don't have a choice for their web based products. They have pushed so much useless garbage onto me over the years that I utterly despise their engineering groups. The latest screwup is "Reading Lists". Like come on man, Bookmarks worked perfectly fine! They had to muck up bookmarks?! Now I am stuck setting a flag to disable it(and repeat every time Chrome updates or I switch computers).
I can't fathom how a company of Google's stature has such a poor design and QA culture. There must be a lot of grifters who have spent so much time trying to get through their tough interviews such that all they know well is how to pass those interviews but not actually how to make great products.
I actually enjoyed nexus 5, nice form factor, awesome weight.
It was eventually fixed in subsequent firmware releases(while other things broke). After getting the iPhone as my daily driver, I opened up and started using the Nexus 5 as a tinkering testbed for custom roms. The smoothest firmware I have seen was a Cyanogen Mod release in late 2015 although it still had rough edges compared to my iPhone from what I recall.
Original iPhone (2007), iPhone 3GS (2009), iPhone 4S (2011), HTC One X (2011, not because the iPhone broke, a friend convinced me I should try Android, and on paper it seemed like I would love that so why not?), Samsung Galaxy S3 LTE (2012), Sony Xperia Z (2013), Sony Xperia Z1 Compact (also 2013), (LG) Google Nexus 5X (2015), iPhone SE (2016), iPhone X (2018), iPhone 12 mini (2020).
I actually knew I was done with Android by the time my Z1 Compact broke in the same way it had already been repaired for once (small crack in the display glass which the digitiser was glued to meaning touch stopped working on one side of the crack, unfortunately about 90% of the screen), but I figured maybe I've just been buying the wrong brands and figured I should give Google, the premium brand, a chance before I went back to iPhones for good.
Alas, the Nexus 5X was so bad (laggy, terrible battery life) I actually went back to my iPhone 4S (which I had also been using between the Z1 Compact and the 5X) within the first year, and then bought the iPhone SE when it came out and never looked back. That iPhone SE actually went to my little brother when I bought the iPhone X, and he stopped using it in 2020 after the screen finally cracked (still usable because Apple doesn't glue the digitiser to the display glass like many Android manufacturers do, a practice I personally think is to force repairs since it becomes impossible to use them without a repair).
Apple fined for slowing down old iPhones - BBC News – https://www.bbc.com/news/technology-51413724
What they should have done is include the toggle from day one, clearly explained why the feature was built, and then presented users with a prompt to enable it if the phone detected it may be necessary. Shoving it down peoples throats just made for terrible optics and "planned obsolescence" was a very well fitting and easy explanation in the absence of the real one that few understood.
Like, people still talk about it like it was a bad thing, see this thread for evidence, and this is one of the places where I would expect to find one of the largest concentrations of people that do understand what that patch did and why it was necessary.
Personally I think it's pretty great to know that I can use my iPhone even with a degraded battery and not have it shut down unexpectedly.
I've had both iPhones and Androids do that in the past, often in cold weather and during bursts of high load (like on a chairlift at a ski resort, which my example here is based on).
The idea was good, but it was implemented in a way that created issues for some users (eg: my iPhone 5 being sluggish all the time) and benefited Apple as most users would simply buy a new iPhone because no one knew what was going on.
That's 8 years of support if it's the last. It was the first 64-bit ARM phone, and the first to have a Secure Enclave, so it might be a bit of a favourite child.
Apple messed up the explanations and messaging on that incident big-time, but I'm convinced that they made the correct engineering tradeoff, and I feel like not enough people (even techies) really understood and appreciated that.
As this thread illustrates, a phone is a life-saving device. The priority must be to function when you absolutely need it. You will literally die if you can't call for help when you're stuck in a blizzard and need to call for a rescue.
Apple slowing down phones with weak batteries so that the CPU always has enough juice and doesn't crash is 100% the right engineering tradeoff for a life-saving device.
The last thing you need when you're bleeding out on the kitchen floor and dialing 911 is for your battery to not supply enough power and then force a phone restart or worse when seconds are counting down.
Not sure what you mean with life changing, but from experience: if you ever find yourself in a situation where you go on a trip and your health might depend on the ability to call or navigate, don't ever use a smartphone for that ability :)
Also got to do a lot of deep thinking while traveling across Europe. Wish they were more united. There are so many unbelievably talented people in Europe. It would be interesting if they could compete head on with the US and help to keep us more on our toes sort of like a second super power. I think that would be good for the world. Alas I saw how things like this are just not possible because people do not believe in it. The same problem I had before I came to Europe! Its unfortunate because Europe has all the components to be just as competitive as the US (in my opinion). :)
I always prepare the possibility of fresh install / factory reset when upgrading.
Which is why google play's auto update when I'm outside made me angry.
However, I found myself in a similar situation as yourself with my Nexus 6P. Newlywed on a beautiful island all by ourselves ready to record some memories. 6P took phenomenal pictures and we were all ready with tripod and remote clicker. 6P just died. Luckily still had the wife's old iphone which managed to capture the moments, but not in all its glory.
Went through one more iteration of Android with a Motorola, that they stopped supporting about 3 months after buying.
As I've said in other posts, the amount of ewaste I generated while in the Android/Google ecosystem is criminal.
Switched to an iphone and haven't looked back. I'm still on the same iphone years later, still getting updates, still chugging along.
In all honesty, I preferred the Android OS, but it's too expensive to tolerate in so many ways; money, time (learning the new UX every time there's an update), environment/ewaste, privacy (google and affiliates vacuuming up all my personal information), convenience (it doesn't breakdown when i need it the most).
Much cheaper than pixel and iPhone and Samsung has a design language that many prefer to stock android and ios.
Moreover, when it comes eventually replacing the iphone, I'm going to get a better trade in value than the android even if it's 3-4x older. Thus lowering the cost of my next phone. (less ewaste bc i know the iphone will end up in someone else's pocket, not in a landfill)
Maybe Samsung is different, but when I went to trade in my $7-800 Motorola after 8-12 months of use, I was offered $28 trade-in value.
My time is also worth money. I don't have time (money) to waste on dealing with android.
Samsungs provides 3-5 years of updates for current mid and high end phones. Does your iPhone last 5x4=20 years? Will it be worth much even in 5 years? But if you trade it only after one year, how does that in any way reduce ewaste?
When I got my current phone it was 1/3 of an iphone and 1/5 of the most expensive Samsung (the fold thingy). It works well and is guaranteed at least 3 years of updates. But I plan to use it as my daily driver for 2 years, maybe 2.5. After which I will probably keep it and use it for something else around the house.
I have zero interest in a f!cking OS pushing ads into my face.
This is an unspoken downside of that ecosystem. I have also generated many phones worth of ewaste when I give up on them in less than a year. Its one of the reasons I stopped playing games with all these manufacturers and just bought an "official" Google phone and not touch it software wise. It obviously still wasn't enough.
I was recently cleaning through my attic and I found a lot of these old Android phones. Its amazing how many of them didn't get anywhere near the support that iPhones phones do. I told myself that I would eventually find a custom rom for them and then reuse them for something else but lets be real, that is just another time sink that probably won't happen. Now I am left staring at these phones wishing there was an easy way to deconstruct all the components into their base materials. I know that it is possible to break down the plastics via pyrolysis but no one is really doing this. Secondly there are the circuit board. FR-4 is ground up and used as filler from what I understand. What that means is that even if this phone is recycled, it will never really fully go away. Put in that context, the Android ecosystem just seems even sillier.
A phone needs to be able to make 911 calls even if its the most unhumble, inefficient, unreliable platform. This is completely offtopic.
Another example is the fact that it has some sort of human input device and output as well. That's also a "bare" requirement, regardless of how bad the phone is and how unreliable it is.
In the same way, food needs to be edible, a mirror needs to be in some way reflective, etc.
I've experienced the severe decline in stability over the last 10 years of use, and on flagship phones, not outdated.
Currently my Pixel sometimes displayes an open app partially off screen, or scaled wrong and clipped --- this is basic UI that worked for years and is now broken again.
For example, since upgrading when I use my "<Car Company Name> Remote App" to lock my car the phone will crash to the lock screen and get stuck there. The only way to get out of it is a hard reboot. Shocking.
While driving to NYC recently, I briefly lost all signal between two bridges; the whole phone slowed down rapidly and hung within a couple of seconds, google maps frozen on screen.
"Release" is the Google terminology for "it compiles, let's see if it works".
That's why most people are okay with the 3-6 months Samsung lag. They simply get a much more stable OS compared to Pixel users.
Source: owner of multiple Google devices.
The problem is that there are about 5 different ways to get the temperature through google now, probably all built by different teams, so everyone suggests a different way to set your temperature units, but they're all wrong.
Pretty sure the same thing is happening internally at google with every team just trying to blame each other one, and no-one caring enough to fix the issue.
It just feels like shoddy coding.
[0] https://support.google.com/websearch/thread/105615277/temper...
My theory is Google was never setup to maintain such a thing.
I think an operating system running on customers hardware requires quite a bit different, more stringent, responsible approach to development and release process. Microsoft seems to have it (albeit with their own flaws and in recent years they went rogue - when they fired their testers, shoot it was almost 10 years go).
Google is not setup in same way and internal incentives are not like that, judging by hoard of messaging apps. They are simply setup to make very short projects that do not require long-term commitment. When people move on, projects get abandoned, neglected and killed. Their incentives structure is like that. It is one thing to change a webapp willy-nilly and another thing to change and support code that you ship to millions of devices you know nothing about.
During 90th Windows had a lot of growth problem that Microsoft was figuring out, now Google's doing the same with Android but I don't think that they will succeed unless they change their incentive structure.
Now having said that about Google, one has to admit that it is _vast_ and there are a lot of different teams and I suppose there are plenty of teams that work in different way. But still, they can't be shielded from corporate overall culture.
I see feature creep and sloppy functionality in the core as a symptom of the usual tech project management style, where there's pressure to make up random metrics to have flashy results over maintaining existing functionality.
Proper testing has the same impact for your performance than just ignoring the metrics you are supposed to test. You can also get praised when you fix the problem your sloppiness caused.
In my experience, major iOS updates don't contain drastic changes and at first glance they don't look too different. Each update feels like a refinement of the previous release, especially compared to Android.
Android is a bloated mess and this bug should be a giant red flag for both Google and MS to get their shit together. Windows is currently a huge mess as well, bloated beyond repair and with "features" nobody ever asked for, but hey, who doesn't like advertising on their login screen and unrelenting telemetry?
She still uses Mac thoug.
Frustrating how the best software engineers can't compete with a hardware company (Apple Inc).
Allowing for a moment for a moment the premise that Google has the best software engineers, the company seems to be structured to ensure they output mediocre work. Awful performance, poor to terrible UX, poor documentation, weird or ill-advised implementations of public-facing interfaces (say, libraries), et c. There are exceptions, but "high quality software" is not something I associate with Google.
I went through that over and over again for the better part of the decade before finally jumping to an iPhone and swearing off joining any new Google services. Being a Google user is being in a perpetual state of beta testing where you pay them with your data. I'm convinced they're never gonna learn their lesson.
There seems to be something fundamentally wrong with it that resists change. Plus in some cases Google simply doesn't seem to give a shit about the platform, letting it lag behind JS versions of their service SDKs for fairly basic functionality, or announcing big UI overhauls but then severely half-assing the developer-facing side of those features.
Sure, devs get used to it fast and can be productive in no time. But it's ridiculous how much hoops they invent out of sheer corporate-ness. (Importing projects? Nah, it never works on the first time. Upgrading projects? That basically only works if you recently sacrificed someone's firstborn. Adding some 3rd party library and getting the build system and the IDE work without spending hours fighting them? I hope you started this journey with two kidneys.)
[0] I just made it up, but wouldn't be surprised if someone does that
To be clear, I don't expect google to actively support such an old phone, but I do expect them to properly test updates if they decide to send them to a particular model.
> AOSP updates via Pixel Experience ROM
I'd be interested to know what this is! Is it something I can use?
Edit: Found it now - looks interesting. Was the installation relatively pain free?
- Connect USB
- Boot in Fastboot: Press and hold Volume Down, then press and hold Power
- Install TWRP recovery `fastboot flash boot twrp-...`
- Select to boot recovery mode using Volume Up/Down
- Format system and cache partitions ONLY. Leave data and internal
- Choose Advanced > Sideload, then run `adb sideload PixelExp...zip` on computer
I can't stand that anymore. Every single updates make things more and more unusable, they hide settings, they make buttons bigger for no reasons, &c.
They even managed to butcher the alarm app... it looks like an app designed for visually impaired people (which would be fine if it was an option and not the default/only choice).
In fact they stripped lot of features by trying to hide stuff in layers with that god awful UI. Sometimes I feel like Android tries too hard to be iOS and loses its identify completely. If I wanted an iOS experience I might as well use iPhone.
* Clock takes two lines on a lock screen. Gigantic clock! Because we have poor vision.
* "Now playing" runs on a lock screen and a lock screen only
* Google Assistant cannot be fully disabled
* Native launcher uses VERY LARGE ICONS - 4 max in a row! A-la AARP advertised phone for grandma with big buttons.
* Can't remove Google search bar via native launcher.
* One tap disable?! That's for penguins! We are not penguins! We are senior citizens! Our fingers need exercise!
Software didn't have to be this way...
At least i hope not, I wouldn't be surprised to find a cooker controlled by a phone style touch screen running Android.
I tried to buy one with physical knobs but was told that the manufacturers who make them are moving to the touch controls.
So I’m going back to gas.
I'm mad at the thing just writing this!
That's exactly what happened to me while staying in a serviced apartment. It's hilarious, ridiculous, and sad all at the same time. As a software developer I died a little inside that day. Fortunately I haven't had to put up with that crap once I checked out of there.
With mine moving the pan on the wrong plate will trigger a lock button, in other words it locks the whole interface. So even if you want to switch the whole thing off you first have to press a button that's now as hot as your pan.
There's no escaping horrible user interfaces.
Meanwhile 10-12 years ago my cousin was ticketed for distracted driving in the midwest because the trucking company he worked for bolted a laptop to the dashboard of his semi tractor. Though somehow these mostly useless screens are okay to have? I dont get it.
But but but how else would you get the gigantic digital clock take TWO lines of a lock screen?! Someone needed to design it!
I hate the new color palettes as well, I wish I hadn't upgraded
I'm on a Pixel6. It is kind of an upgrade to my previous 4 year old phone and I sort of like it but no, it does not have a better battery and it barely has any better performance, but other Android phones are ad-ingested junk ( looking at you, f!cking Samsung ) or a joke of a software ( Looking at you, OnePlus), plus they arent whitelisted on major US carriers in Feb 2022, so Pixel it was.
The new UI is total junk compared to the UI of 11. To make it somewhat better I replaced the launcher with ActionLauncher 3, disabled gestures and disabled Google Assistant.
What I want to know is if "Now Playing" can be made into a widget/app-tap, because no, I do not want it always listening.
Basic aspects of the display, like the clock, cannot be customized at all.
I don't use Apple products because they feel locked-in, but Android is almost worse sometimes.
Totally shit design. And could still have lower input lag. But instead of reducing it they added slow animations to try to hide it, which makes it take even longer!
We are going to... Material YOU!
"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?
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.
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:
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.
"We believe the issue is only present on a small number of devices" -> Reads like damage limitation. Don't believe it, say why!
"we are currently only aware of one user report" -> Irrelevant. Damage limitation. Don't ever write this. Most users will never be able to recognise it as an Android problem, even fewer will have the ability to bug report it.
-- https://www.reddit.com/r/GooglePixel/comments/r4xz1f/pixel_p...
I don't think it affects finding that device from other devices.
* Can't make calls
* Can't receive calls
* Can't send text messages
* Can't receive text messages
* Receiving text messages out of order or days late
* Can't take pictures
* Can take pictures, but they don't save
* Phone randomly shuts down when cold
* Phone randomly shuts down when hot
I bought myself a $400 iPhone SE. It may not have every feature I loved from Android but it's 100x smoother and more reliable. I don't regret the move.
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.
I did this three times before switching to a friend's phone. I don't remember what apps I had or even what phone it was (except being Android) but it was a pretty bizarre and scary experience.
Yes they royally f'd up. However Teams is a voip carrier among other things. As of Jan. 6, 2022 they are not allowed to ignore 911 anymore. They HAVE to allow 911 calls. Even being a non fixed device. And on android this does mean interacting with the dialer.
(I have no affiliation with google or microsoft. I however did switch our small company to voip earlier this year and had to take a deep dive into the legalities.)
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...).
Unrelated, but in 2012 or something like that, I was out walking, on my way to a meeting. I literally stopped mid walk, and turned another direction, went to a store and bought an iPhone.
My, at the time, state of the art Samsung galaxy S3 had just prevented me from answer an incoming call due to a software bug. As the S3 froze and then crashed, a crushing realization hit me; what I was holding wasn't a phone, but something else. I was even a poor student at the time, but due to engagements, I was completely dependent on my phone working, or as I then realized: "Having a phone".
I am only posting to add that with my pixel 3 I am having issues with incoming calls being dropped or the interface not allowing me to accept an incoming call. Especially since the new re-design of the caller app a few months ago. Even an old phone should always be able to call and accept calls.
Due to the emergency use-cases, I really think call functions should be the highest priority of smart phones and I cannot understand why there is so much sloppiness in QA with this. There is going to be kids out there that try to call their parents and their calls get dropped, same with elderly or otherwise vulnerable. You don't always want then to call 911 as first resort. But hopefully they remember to do it if cannot get through to their carer..
Before people suggest it, getting a second phone that guarantees handling incoming calls in not practical, as they would have to dial a different number than usual in an emergency.
https://www.thecustomdroid.com/remove-emergency-call-button-...
Normally I feel like it's a strength of the Android operating system that users are allowed to make whatever changes they want, including handing off all responsibility for phone calls to Microsoft or whatever. But in cases like this where users might not understand what that means I wonder how we can put in better guardrails while still maintaining the systems flexibility.
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.
No matter how many Windows updates I install, or how many times I update drivers and firmware, Teams on Windows 10 on my Dell laptop is a very unstable combination. When on video calls it causes problem conditions in the graphics drivers that destabilise Teams, sometimes other applications such as Firefox, and will fairly regularly bluescreen the OS.
Again on video calls it also interacts poorly with Killer WiFi drivers leading to:
- intermittent drop-outs in network connectivity affecting all applications, including Teams (but not other devices on my network),
- total loss of WiFi connection, requiring disable/reenable of my wireless network adapter, and occasionally a machine reboot to resolve
- again, OS bluescreens
These problems only happen during Teams video calls, and most regularly (though not always) after the system has slept and woken at least once since its last reboot.
I'm not even going to dive in to the multitude of application level problems (failing to load calendar, failing to join meetings, breaking copy & paste, and on, and on). My point is that, as much as Google is at fault here, so is Microsoft: Teams is not good software. It is not built with safe interaction with the OS in mind, and it is not well tested.
Feature-wise Teams is far and away ahead of alternatives such as Zoom, and call quality is generally better than some alternatives, such as Google Hangouts, but it's let down by poor engineering and, as I've already said, inadequate testing. In the case of OP, with very serious results.
It’s hard to blame anyone else but Google for this.
The Teams UI probably stresses your graphics card in some unique way.
Enable memory dumps and then get one after a bluescreen and run it through windbg.
I hung up immediately, but they called back. I apologized profusely and explained my phone had done it, the guy sounded skeptical but let me go. Sigh.
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.
Developing and testing this feature is probably less convenient than normal calls, since it requires you to either have a fake 911 setup (meaning operating the phone in an rf shielded environment and with a fake tower) or actually disturbing real 911 services.
So, while super sad, not surprised at all.
Apparently this was an Android bug triggered by installing Microsoft Teams.
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 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.
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...
Smoke-alarms and GFCI-devices do, enabling folks to ensure that the device'll behave properly.
Presumably there'd need to be some sort of systemic support for a test-feature, where emergency-services would have recognition of the concept such that they'd filter out test-calls, but only at the very last stages. This way the entire system performs the test, but operators wouldn't be tied up.
Alternatively, route test-calls to a test-operator, that'd presumably be an automated system, as to not burden actual emergency-services.
> 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.
https://www.washingtonpost.com/archive/politics/1994/12/13/d...
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.
Also, as many of the Reddit comments state it's perfectly okay to call 911 and immediately tell the dispatcher you're testing and ask them to read you the address that appears on their console. I do it all the time in various places around our service area for QC purposes.
They claim it is so 911 can call you back in the event of a dropped call but oof, just not cool.
> If you are unsure what Android version you are on, confirm you are running Android 10 or above
My Xperia X is still on 8.0.0, it only got a few months of updates before they just silently stopped sending them, displaying that my "device is up to date!". This is a widespread problem in the Android market, in comparison, my iPad Air 2 is still getting updates 8 years after release. Google keep saying that they want to work on this, but realistically, is it ever going to happen?
9 and below not affected. It's not the clearest phrasing, I had to do a double-take while reading it.
My opinion is that given that the phone knows you’re making an emergency call it should immediately kill all non system apps (including Builtin apps like the browser, messaging, etc being killed) to minimize chance of something like this happening, and to maximize battery life
Question for HN: Is there any formal critical contact network between Google, MS, Apple or other large companies? In incident responses like this are people relying on personal contacts?
My experience (Canada) has been that they don't like it when you call and hang up.
But I would sometimes call and say "Hi, I'm mig39 from my organization, and I'm just testing that I've programmed the phone system here to dial 911 properly." They had no problem with that at all.
I don't think Microsoft Teams is clear of blame as well. Apps trying to do more then what they are made for is a huge problem.
Why in the blue blazes of fuck is any app without root access capable of interfering with emergency phone calls or interacting with them in any way?
Smartphones are now super cool mini computers but not phones first anymore :/.
Someone really messed up the compliance testing - probably because it was never tested with fake location enabled.
Then it can somehow jump and start apps too, especially the music app.
Is there some way to disable this?
Surly this should be resolved by the operating system by not allowing apps to prevent an emergency services call!?
> I'm supposed to trust that a phone will do the main thing is built for, and place the call, and let me speak to the human on the other end.
We are not in 1990. Smart phones are only similar to phones in that they have "phone" in the name.
Edit: I just read through some of the Reddit comments and see that Teams was the culprit, which is an insane bug: There is no way that a user space app should be able to do this.
I also still think the FCC should do their own work on it too. They need to make sure Google isn't downplaying this, and is actually taking steps at the highest priority to make sure an app can't do this.
The more complex a project is, the more difficult it becomes to make sure it's reliable.
I have way more trust towards an old nokia phone for that kind of thing than any smartphone. It's odd how security and reliability are better retained for more minimal softwares.
I guess this will always be true.
That's why it's always better to do one simple thing and do it well. The more feature you add, the more you need to increase constraints and add new rules, at an exponential rate.
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 do, and Facebook no longer has native iOS support
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.)
a) The dialer is software. Your calls are not analog.
b) As a user, I _should_ have the freedom to choose a different dialer if I want. (E.g. I am on a data-only plan, and I want to use VOIP.)
c) Say I'm on wifi with no tower reception (as used to be the case when I lived in Virginia, within 50 miles of DC). 911 calling over wifi works on some carriers but (I believe) not others. It's therefore fine for third party dialers to be able to handle 911 - VOIP might be by far the more reliable alternative for a particular user's circumstances.
d) MS Teams registered itself to handle calls, regardless of whether or not the user was logged in, and some bug in that area caused it to lock up after the call was made. They're likely fixing this specific aspect - if you're not logged in, it will pass-through calls to the next app that's registered as a dialer. Straight up bug.
e) There should be (and likely is?) a certification process for apps that want to act as the dialer. Is Google liable for distributing an app that registers as a dialer that has a bug when it comes to 911 handling? Maybe. It's a slippery slope to make the distributor liable for third party developers' bugs.
f) The user stated that the emergency call was going on in the background while the UI was locked up. To the Android OS, the app was handling the call. It's pretty obvious that it'd be hard to detect. Should Android have detected the high CPU, terminated the Teams app's process, and then fallen back to the native phone dialer? Clearly not, because the call might actually have been in progress, and the operator might have been taking information from the user.
Seems to me that the best Android could do is to add more functionality to the special 911 dialing UI. Specifically, it should probably prompt the user to choose which dialer to use, and within N seconds of no response automatically choose the native dialer (IF there is a tower signal, or it can route the call over wifi). If an alternate dialer is used, it should maintain an overlay on the screen allowing the user to switch to native dialer with one click, terminating the alternate app.
That all said, longer term 911 itself probably needs to enter the 21st century. While it will take some time, voice calls probably won't be around with the same infrastructure in 50 or 100 years. Why shouldn't there be 911 over whatsapp, SMS, hangouts, meet, whatever else? Why shouldn't there be a 911 app that comes preloaded? Imagine being able to send video or photos to the 911 operator. Clearly there's a high bar for reliability, but bear in mind that cellular providers themselves are not offering consistent coverage across the US / world, and that land lines are going the way of the dinosaur.
> Out of an abundance of caution
I hate that phrase Google will release a patch for their bug out of an abundance of caution? Thats not an abundance of caution thats just standard practice.
Sounds about par for the Android team's awareness of what a steaming pile of cow dung their OS is. I gave up on Android long ago and I'm aware of many reports like this.