Hi Kevin, thanks for the correction and your reply. I've read the other thread you mentioned, and honestly, it might work well for another type of project. The problem is that the polling interval becomes the alert latency and more fundamentally, the polling loop itself needs the process to be awake, which is where that thread ended up too: there's no wake path for it. The key is anticipating the S-wave by a few seconds, so if the data arrives even a minute late, it's useless for an alert system. I understand the power argument, but I think it's worth mentioning something that might change the math: the mode I'm asking for only runs while the device is stationary and charging. At that point the frequent-wakeup cost lands on a phone sitting on a nightstand, plugged in. That profile doesn't really look like the location category anymore. And this isn't theoretical, Android has been running this exact pattern for years, at two levels actually. Google's own Earthquake Alerts System works OS-level on charging, stationary phones: thresholding on device, only trigger events go up. And independent of that, third parties like Earthquake Network have done the same thing through a plain foreground service, sensor access with a persistent notification, restricted to charging. Years in production, and the charging constraint keeps the cost where it belongs. So the question of whether a mode like this is viable already has an empirical answer. For what it's worth, that same thread you linked ended with FB24300192 asking for a user-authorized, condition-triggered CoreMotion wake, my FB24275258 is essentially the narrow life-safety version of the same gap. Last Monday made the gap very visible here. The M7.4 earthquake in Colombia on August 10: Android users got a warning up to ~30 seconds before the shaking, iPhones stayed silent (no government EEW infrastructure here, and Apple's Enhanced Safety Alerts only cover a few regions). It was all over the local press, literally headlines asking "why did Android warn me and my iPhone didn't". The hardware in those iPhones was sitting right there, charging on nightstands. I'm not expecting any of this to exist today, and I get that the entitlement route is a long shot. Honestly if Apple solved it at the OS level like Google did, that would be an even better outcome than my FB. Mostly I want the case on record: narrow scope, power-neutral by construction, and a very recent real-world event showing what it's worth. Thanks again for taking the time.

Update: I’ve filed this as an enhancement request — FB24275258 — asking for a purpose-scoped entitlement for background accelerometer access limited to seismic detection, with on-device thresholds and only trigger events leaving the device. Still interested in whether there’s a supported approach today that I’ve missed.