When I used to work for a large mobile network, we would spend ages testing the firmware of new devices. Even giants (at the time) like Nokia would release phones which couldn't dial the emergency services, or put out more than the legal limit of radiation, or were in other ways defective.
We'd test, send a report back, wait a few weeks, get a new firmware, test again, repeat until everything worked. It took months. That was fine when phones weren't expected to be updated by users.
But when more modern phones arrived with flashable firmware, customers couldn't stand the delays associated with testing. They'd see a new firmware had been released and complained that the mobile network operators were delaying progress, dragging our feet, deliberately depriving customers of something cool.
The fact was, operators very often didn't certify the firmware because it contained *dangerous* bugs. I'm sure there was also a cost element - why pay to re-test a phone that you're no longer selling? - but that wasn't the primary driver.
Well, the manufacturers and customers "won". If you buy a phone through your network, it probably has a network-certified firmware blob. If not, you're at the mercy of the manufacturer.
Well, the fact that big American mobile operators outright blocked or delayed updates for months did not go unnoticed.
Testing is one thing, but in my first hand experience, many carriers used this "testing" as a convenient way to block phone updates without preloaded bloatware preferring their services or apps they were paid to put on the phones.
> many carriers used this "testing" as a convenient way to block phone updates without preloaded bloatware preferring their services or apps they were paid to put on the phones.
How were you involved with the update process to know this?
Basically part of the reason Apple went with AT&T was they were the only carrier willing to let them control the user/feature layer of the stack.
The other telecoms would have this giant requirement document they dictated to handset manufacturers - which is why your crappy Motorola flip phone had three way calling buried 7 menus deep that nobody could use.
Things got magnitudes better when Apple leveraged their power to take away this control from telecoms. Though they still did agree to adhere to the minimum specs wrt safety/security.
The crappy Motorola rockr phone that Jobs hated is what happened when you tried to work with the telecoms.
This is what Apple claims, but what I heard back at AT&T was Apple demanded full payment for every sold device up front from AT&T, meanwhile every other vendor was providing multi-year financing.
AT&T had much worse commissions for selling iPhones than new lines for a reason. Meanwhile, Verizon, Sprint & T-Mobile played the long game and waited to sign volume commits and financing terms with Apple.
The carrier specific iPad financing promos where they sell you a tablet well below cost (even factoring in the 2 year data plan cost) is a situation created by these minimum volume commits.
Adding on: phone update 1.1.2 would be released from the phone vendor, with fixes for various bits. Carrier 1.1.2 would be released with undeletable spam apps and undeletable spam bookmarks.
We know this because both versions would end on XDA Developers.
The way I see it, this just moves the responsibility for safety to the manufacturers instead of the network. It's on the specific company then to provide adequate QA for their firmware before they release updates, or it reflects badly on them. This fiasco for example, tells me to never buy a Google phone since they apparently don't test their devices properly.
I'm not sure why it would be on the network to test devices anyway, it's not like every net card needs to be approved by ICANN or something. There should be standards to adhere to, if those are breached on either end, fines should follow.
This is probably like the fourth or fifth time issues calling 911 has come up for Pixel phones too. Google simply isn't capable of producing life-critical software.
> Google simply isn't capable of producing life-critical software.
I was stuck with a broken-down car at night before and needed to see my location on a map. Google had opted me into some A/B test on Google Maps that broke the entire app and made it unusable, I couldn't find any way to get out of this test.
Friends iPhone worked perfectly fine and ended up being used instead.
This was probably the biggest factor as to why I dropped Android and got an iPhone, you simply can't trust Google's software quality.
That's obviously true, after all Google's principal role in life is to make money though advertising not through saving lives.
As I've said elsewhere, ultimately it's the responsibly of the regulator in each country to ensure that phones can connect to emergency numbers irrespective of what operating system or apps are installed on them—so that's where the problem ought to rest.
That said, it's clear that that view doesn't sit well with a number of commentators here, for within seconds of posting it together with a solution and the reasons for why the comment was voted down sans comment. With attitudes like that about one can expect Google to prevaricate.
That leads me to think there's more to this than just a clash of software nuking emergency numbers. If I were the regulator I'd be asking for the source code from Google on threat of future non-approval of Pixel phones to see what nefarious antics Google is up to. (It's clear to me that it's just too coincidental that blocking 911 would happen unless Google is specifically monitoring the number for some other unspecified reason.)
I think you’re being unnecessarily hard on Google.
When someone dials 911, there is a ton of context data that needs to be collected, analyzed, and added to Google’s profile of the user to ensure the most relevant ads can be served in the future.
There’s location data, whether the user is driving, connected Bluetooth accessories, other phones in close proximity. All of this needs cutting edge ML processing so the user model can be updated with e.g. “likely domestic violence victim, recommend self defense courses” to improve the user experience the next time they search for a pie recipe.
Given the heavy lift of this advanced algorithmic processing, it’s inevitable that some minor bugs will creep in to ancillary functions like connecting the user’s phone call to emergency services. Even when that happens, it’s still a >95% success for the scenario.
> As I've said elsewhere, ultimately it's the responsibly of the regulator in each country to ensure that phones can connect to emergency numbers irrespective of what operating system or apps are installed on them—so that's where the problem ought to rest.
If you are selling a phone, you have to comply with phone regulations and it’s your responsibility to make it do phone things.
Blaming the regulator for Google’s error is a neat idea though.
"The way I see it, this just moves the responsibility for safety to the manufacturers instead of the network."
Perhaps so in the current circumstances, but ultimately it is the responsibly of the regulators to ensure the emergency numbers work.
As witnessed here, a number of commentators seem to have forgotten that their smartphones are first and foremost are telephones and not playtoy computers. Unfortunately, the computer aspect now seems to dominate—if this weren't a fact then these unfortunate incidents wouldn't have happened.
> their smartphones are first and foremost are telephones and not playtoy computers
I don't think that's true. A few years back when I was comparing phones, many reviews don't even mention how good they are at making calls. Both Millennials and Gen Z are notably phone-averse. [1][2] I think a modern smartphone is a portable network computer/camera/sensor-package, with the telephone bit being something like the human appendix.
As somebody in Gen X, it looks to me like the whole notion of "phone call" is a dying concept that only existed due to the technological limitations during the period 1880-2000. Think of it sort of like faxing: it made sense at the time.
Yes this. I've always disliked phone calls, especially with strangers. All service stuff should be accessible via SMS or email unless it's urgent. Then I can send and forget and they can reply when they're ready. No fumbling to get to the calendar that's on the same device you're trying up speak into.
> I think a modern smartphone is a portable network computer/camera/sensor-package, with the telephone bit being something like the human appendix.
A modern smartphone is a convergence of two devices: a PDA and a cell phone (this is more obvious with older devices like the Palm Treo 650). Once the telephone bit is no longer relevant (probably replaced by a data-only cellular modem), it will go back to being just a PDA.
The QCI (QoS Class Identifier) for carrier provided voice and video (Android only) calls is generally much higher than normal data, and carriers monitor call handoff reliability between towers, Mean Opinion Scores (MOS, a rating of the audio experience of each call), and device specific performance.
"Making calls" isn't a feature phones compete on - it either works or it doesn't, and I hope a review would let me know if calling was defective on a phone. Otherwise, there's no point in including information on making calls - it's a basic feature everybody who buys a phone expects to have.
It's a bit like saying "most car reviews don't review whether the car stays still when parked in a garage or not!"
That's just not the case. Phone audio quality varies significantly between smartphone models due to variations in speaker, mic, and noise reduction. And that's before we get to fancier things like Wi-Fi Calling and HD Voice. The whole reason I was looking for that in reviews is that people had a hard time hearing me when I called from my previous cellphone, and I also noticed that some people I was talking to had much clearer voice calls than others.
If you had difficulty being heard on a phone, then your phone has failed at being a phone.
Also, splitting hairs over phone audio quality is beside the point. The point of a phone is to be a phone, smart or not. I would be livid if my fridge could play games but not provide cooling. A smart fridge doesn’t negate the primary function.
If audio quality is beside the point, then it sounds like you agree with me that the primary point of a smartphone is no longer that of being a phone.
I also think your "smart fridge" analogy is hilariously off target. Survey data indicates that the actual phone calls are a relatively small fraction of smartphone use: https://www.reviews.org/mobile/cell-phone-addiction/
I agree that the primary purpose of a cellphone was once making calls. I'm just saying that day is long past. That transition started as texting became popular, but smartphones drastically accelerated it.
> a number of commentators seem to have forgotten that their smartphones are first and foremost are telephones and not playtoy computers.
Speaking for myself at least, I can tell you that it's not so much that I forgot as that I don't care and also you're wrong. Yes, it's good - perhaps even important - that the computer I carry in my pocket every day can also theoretically make phone calls, but it is most certainly first and foremost a computer.
This is such an uncontroversial take, I’m really surprised to see it get so downvoted on HN. I upgraded my phone the day after it froze when I tried to make a call. I never want to be in a situation where I can’t make an emergency call. That’s sortof the whole point of a “TELEPHONE”??
Because for many (probably the vast majority) it's not true. Their smartphone is first and foremost a portable computer. The ability to make calls is secondary.
it's a simple reason - google relies on automated tests and doesn't do manual testing at all.
if they did plenty of bugs on the home scree launcher would've been found.
source: I used a pixel 3a for about 3 years, now I have a pixel 6a.
all errors I have run into are things only a human can find. low laying fruit.
Most people buy their phone from a network provider / carrier. And when someone goes wrong, customers complain to the network - not the manufacturer.
That's why networks test firmware. Because they face the complaints and chargebacks when the phone breaks.
Mobile networks are, in effect, private networks. Your employer may prohibit certain devices from connecting to their in-office LAN. Or they may insist on specific devices which they know work well with their equipment.
Mobile networks can ban equipment which is stolen. I assume they can also de-register an IMEI if the handset if interfering with the network. Most countries have a regulator who can issue fines for disrupting the airwaves. But they are often unable to investigate non-systemic issues.
Perhaps staying inside the network is more common in the US, but from a European perspective it's unlikely for a device to stay at one provider at all times. Half the time you're roaming at another network due to missing towers or if you drive 100km and end up in a different country you won't see your original provider at all until you return.
As such, all networks must support all devices for the system to retain some shred of functionality and standardisation is key. Providers can't just pick and choose what to support if they want to maintain credibility. I would imagine it makes far more sense for some international org to do reviews, but at the absence of that the manufacturers themselves need to guarantee compatibility or they will be pushed out of the market by those that do.
I would assume that will run afoul of EU regulations which forced the providers to enable roaming without additional costs. If providers could just deny roaming phones they could use that to circumvent the regulations (which are unpopular with network operators).
In the case of a phone with defective emergency calling software/firmware/hardware they must have a means of detecting and blocking such phones from making spurious calls, right?
If they already have this capacity in place then detecting and blocking out-of-network phones from roaming should be trivial.
I’m not sure this isn’t a dated take, unfortunately. Perhaps this would have been an accurate set of statements back in 2012 or so.
1/ Roaming is a big factor (before COVID, and now in a post-COVID world too). I’ve spent more time on carrier networks which are NOT my ‘home network’ in the past 3-4 weeks than not, in many different countries, managed by many different regulators. I didn’t need a new phone for each country, a software update for my phone, instead it just worked.
2/ I’m not unique in buying devices from the manufacturer directly - specifically, I use the iPhone Upgrade Program. Lots of friends buy direct from Apple or via electronics stores like Best Buy but every 2-3 years. I hear very few people who “got their phone from Verizon” (but I’m sure this still happens, too!). [1]
3/ At least in the Apple ecosystem these days theft and loss is handled with Activation Lock, which is IMO more effective than IMEI blocking because it works regardless of cellular network and without relying on any assumptions networks may share a blocklist of reported stolen IMEIs amongst themselves.
It was considered the utmost priority for a call to 911 to be clear enough for the other side to hear that you are an employee at a testing facility verifying that the device does work and the other person can hear you and NOT dispatch emergency services....
Not often, and we didn't get fined (they were like three blocks down the road)
It was really bad around the VolTE roll-out because the firmwares were pretty junky at that point (like a 10-1 failure rate) so we started doing testing calling from a phone to another (working) phone before doing the emergency services call.
Wait, shouldn't be something like FCC certifying emission levels not some random mobile network operator ? Or at least company run by them as to not have to repeat test same thing over and over again ?
Emission levels are complicated. There isn't a particular threshold they have to be under. Rather, phones negotiate with the tower to use the minimum power needed to get their signal through, depending on their distance from the tower and other factors. Using lower power means less interference with other phones as well as increased battery life and less RF absorption by the user's head. This negotiation has a lot of parameters that vary between carriers, so carriers legitimately need to test that every model and version of phone works reliably on their network and doesn't just start blasting at full power sometimes, causing other calls to drop.
Also phones (and towers?) in border areas have some logic to avoid roaming onto the other country’s network.
This leads to lots of misconceptions too.
With a local Rogers SIM from a high building in Toronto, my phone will only see Canadian networks on a network scan. But when I put in an EU SIM, same phone and same place, a network scan will see several US networks and even prefer connecting to them (probably cheaper roaming rates), even if the connection is ultra-weak.
Feels like there’s some geo-fencing preferencing, or maybe time-distance bounding going on.
OK, there's a super-high limit 100x greater than what phone hardware is capable of putting out. But that's not what carriers are testing -- they want to see that it only uses say 0.5 mW, not 1 mW, when close to the base station.
I appreciate the value of this, but the incentives are too biased to function properly. I think a good remedy (which would also tackle a number of other conflicts of interests and biased incentives) would be for anti-trust prohibitions on mobile network operators from selling cell phones at all.
Let the network operators continue to certify phones, like hardware manufacturers do with hard drives, memory, etc., dimmer manufacturers do with LEDs, etc.
Make the certification tests, steps and costs transparent to both device manufacturers and the public.
And I hope we never go back. That phase of mobile phone history was unbearable and carriers insufferable. If issues are slipping through, it’s manufacturers who should be held to account for their faulty devices. And if faulty firmware/software is a persistent problem, then society should step in and regulate.
Such things should be under the prerogative of the national telecom regulator body to be checked in the type approval procedure. After all, before EU took the care of this, telecom equipment in European countries had homologation marks of the local FCC equivalents.
Yes. From memory we had a specific SIM which was registered with 999. We dialled up, gave a password of the day, and asked them what info they could see about the call. They could see IMSI, IMEI, Cell Location and other things like that.
(A couple of decade ago now - my memory might be inaccurate.)
You call the regional center (the 911, or in our case, 112 responders), you negotiate a timeframe for your tests (so that there's enough operators there), you tell them the phone number (and other data) that will be used for testing (because the responders get the approximate location of the caller, and might still send someone to check after a call, even if the voice doesn't get through), and then call 911 (112 here) a bunch of times.
Also, emergency calls have to work even without a sim card inserted, or with a simcard but still locked (via sim pin), or with an unlocked sim but locked screen, so that had to be tested too.
This was also a huge issue with BlackBerry 10. We kept getting bugs about 999 being dialed because of the way the screen recognition was... The phone would wake up in your pocket, dial 999 and you'd pocket dial EMS because it was allowed to be dialed from above the lock screen no matter what.
I’ve accidentally dialed 911 via the side buttons on my iPhone (I put it into the drink holder in a chair, and it was just tight enough to depress the buttons) and at least twice via the buttons on my Watch (trying to swap out the watch bands). Oh, and once my Watch was wet, and it registered my slide motion in the wrong spot.
Admittedly this is roughly once every 2 years, but still I’m about at the point where I’d like to disable all automatic emergency services.
I had to do this because the kids discovered that if they held down power off and then slid the bar over a nice woman would talk to them and then a big truck would show up!
I let the kids play with an old flip phone, figuring they couldn't get up to too much trouble since it had no service.
Came downstairs to hear them talking about calling 911 - when I picked up the phone there were four outgoing calls!
Fortunately the big truck did not show up, so I guess the operator was able to figure out that there was not actually an emergency (or maybe the phone was too old to communicate its location).
Thanks, apparently I did turn them off at some point. Doesn’t appear to be a way to disable the emergency slider on Watch or iPhone though, unfortunately.
My Pixel 5 had an issue with its power button a few weeks back where it would self-press the button. (I believe some rain had gotten in somehow and was shorting the button).
This resulted in the phone doing various things, such as opening the camera (double press of power), trying to turn itself off, and, worse: activating the "I'm in danger mode" (5 power presses in succession) and counting down to calling 911.
I caught it and cancelled before it dialed, then turned off the phone. However, as you might guess, the phone turned itself back on!
Fortunately I was able to (with much aggravation and accidental swaps to the camera app), eventually get to settings and disable the feature.
My experience sitting in on 112 dispatchers as part of my EMS training was different. Multiple times per shift a caller would just start the conversation with something like “This is no emergency, I'm an employee of Vodafone/T-Mobile/etc and have to test 112”. Only network operators calling this way though, no phone manufacturers.
Phone manufacturers probably do use simulators for most of their test calls, but also nearly every emergency dispatch center will have several cell towers in their service area and very few have phone manufacturers or phone test facilities.
I have a friend who used to work on cell towers and he'd need to do a test call after certain types of maintenance, and might visit a few towers a day to do that work. On the other hand, a particular phone model probably only needs one or two live test calls per firmware release, so there's probably a lot fewer of those calls overall, even if you're at a dispatch center that serves an area including people testing phones.
Happens all the time with roaming and imported devices.
I’m not aware of any western provider saying “oh, that block of IMEIs aren’t allowed to connect to the network”.
Canadian government shadow-banned sales of a bunch of Xiaomi cell phones, but local providers have no issues authing them onto the network. Can’t say no to that juicy roaming revenue even if it means putting your network at risk.
US networks get cagey about certain phones. CDMA carriers were always restricive, but now that 2g and 3g are mostly shut down, they don't want to allow registration of LTE devices that don't do Voice over LTE with their network because it breaks the emergency service rules.
I don't think they'd block them from roaming if the device has a foreign network sim that's authorized to roam though. Of course, major US carriers basically don't allow their subscribers to roam to other major carriers.
Yes. I used to do this while contracting with Verizon.
When bringing up a new tower, we had a bazillion tests to run, and one of the very last was 911. When that day arrived, my supervisor would call the non-emergency line at the PSAP and check in; sometimes I was in the room for this call. Basically we'd make sure they weren't short-staffed, that they had capacity for the calls, etc. Just a formality.
When testing actually began, I'd simply tell the operator "This is not an emergency, I'm a tech with Verizon making a test call, do you have time to take this call?", and if they were bouncing off their limit, they'd say no, and I was done for the night.
If they said yes, I'd ask them to read back my E911 data. I'd transcribe what they said for later comparison against what was expected, and ask again if they figured they had time to take a few more in the coming minutes. If so, I'd move to the next sector on the tower, lather, rinse, repeat.
It was really quite straightforward, and sometimes I'd get the same operator over and over, they'd recognize my DN and just start rattling off coordinates. At the last call of the night we always made sure to thank them, but briefly, and that was that. My report would go back to the datafill engineer, and that was the last step before unlocking the tower for customer traffic.
I don’t know if cell carriers support it, but we test our PBX with 933. It functions like 911 but doesn’t route to emergency dispatch, instead it reads back out E911 data. I also don’t know if, for cell carriers, it functions enough like 911 that issues on the phone like reported here would be evident.
It used to be true that even when having an unlocked device here in Sweden, the operator actually tested and certified the updates, and I know this because updates used to be released at wildly different times between different operators. I assume this has stopped now that I read this, because I do get security updates straight away, and I get the feeling everyone does.
Sounds like you’re unhappy that people didn’t want the network to be responsible for checking against bugs. But would the opposite actually be fine? What about people who buy their phones from the manufacturers?
The problem with operators is not only that they often delayed fixing critical bugs for no good reason; they also liked to add maliceware. I remember a Nokia phone with one key dedicated to trick users into starting it by accident, which of course was billed.
Apple preventing network operators from breaking their software on purpose was a huge step forward.
Malware can do more damage than a broken 911. It depends on the circumstances.
It's not "life safety dangerous" to leave the house without a phone, and in almost all situations a complete lack of phone is more dangerous than a phone with broken 911.
> If you're logged out, launching Microsoft Teams 10 times will result in 10 duplicate PhoneAccounts from Teams clogging your phone. Teams shouldn't do this, and Microsoft's update stopped Teams from doing this, but a bunch of duplicate PhoneAccounts also shouldn't be enough to bring Android's phone system to its knees.
> Next bug: when picking a PhoneAccount to run the emergency call through, [...] it's possible for this to result in an integer overflow or underflow, and now the phone subsystem is going to crash.
> A third bug in this mess is that Microsoft Teams does not even register itself as an emergency call handler.
> An update is not arriving for the Pixel 6 yet. Google's newest flagship is going though a bit of an update crisis at the moment. The December 2021 update was pulled due to unrelated "mobile connectivity issues" (phone calls don't work). While Google scrambles to fix everything, the next Pixel 6 update with this 911 fix is due in "late January." Until then, it's normal to be on the November patch. Both of Google's "early January" and "late January" patch timelines seem incredibly slow for a bug that could cause users to literally die.
If the OP article is correct, then apparently this still hasn't actually been fixed yet.
And why the hell does Google/Android allow 3rd party emergency phone service handlers at all?
Something critical like 911 should have one handler. Heck, I’d argue the phone system shouldn’t be allowed to be overloaded by a 3rd party at all. That just sounds like a bowl of buggy spaghetti.
"The FCC requires that providers of interconnected VoIP telephone services using the Public Switched Telephone Network (PSTN) meet Enhanced 911 (E911) obligations. E911 systems automatically provide emergency service personnel with a 911 caller's call-back number and, in most cases, location information.
To reduce possible risks to public safety, the FCC requires interconnected VoIP providers to:
- Automatically provide 911 service to all customers as a standard, mandatory feature. VoIP providers may not allow customers to "opt-out" of 911 service.
"
From a user perspective, I think I’d expect one of two things on a cell-phone…
- Teams (or other 3rd party) isn’t allowed to make telephone calls. The phone provides this service. Teams can continue making voice “calls” to other Teams users, it just can’t initiate telephone calls via PSTN.
- Teams (or other 3rd party) is allowed to take over calling duties from base software. But, only one call handling system can be active at a time.
Personally, I’m not sure why I’d want multiple handlers, or even a single alternate handler, so I’d pick the first option. If I’m missing a common use case, I’d like to hear it.
Person is in an emergency, they pick up the closest device and dial 911.
That needs to go through, complete with location information.
The specific triggers for the rule were old-landline handsets plugged into VoIP boxes routing through carriers that didn't have E911 connections. A child would pick up the phone, dial 911, the other end wouldn't have the address, and the child wouldn't know it either.
This rule would appear to include _anything_ capable of making a call, including things that don't look like phones (tablets).
That is mixed with the desire for carriers (and others) to intercept long-distance and other calls (no signal, cheaper rates, etc).
Microsoft used to sell something which would automatically intercept and redirect calls to other private numbers off of the cell network. This allowed higher quality codecs and lower costs.
If the handset maker only supports 911 when there is a cell signal, then this runs afoul of the FCC rule. The handset could be used in a location with wifi (but no cell signal), and be used to make calls. Someone picks up that handset, tries to dial 911 and is denied.
Microsoft, since they're a VoIP provider, needs to deal with E911. Google, needs to be fault-tolerant in the 911 dialing path and have good fallbacks.
I understand that. But MS shouldn’t have to solve “route E911 on an Android phone”. Google has to solve that for the default dialer/call handler. I don’t understand why a call made from default Android would ever route back to MS Teams. All calling (at least for E911 and similar) should go through the default call handler via API. Or something like that. It sounds like Google has a really convoluted, error-prone implementation. I’m sure they had a good reason at the time, but looking in from the outside today, my first thought is “WTH were they thinking?”
The obvious prevalent use case is adding a business / work line via your company's VoIP provider to your personal handset (or a company one, for that matter). I'm sure this is very common, and I have both done and supported it at multiple employers. Personally I have also in the past used VoIP accounts for cheap long distance, but I maintain a cellular service for reliability with local calls.
Having this functionality integrate with the OS is much handier than the clunkiness of dealing with individual apps, and this idea of replaceable parts is a key advantage of Android in general.
Emergency calls probably warrant special care and maybe more rigid handling, I will grant, but there's no reason not to support this in general.
>And why the hell does Google/Android allow 3rd party emergency phone service handlers at all?
It doesn't, but the interaction of registering a bunch of 3rd party voip services interacts with the emergency call system in interesting ways, as explained in detail in the links Ars Technica article.
If I get this right, we have a $1+ trillion company not being able to build a basic functionality into their phones? (like "phone calls don't work" and the whole calling 911 issue). And, apparently, that was happening because of a shitty app built by another $1+ trillion company? In terms of innovation the US tech scene is toast with these dinosaurs.
When it’s a matter of life and death, like in this case, bugs shouldn’t just happen. If your sw product gets too complex so that you’re not able to control anymore of life-threatening bugs then you should make sure that said product gets rid of its complexity so that the engineers can have a better grasp of it.
If that still doesn’t happen then it’s a job for the regulators to step again because, again, this is a life and death situation.
I would love this, though there's very few entities in the world that seem to have this level of sovereign power - most regulatory agencies / governments don't seem to have the political will, drive, ambition, or simply ability to do something like this.
Let's say for the USA, the chair of the FCC (hahahahahahahahaahah) decided to do this, could they even? Isn't power dispersed enough to make this impossible? (immediately challenged by courts, or, unable to determine which regulatory agency in USA actually has authority to do this, etc?) Or say an American state, perhaps Texas, decides to protect its citizens by threatening to ban sales of google phones if they don't fix this bug tomorrow, and force a recall, would that be possible? I mean... via what mechanism could that even happen? A governor executive order immediately challenged by a local court or even the USA federal government? A state law, that gets vetoed? Etc.
This leaving aside the fact that Google can just do fat campaign donations to whoever can throw a monkeywrench into this kind of consumer protection action.
As much as the deregulatory agenda is ascendant, the FCC does have authority to regulate … wireless carriers and interstate commerce.
In particular, 47 USC 618(a)(6) provides an explicit right of mandamus if the FCC fails to act (I suppose this is mainly for venue). I’m not a lawyer but I’m pretty sure you could compel the FCC to, however indirectly, compel Google to act.
Suppose that the penalty for this was that you were forced to halt sales and offer a full refund to all purchasers the original price until your phones’ emergency function worked. I’d bet that Google would magically be able to repurpose some of their billions in profits to hiring some QA testers.
You can't do much about the stuff out there now, but you can make punishments so painful companies simply regulate themselves. It's all math to them - if the punishment is more expensive than doing it right the first time, it gets done right the first time, usually.
But you have to agree the state of MS Teams is an absolute shitshow. The quality is like it's put together by a bunch of guys coding on their spare time if they feel like it.
That would be a passion project. I find it hard to conceive of Teams as a passion project, except possibly by people who have a passion for hating the world.
Normally failures like this would be addressed through legislation. Perhaps a $10,000 fine per 911 call failure incident. With regulatory capture and half the voting population against regulation, this is unlikely to happen though.
Short of that, boycotts could be organized. Maybe a senior executive at T-Mobile loses their kid in a car accident because the 911 call didn't go through. So they decide to drop Google for 2 years or something.
More and more avenues that help common working people stand up to monopoly/duopoly, wealth inequality and other forms of power imbalance are being deemed political.
“With thousands of people using your phones, it'll be clear pretty quickly when something as crucial as 911 stops working. You shouldn't need tests for that.”
Of course it matters, why such a black and white statement? The assumption is that a well funded company should be able to finance a quality assurance team which fixes bugs the developers create
Market cap is not revenue. While Google and Microsoft do have a lot of revenue, saying "trillion dollar company" is a tacit suggestion they're sitting on a trillion dollar dragon hoard.
Their profitability compared to profits is a more logically consistent comparison. If they recognize a billion dollars in profit while shipping brain dead bugs it goes to demonstrate their lack of respect for customers.
Bugs like these can arise from using unsigned values as intermediate results in a computation. Just because the source and dest values are positive integers doesn't mean that results don't go briefly negative.
I'm all over the place with pocket computing devices and remain confused. I once has an iphone. Beautifully crafted, both inside and out, but so frustratingly locked down that I was desperate to leave it behind. They have progressively opened up the platform, but it always lags behind (I remember I couldn't access the cloud storage from anything other than a mac).
My favourite devices have been more alternative. E90 running symbian, which was fairly 'open' for its time - I could install any software, proper multitasking. The N900 also, full linux system, great phone. But then the apps I find useful, are often not available for that platform.
At the moment I'm on Pixel, which has been a good balance between being well supported, while still fairly open. I can sideload apps, run a linux distro in the form of termux. As a bonus the camera is great. I have to remind myself that while it might not quite compare to iphones in terms of refinement and hardware, I do at least have more freedom on the platform, and it's easy to take that for granted until you lose it.
I’m in a similar position. I used iPhone for years but after they started to remove important apps from AppStore I decided to move to pixel. UX is terrible and unpolished. Hardware is just bad. But I can sideload and that’s more important.
I'm aware. They've been declining on that front. Without the privacy selling point they're the worst of both worlds. No privacy, security that falls behind Pixel phones, and no freedom.
Ah yes... the yearly pixel/nexus emergency call bug. I would say it's a total shame for Google that they really have repeating probably life threatening bugs in their phones but they don't seem to care at all.
They've had this problem for at least a few years, dating all the way back to the OG Pixel 1. I filed an FCC complaint about it four years ago. Not much has changed.
I was a lifelong Android user, but after I heard about this, I purchased my first iPhone this year. Completely absurd that Google refuses to prioritize safety. While I am mad the bug happened (there should be a dedicated test suite for safety features) - I am furious that there is no stop-the-world escalation to get the problem resolved.
I hate so much about the Apple ecosystem, but screw Google. If it is not a KPI product promotion package, evidently it is not worth the time.
Oh come on. "No comment" is always what a company says in a situation like this, where saying anything else might hurt them in a future lawsuit. It doesn't mean they don't care, it means they have lawyers with the bare minimum level of competency.
I've seen statements that at least pretend like the company cares and the steps they are taking to deal with the issue.
Something along the lines of "the safety of our users is our highest priority and we are investigating these reports", no admissions, no legal risk, but they couldn't even do that much.
> "the safety of our users is our highest priority and we are investigating these reports", no admissions, no legal risk
That statement contains both admissions and legal risk! If they aren't actually investigating the reports (entirely possible), it's a lie. If they don't actually mark "safety" bugs p1 (almost certainly possible), it's a lie.
...which is why no comment looks so bad, because those are easy things that extremely should be happening. (Though "highest" priority shouldn't be taken so specifically.)
No comment is the worst way to avoid that risk, and should be looked down upon.
> “So this is what happens on my brand new $1,000 Google phone when I try to call 911.”
How old is this story? The news report is from 2 days ago, but surely in 2022 the person filming the TikTok video wouldn't call a Pixel 6 a "brand new $1,000 Google phone"?
Which leads to a different problem, because at least a few Android versions ago (or maybe even today?), the emergency call dialler didn't necessarily recognise all the different country-specific emergency numbers. E.g. in Germany the European standard of 112 is only natively used for fire brigade and ambulance, whereas the police's native emergency number is 110 – but you couldn't dial the latter from the lockscreen without unlocking your phone.
As an end user today with a Pixel 6, what am I supposed to do if I can't rely on them to get this right? I NEED 999 to work. If not for me, then the people around me. Am I supposed to go and ring 999 to test it after every major update until Google gives an actual statement on the condition of their shitty product that has failed the most important use-case? That doesn't scale and if nothing else, Google should understand a scaling problem...
> As an end user today with a Pixel 6, what am I supposed to do if I can't rely on them to get this right?
Buy a Pixel Watch! I’m sure emergency dialling won’t be broken on both the watch and phone at the same time!
But in seriousness, I personally just accept that cell phones aren’t a bulletproof way of accessing emergency services. At any point in time, my phone could be out of service, out of battery, dropped and broken, unconnected due to a network outage, etc. An emergency services bug is a qualitative difference, not a quantitative one. I qualitatively increase my odds of being able to access emergency services by running redundant systems - I have a VoIP landline, my partner has a cell phone with a different OS/mobile network than me, I carry a PLB if I’m in the wild. (I plan on getting an LTE-capable watch at some point - the Pixel Watch is quite unappealing for the price though.) (Will probably switch from PLB to sat messenger when the battery on this expires, which will double as an emergency service contact backup.)
Do you have any local emergency non-999 numbers? I have saved the numbers for the local emergency dispatch numbers for the cities around me, along with the non-emergency ones. This is also where directing specific people around you to call 999 (or calling on another person's phone) is a backup plan.
Well, I'm being pedantic but how do you know Google tracking never once failed? It could fail 50 times a day in strange circumstances but work just often enough to keep the approximate trail without you being aware. In fact, I'm nearly certain that just due to the ubiquity of Googles tracking, it's vastly more likely to break than the phone services. Now, each of these have very different meanings and severity and all concern is certainly warranted but if you do, I would be interested in how you're tracking google's tracking
The regulation problem is that the "Wireless Communications and
Public Safety Act of 1999", which requires carriers to support 911, predates smartphones with non-carrier software. There's Kari's Law, [1] which requires multi-line phone systems to support direct 911 (not 9-911, or diverting 911 calls to in house guards). That applied to the Microsoft Teams problem, where Microsoft Teams was capturing 911 calls but not connecting them if the user was not logged into Teams.
If the FCC went after Google on this, they could probably win claiming clear legislative intent to cover all the cases, and that a third party who insinuates themselves into the call chain has the same liability as the carrier. File a formal complaint with the FCC, and copy your elected representatives.
Is there any theory or explanation why this happens?
"Third party apps" is totally vague, what third party app could stop you from dialing an emergency number? And even if such apps exist (or even are common) is it not a huge design flaw by itself, which the manufacturer has to remedy?
Not sure why they don't say it by name but the bug was originally found with MS Teams.
"The issue is the result of an “unintended interaction” between Teams and Android, specifically when the users have the app installed but are not logged in to any account." [0]
Unless Teams is abusing private APIs or acting in other nefarious ways, this is 1000% a problem with Android itself. It shouldn’t be possible to break emergency service call operation through normal usage (or even naive usage) of the public APIs on the system. To blame Teams here is completely backwards.
I believe this is the result of two problems. One is the fact Teams registers phone service providers over and over again, the other is that Android didn't pick the right phone account for a while.
The Teams issue will cause generic connectivity issues because Teams says "I can call this number!" but then can't; the Android issue is an emergency issue because the Teams app shouldn't indicate the ability to call emergency services but Android tries to use Teams regardless. Even if Google fixes the 911 bug, users may still be unable to call if Microsoft hadn't fixed the registration issue.
Both problems should be fixed by now, but it's possible Google and Microsoft haven't updated every single device out there. It's also possible a different bug has shown up.
Allowing one app to register more than one phone service provider smells like an Android API bug. Allowing an unlimited number definitely is a bug. Allowing the corresponding integer to overflow and... well... do we really need to argue this point?
A phone OS should never have to rely on good app behavior to not collapse like a house of cards. Much less one made by a corporation with a 71% worldwide market share.
The OS was bugged. The method that fetches the phone service providers for emergency services returned a sorted list of all service providers. Had the necessary filters been in place, the index issue wouldn't even have become a problem.
The integer overflow issue was part of a very flawed last resort branch of a piece of sorting code. It did underflow, but the underflow happened in a piece of code that basically sorted two objects by their memory addresses at that point. There was no way to recover from that, the problem should've been caught way before instead.
It's awful that code this important is this buggy, but no code is entirely bug free and hard coding behaviour would only hard code the bug further. This is a problem that can only be solved with higher standards, better testing, and better code analysis tools.
I understand this, but there is still an architecture issue here:
It should not be possible for installed applications (even malicious ones) to prevent calling the emergency services using the cellular network
In the worst case it might try some other options first, but whatever is registered or set up the phone should use the SIM information to call on the network. The network operators have a load of regulation to meet (and special prioritisation of emergency call channels etc.) so why do the phone makers not?
Teams is a cause of this problem, but we're talking about it because it's a widely installed app. What other niche VoIP or similar applications are also causing this problem? The whole value we are sold of the restrictive "app" model is it is meant to protect the phone user from things the app might do.
I think we all agree it shouldn't. If I remember correctly, the code had special cases for emergency services just so this wouldn't happen.
That said, if I install a carrier's app on my tablet that enables calling and adds the necessary emergency services support, I don't see why it couldn't be used as the fallback for emergency services. Sometimes I have WiFi but no mobile signal (VoWiFi is finicky as hell) so if I need to reach emergency services, an "internal dialer only" approach would actually prevent me from getting help more than it solves the problem.
The code was buggy and not tested enough. Teams didn't specify that it could handle emergency calls. The method that sorts the apps that are capable of dealing with emergency phone numbers simply forgot to verify that the numbers in the list were all emergency capable: https://medium.com/@mmrahman123/how-a-bug-in-android-and-mic...
If I install a dialer, I expect it to be able to dial 112/999/911. I don't expect it to try to re/activate the vendor dialer I disabled, switch my system settings to give it its call permissions back, and call the number. Hell, with multiple dialers, this behaviour may even cause a loop by itself.
Bugs in the core framework can't be fixed by hardcoding specific dialers, you'll only hardcode the buggy, often barely updated dialers. Even after my phone goes EOL, I can fix problems like these by simply installing a better, fixed dialer, and that's a pretty good feature in my opinion.
That should really not be neccessary and potentially a user might want to use third party applications during an emergency call. (Imagine having saved the medication a relative receives on your device)
The OS has near complete authority over the device. If a user dials an emergency number android has to choose to give it to a third party app and that should never happen.
(I am also not sure that it would be a fix at all. From the description above it seems like android would try to start Teams, even if it was closed.)
I don't think this is newsworthy at this point. My Pixel 6 and Pixel 7 both are unreliable when trying to call 911, calling with an over the top app or dialing the PSAP's number directly are the only workarounds.
Google doesn't give a fuck about this issue. I have filed repeated support cases over the past year with Google about this when using T-Mobile or Verizon.
That makes little sense. "It's the users who are wrong" ideology applies when you tell the customers they are holding the iPhone 4 wrong. Or when you ask them whether they don't have phones when you reveal the next Diablo as mobile-only.
No company would argue that users are wrong and that they are not supposed to dial emergency services.
Club of Rome often lamented human overpopulation, so the user you’ve been replying to will undoubtedly share some far-fetched conspiracy theory that won’t make a lick of sense.
Most interesting is a user story[1] shared giving an idea of how often this happens: 3 times over 8 months, with ~5 calls a week. We could round it at around 1% error rate. It's both relatively low (as a chance it happens to you), and extremely high (I can't imagine how many people might have the issue and not be aware of it!).
I'm sure there are other conditions that aren't identified here, but this definitely warrants more regulatory scrutiny.
Google Pixel phones pose an unacceptable safety risk to vulnerable Americans. This product should be recalled and future Google phone products should be refused certification until they document and enact a plan to do QA. And no, “engineers write their own unit tests” does not count as QA for safety-critical software.
I luckily don’t own one, but if I did I’d be reporting it to every regulator I could find. https://www.saferproducts.gov/
I've seen many reports of this on Pixel phones but I experienced something very similar on another Android phone (it was either Moto G5 or OnePlus One): https://news.ycombinator.com/item?id=29494820
Most of the discussion here is related to 911-specific bugs in Pixel. But there's also generic cellular communications bugs, and based on what I see on Reddit it's widely experienced but not well understood. The symptom I see is nothing cellular works sometimes until I put the phone in airplane mode and back again. Networking software bug? Problem with the cellular tower? I have no idea. But it seems very common on Pixel 6. I probably won't buy another Google made phone because of it.
FYI memorizing 112 is probably a better idea. It's baked into GSM spec and gets redirected to the right country end-point (like 999 for UK) in most of the world.
Same difference while in UK, but good habit for travelling.
For my experience, when possible it's better to use the more direct number – that extra layer of redirection takes only a minute or two, but in an emergency that can be a lot.
Nah, I don't mean just the "please hold the line." But most of all redirection means that you need to explain the situation to two different operators before the response is sent.
Maybe this is a 'straw man', but this is what I refer to when I say I prefer iPhones for their reliability and stability, or at least what I perceive to be more reliable than most android phones. The closest issue I can recall on iPhone was that issue where saying some nonsense to siri caused an erroneous dialing of 911.
I get it, this is sorta a one off thing, but it irks me when super basic functionality of the phone is unstable, such as making a literal phone call.
i'm REALLY surprised that this is still a problem, especially after the last 911 fiasco (the one where Teams was preventing users from dialing 911 due to call routing)
it feels like android in general has had issues with 911/112. i remember cyanogenmod ROMs (when that was a thing) having issues as well.
I used to be REALLY into modding / jailbreaking / rooting / installing custom ROMs on android phones, until I witnessed a car accident, tried to call 911 on my iirc galaxy s3, only for it to crash. Luckily my friend was able to call, but I tried again a couple times later and sure enough, dialing 911 on whatever ROM I had simply crashed the phone.
As much as I miss having root on my phone, I'm never taking the risk again. Being able to use payment features is a nice extra plus I guess.
I actually had another emergency-call-related bug a few days ago on my Pixel 5 after accidentally triggering the SOS call feature.
My device got stuck in a reboot loop -- it would reach the colored google "G" logo in the startup process, then reboot again. Every handful of cycles, it would reach the lock screen, attempt to start an emergency call, then reboot again.
I had to get my device to the debug fastboot screen just to kill the loop
I have a Pixel 6 running GrapheneOS, and the one time I called 112 in the Netherlands it worked. Hard to extrapolate from that one data point though.
It's a bit of a bother that this is not something you can test at any reasonable scale. “Just testing if my call gets through” is not something you want to see inundating emergency call centres.
It's a side effect of that Android version letting apps register to take over calling functions (for, e.g., VOIP purposes). If any such app on the phone doesn't handle the emergency call case correctly, then the attempt fails in one way or another.
I had a Samsung 5G Exynos and when one time I couldn't call 112 (emergency number in Europe). Tried over and over. Even restarted my phone but the phone line was silent when it answered.
I owned a Pixel 1, a Pixel 2... and now a Pixel 6. Pixel 6 is by far the worst. It is extremely low quality and the screen has broken twice in a year just sitting in my pocket. It runs slowly and has frequent bugs. Garbage phone.
> I contacted Glynn County emergency services about Macleod’s 911 issue. The county said it “did not find any record of these calls registering in our system during the time in question” despite Macleod’s phone log showing she called 911.
I was under the impression that (successful) 911 calls aren't recorded in the call log.
As a 6 Pro user, even if you could get ahold of 911 your signal may just drop out entirely in the middle of your call. I've never had a phone that drops signal so often. It's insane. I used the Black Friday sales to get a new phone to replace this one for that reason specifically.
Since this has apparently been happening for multiple years, and is a safety issue, why don't the authorities order a product recall? 100% refund for every pixel phone seems reasonable, and Google has that sort of cash laying around anyway.
I had the opposite problem with an iPhone last week: it called 911 all by itself. I was in a different room so I didn't hear any warnings. Instead, I heard the "It's the police! Open up!" accompanied by banging on the door around midnight.
Since I had recently washed the phone (it's supposed to be water-resistant), my theory is that some water got into it and was completing the contact for the side button. There's an iPhone 'feature' that does an emergency SOS if you hold down the side button for about 10 seconds. I've since turned that feature off. Unfortunately the "side button being constantly held down" problem is persisting for me, sending the phone into recovery mode whenever it turns on; I may need to scrap the phone.
In these United States, there are now two emergency numbers which can be dialed: 911 and 988, for mental health crises.
The last time I removed the SIM from my Android phone, I tested 988; unsurprisingly I was not able to contact the service because the phone denied access.
If your phone doesn't recognize 988 as a bona fide, legitimate emergency number, it's time to request a firmware update. 988 has been years in the making, and firmware developers should have made it a priority to put it on the whitelist.
I must qualify this by pointing out that I have mixed feelings about the 988 line.
It streamlines the hospital pipeline for committing people who are DTS/DTO (5150) status, and let me tell you, that is an easy status to earn or gain.
The hospitals profit immensely from admitting mental patients in a way that jails and police don't profit from locking up people who act crazy.
Every time there is a mass shooting in these United States, the Legislature swoops in and throws more cash-money at mental health programs. Therefore more mass shootings will tangibly "improve" your mental health care (if improvement is gained from larger budgets) and the more insurance money available, the more crazies they can lock up and the longer they can hold you in the hospital "just to make sure" you're responding well to treatment and that you'll be a permanent customer after your release.
So call 988 at your own peril, because the mental health system is a roach motel for many of us. Welcome to the Hotel California.
It's not a network problem. It's a side effect of that Android version letting apps register to take over calling functions (for, e.g., VOIP purposes), when then makes emergency calls fail if any of the apps that have registered that functionality don't handle it properly.
Thanks for the clarification. I had no idea Android apps could intercept calling functions like that. I can see the benefits, but I’m amazed devices are allowed to be that open
Do you mean users install apps that are buggy, and this is somehow Androids fault? At the same time, if Android wouldn't allow VoIP apps, it would be somehow at fault again ?
It's absolutely Android's fault that it allows a buggy app to interfere with emergency calls, and Google agrees, given that in later Android versions they tore out the code that allowed anything but OS handling for emergency calls placed through the default phone app.
There is no reasonable way a normal user could suspect that buying a phone from one of the biggest companies in the world (Google) and installing a very common application from another huge company (Microsoft) will result in their phone no longer being able to dial the emergency number.
This is most definitely Google's fault for allowing emergency calls to be overridden and not having a fallback if the override fails.
Most custom versions of Android (in this context, non-Pixel phones) have actually hardcoded that all emergency calls (especially in lock screens) be routed into a different, lightweight, for-emergency-only dialer. Google has known about this but didn't do anything to also provide a hardcoded override.
Edit: and apparently recent Android versions, but I can't confirm that.
911 generally does perform their job well. Your issue is with the police and is valid, but there are many other public services an operator will route to you (ambulance, firefighter...)
Let's just spell it out instead of this clickbait title:
Dialing the local emergency number (112, 000, and 911 were reported, but presumably also others) sometimes doesn't work, just gives a click instead of dialing. Google blames third party apps. Users report similar issues since Pixel 4 that were reported to Google but haven't been resolved since release.
Not like "911 doesn't ring" is much longer of a title than "very scary issue with dialing 911". It just sounds ever so slightly less like a horror movie.
I'm not going to suggest third parties can't screw with a phone and make it effectively unusable, but why isn't emergency calling a separate code path in the dialler app and OS that just ignores everything that third parties have done? It should be impossible to change the behaviour of that small bit of the phone. Don't fire any OS level events, don't call any callbacks, ignore any registered intents.
This is on a Pixel. Google can have complete control of the OS and dialler if they want to. They should be able to effectively isolate this from the rest of the phone. Blaming third parties doesn't really explain it.
> Next bug: when picking a PhoneAccount to run the emergency call through, Android goes through a complicated sorting process to figure out which account to use. The last step in this sort process, the tiebreaker, is sorting by hashcode. The hashcode comparison just subtracts one hashcode from the other. But just like that stupid Y2K22 Microsoft Exchange bug from the other day, it's possible for this to result in an integer overflow or underflow, and now the phone subsystem is going to crash.
This is horrifying and stupid and horrifyingly stupid.
I didn't mean for it to sound as though I thought this was a legitimate reason absolving Google of blame. I cited it as a lame excuse, exactly for the reason you mentioned: this should be a core system thing, not influenceable by third parties.
Nothing about your explanation refutes that this is a very scary issue.
Third-party apps or not, a phone that can't call emergency services in every situation other than empty battery should be treated by the government like food that can potentially poison people.
> Nothing about your explanation refutes that this is a very scary issue.
That's great, because I didn't want to say that!
The point is that "something very scary happened" is less useful than "X happened" when everyone intuitively understands that situation X is very scary.
> Third-party apps or not,
Maybe that's another misunderstanding: I think Google's excuse is lame. Perhaps you thought I cited it as a legitimate reason?
"911 doesn't ring sometimes" in this context means that there's good signal and can call non-emergency numbers using ordinary phone networks, but for some reason can't handle emergency calls correctly (and yes, you could call the GSM-wise non-emergency but legally-wise long emergency number for your area normally, it's just you're more likely to not know it in an actual emergency). That's not just "scary", it's a life-threatening defect similar to a faulty airbag (where you don't need it now but it must work in an emergency).
Indeed, the phone has a life-threatening defect and I would never own one. "Failure to dial 911" is a scary defect for a phone.
Where the title makes a logical mistake and is misleading in order to be sensational is that, assuming "dialing 911" as given context, "phone doesn't ring sometimes" is probably the least scary issue possible. In fact, it's the most common way dialing a number can go wrong. It's easy to imagine countless worse things that will radically worsen your outcomes in a life or death situation (such as: phone bricking itself, phone exploding in your hands, phone becoming subsequently unable to make any call, phone making loud noise that alerts the attacker that you are making a 911 call, so on so forth).
Perhaps for a native speaker it's not as obvious that "'very scary' issue dialing 911" here is a semantically illogical construct, but I assure you it is. Example of one that isn't: "'very scary' issue with a Pixel phone involving 911 calls".
First, this article is targeted to the general population, not to anal-retentive HN commenters. You're nitpicking on technicalities which while tolerated on posts by HN users (although heavily discouraged unless it's of a technical nature) is definitely out for general articles. Even the guidelines are clear about this: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
Second, the Note 7 exploding is also scary, but to the average population (in the US anyway) a phone that bulges and physically explodes is as dangerous as not being to reliably summon emergency services.
I merely clarified what the downvoted comment's author meant so that those who reflexively started to argue with it would see they are actually in agreement on substance if they gave it any thought. Talk about generous interpretation and anal reflexiveness.
> a phone that bulges and physically explodes is as dangerous as not being to reliably summon emergency services.
If you are putting forth that a phone exploding when you make a 911 call is an issue of the same magnitude as a phone occasionally not ringing when you make a 911 call, I don't see what else we can discuss...
As I tried to explain, the title is misrepresenting reality in the direction of exaggeration. Which is probably the definition of clickbait, so the original commenter is not wrong.
I don't think there's a reason to pursue this but I can't see how this is too far.
I wrote:
> title implies "911 doesn't ring sometimes" ∈ "very scary issue dialing 911", that is incorrect
to summarize why the downvoted comment said the title is clickbait. (As in, it’s a scary issue with the phone, but if we limit to the domain of issues when dialing 911 then 'not ringing sometimes' is not scary, it's mundane.)
And it is wrong to insist that "scary" must be interpreted relative to that domain. Being scary in the domain of phone use, then noting the specific time it occurs, is fine.
And you didn't just say it could mislead, you called it illogical, and that's not right. You're being pedantic about a rule you made up.
But "something very scary happened" as a headline is less useful than "X happened" when everyone intuitively understands that situation X is very scary.
Clickbait is where you have to click through for the essential-but-omitted information, written in a way that makes you want to know. This is that. It doesn't mean it's not also accurate.
Frankly, that this situation happened at all is outrageous and certifying bodies should take steps to ensure it's no longer possible for it to happen.
The solution is to mandate that emergency numbers be hardwired into phones and thus their operation could not be overwritten by any software whether it be the phone's operating system or any user app.
Moreover, it would make sense for all phones, irrespective of country of origin, to include emergency numbers from all countries, i.e: 911, 112, 000 and any others I'm not aware of. Moreover, all emergency numbers should work—that is no matter what emergency number is dialed it still should connect to the local emergency number.
This is important because tourists/travelers in a different country may be unaware of the emergency number for the country they are visiting. Whilst roaming, the phone would recognize its location by actual location and the carrier its connected to and it would dial the correct number even when the user dials his/her home emergency number.
This is not just a nice hypothetical, there have been multiple instances of US citizens visiting Australia where I am and dialing 911 in an emergency and failing to connect with the local one. Here, as in Europe, the mobile number is 112 and the landline one 000.
Why this wasn't a part of the original ITU 'G' roaming specs is anyone's guess but it's an obvious and very dumb omission.
We'd test, send a report back, wait a few weeks, get a new firmware, test again, repeat until everything worked. It took months. That was fine when phones weren't expected to be updated by users.
But when more modern phones arrived with flashable firmware, customers couldn't stand the delays associated with testing. They'd see a new firmware had been released and complained that the mobile network operators were delaying progress, dragging our feet, deliberately depriving customers of something cool.
The fact was, operators very often didn't certify the firmware because it contained *dangerous* bugs. I'm sure there was also a cost element - why pay to re-test a phone that you're no longer selling? - but that wasn't the primary driver.
Well, the manufacturers and customers "won". If you buy a phone through your network, it probably has a network-certified firmware blob. If not, you're at the mercy of the manufacturer.