Can't say I like the tone of this article. Google is trying to do something good it is not in any way obligated to do. Painting this like they were responsible just encourages people not to try such things.
There's an old blog article about "PETA problems", maybe? Can't remember the name. The premise is that if you mention a problem or help in a small way, then people blame you for not fixing it completely. Google saves people from earthquakes... BUT NOT EVERYONE!!! How could they???
No good deed goes unpunished. The challenging sensor data quality (random handheld devices from various vendors placed in random environments) means that the detection algorithm can only be calibrated with real data, aka real earthquakes.
"...sets off a loud alarm on a user's phone - overriding a Do Not Disturb setting - and covering their screen"
I'm already at war with my smartphone to make all the alerts stop buzzing and squelch the intrusive notifications (e.g. apps that think they're important, amber alerts that seem in most cases to be accidentally blanketed due to user-error, test alerts, false alarms, etc).
I'm fine if Google wants to experiment with it, and I even applaud the effort, but at the end of the day I want control of my device, thank you very much. That means this sort of thing should be opt-in, not foisted upon on me.
IMO this is the most interesting part:
Postevent analysis revealed several limitations to the detection algorithms that have since been improved. First, the duration of monitoring has increased. At the time of the event, the algorithm only allowed updates to earthquake parameters for 10 s after first detection. The number of allowed updates was limited because there was a trade-off between more updates providing additional information for larger earthquakes and more updates introducing outlying single-epic data causing a large overalert. We now allow updates for 30 s and use other checks on the rate of variation in earthquake parameters before updating an alert. Second, there were a large number of noisy phones in the monitoring pool at the time of the Türkiye earthquakes. These high-noise phones triggered late, particularly after the P wave for the M 7.8 event, which had a slow start and complex rupture (31–34). The AEA system is now more selective about which phones are included in the monitoring pool. Individual phones determine their noise level when they become available for monitoring, and this noise level is factored into the detection algorithm. Third, many phones were receiving a BeAware alert and vibrating, which prevented them from triggering on the earthquake ground motion. The alerts now issued by Android EEW no longer cause phones that are detecting to vibrate.
Android was successful in detecting and warning during the 23rd April 2025 Istanbul earthquake. Probably they made some fine-tuning on their algorithm.
Why doesn’t Google invest in relay communications that doesn’t rely on a central server, like some on HN have done? One developer here had a really good implementation.
15 comments
[ 3.9 ms ] story [ 31.4 ms ] threadThat's amazing. How incredibly encouraging for the future.
Android Earthquake Alerts: A global system for early warning
https://news.ycombinator.com/item?id=44651092
But I wouldn’t have guessed that over 50,000 people were killed by that earthquake.
"...sets off a loud alarm on a user's phone - overriding a Do Not Disturb setting - and covering their screen"
I'm already at war with my smartphone to make all the alerts stop buzzing and squelch the intrusive notifications (e.g. apps that think they're important, amber alerts that seem in most cases to be accidentally blanketed due to user-error, test alerts, false alarms, etc).
I'm fine if Google wants to experiment with it, and I even applaud the effort, but at the end of the day I want control of my device, thank you very much. That means this sort of thing should be opt-in, not foisted upon on me.
IMO this is the most interesting part: Postevent analysis revealed several limitations to the detection algorithms that have since been improved. First, the duration of monitoring has increased. At the time of the event, the algorithm only allowed updates to earthquake parameters for 10 s after first detection. The number of allowed updates was limited because there was a trade-off between more updates providing additional information for larger earthquakes and more updates introducing outlying single-epic data causing a large overalert. We now allow updates for 30 s and use other checks on the rate of variation in earthquake parameters before updating an alert. Second, there were a large number of noisy phones in the monitoring pool at the time of the Türkiye earthquakes. These high-noise phones triggered late, particularly after the P wave for the M 7.8 event, which had a slow start and complex rupture (31–34). The AEA system is now more selective about which phones are included in the monitoring pool. Individual phones determine their noise level when they become available for monitoring, and this noise level is factored into the detection algorithm. Third, many phones were receiving a BeAware alert and vibrating, which prevented them from triggering on the earthquake ground motion. The alerts now issued by Android EEW no longer cause phones that are detecting to vibrate.
Why doesn’t Google invest in relay communications that doesn’t rely on a central server, like some on HN have done? One developer here had a really good implementation.
Not sure if Google is reinventing the wheel here?