[numpad0]

LTE ETWS/PWS is mandatory feature, iPhones has the same thing. Maybe you've explicitly disabled it, considering (IIUC) US used it for AMBER alerts and had annoyed lots of people at some point.

Generally an earthquake warnings are issued by someone always automatically correlating sensors everywhere, USGS and/or NOAA in case with US, and then cellular carriers broadcasting the alert through LTE feature. This does not work without participating local equivalent of USGS deploying a sensor network and running its computers wired to carriers.

This feature is carrier agnostic, enabled by default, and mandatory on phones; it's specifically designed to deliver earthquake early warnings. It does not matter if it's Android, iOS, or something else altogether. Any phones, SIM locked or unlocked, with or without SIM, should start blaring the alert so long it hears the signal.

ref: https://en.wikipedia.org/wiki/Cell_Broadcast

[kccqzy]

I think OP is describing a different feature. It's not a carrier feature like Amber alerts but an OS feature. Google documents this feature here: https://crisisresponse.google/android-alerts/ I'm fairly certain this is due to some Android-specific code inside GMSCore. It has nothing to do with carriers.

On iOS you have no such thing and you either rely on the carrier alert (there won't always be one) or install an earthquake alert app such as MyShake.

[Rebelgecko]

The wireless emergency alerts (like what you see for amber alerts) that go over cell towers have pretty high latency (IIRC on the order of a minute or two for the alert to disseminate). The native Android earthquake alerts are much faster

[numpad0]

Carrier alerts is the fastest. Not only the whole process from detecting tremors to alerts take 30 seconds or so, there aren't other data sources than what those carriers use anyway, so there's just no way Google can be faster than carriers.

PWS is also a broadcast, meaning the phones don't have to wait for cellular timeslots, so it's faster and bandwidth efficient in that regard too.

[jcrawfordor]

Unfortunately the architecture of IPAWS can introduce fairly long delays. The EEWS system uses a dedicated channel to deliver alerts to WEA more quickly, since a study by USGS/NIST had determined that IPAWS could not meet time objectives (typically ~5 minutes end to end). The tsunami warning center, like basically everyone except for USGS, has to originate alerts through IPAWS. The performance and latency problems with IPAWS have been flagged by GAO a couple of times now but it's not something that receives much investment. All-Hazards Radio (weather radio) should actually be a faster alerting mechanism for tsunamis, in practice, since NOAA operates that system themselves.

The Android Alerts are actually coming off of IPAWS as well, but I believe they take a feed directly from the publishing system and do all of the routing themselves. Their implementation is of course quite a bit faster than IPAWS rather creaky and sort of batch-centric architecture.

[Bratmon]

Android alerts got there way before carrier alerts today.

Reality doesn't care what you think should be the fastest.

[Melatonic]

When I was on Android the integrated Google system was always much faster than anything else

[int0x29]

I got shake alert via google play services. I have amber alerts on. I have gotten earthquake alerts over WEA in the past. I did not get one this time. I am pretty sure one was not issued for the 6.9 magnitude quake just the tsunami

[mgsouth]

For folks jumping on saying "that's not a carrier thing". All comms are a carrier thing. Whether it's ETWS, SMS, or IP, it's going through the carrier, they process it, and they do extensive traffic management. Carriers absolutely can and will inspect, proxy, aggregate, and do anything else that will tease out another few % of "free" capacity.

[Edit:] All too real scenario: Carrier knows about particular IP addresses and ports used by alert service. Carrier makes provision for separate path for it. Carrier also tries to shave said provisioning to the bone, calculates a worst-case, and adds 5% capacity. Which doesn't get updated when that particular app gets a 6% boost in subscriptions. Back in the old days the traffic management folks would be on top if it, but that's all been outsourced...

[sib]

In this case, there is a separate service that Google developed for early warning.

(Source, worked at Google in Android team.)

[numpad0]

PWS is tower based broadcast. Everyone within range of a tower gets the alert. Data source is supposed to be local government weather authority, I think USGS and NOAA in US. Or the Meteorological Agency in Japan.

You can do a location-based two way warning system and there are such services, but it's going to be laggy and won't scale to 100M+ simultaneous subscribers. One-way broadcast scales to the planet if wanted.