Android Question Significant motion sensor intent for receiver

certain service behavior is out. check @Erel's famous "background tracking" example:

you need a foreground service to replace part of what you were doing before. once you start such a service, it keeps running.

drgottjr said:

certain service behavior is out. check @Erel's famous "background tracking" example:

Background location tracking

Simple example of a foreground service that keeps the process running in the background. The current location is shown in the persistent notification. The app starts at boot and theoretically should run all the time. It also schedules itself to run with StartServiceAt. This can help in cases...

www.b4x.com

you need a foreground service to replace part of what you were doing before. once you start such a service, it keeps running.

Click to expand...

Agreed - this is essentially what I did before as a night-time seismometer, and is now Plan B.

Plan A is to see if I can use the "significant motion sensor" to start a receiver which sends out a message. Problems are 1) is the significant motion sensor sufficiently sensitive, and 2) how do I make an intent-filter that starts the receiver whenever the significant motion sensor is triggered? If it works this plan would use less power and cpu time than Plan B. It would also work during day time whenever a phone is at rest.

your initial post was somewhat misleading. to accomplish what you now describe as your goal you need to write a listener.
that, in itself, isn't technically difficult, but it helps if you are familiar with how sensors behave and what their output
values mean and what threshold, if any, needs to be reached. i'm guessing you are familiar, so you can
probably get chatgpt to draw up a template that makes sense to you. i know there are examples of sensor
listener code out there. it doesn't have to be a "library" per se; inline java would work. depending on the example,
with small tweaks, it could almost be plug and play. you would run it with a javaobject. development time would
be faster with inline java. a library is more tidy but involves (not unbearable) extra steps. inline java could always
be converted to library format after bugs were dispatched.

a forum member apparently developed such a listener:
but he has not visited the forum for a number of years (perhaps after making lots of money with his listener).
he would have presumably known if such a listener were sufficiently sensitive.

your thread is still in the early stages; someone else may stumble across it. hang tight.

one other thing that needs looking into: the significant_motion sensor appears to be connected to a wake_alarm, which implies some kind of timer in place (that is, something scheduled to happen at a particular time). this kind of thing defeats the purpose of a sensor. in other words, your earthquake - tiny or otherwise - would have to wait until your listener was supposed to wake up to report it. good luck with that. this is all part of google's battery saver scheme. smartphones aren't really designed for scientific measurements. and android has an issue with background ops that get in the way of power saving, and it's tricky negociating the ever-changing restrictions. my feeling is your plan b still works, and if i were me, i'd stay with it.

Thanks drgottjr for the suggestions, which prompted me to look again. Now I've found Erel's Physical Activity Recognition Detection library which does in principle what I'm after. I'll see if I can modify it to detect exits from the "STILL" activity state.. ?

for some background: https://www.androidauthority.com/using-the-activity-recognition-api-829339/
(assuming you can find the actual article cleverly buried behind all the pop-up ads). note the reference pointing right back to significant_motion.

Thanks again drgottjr - the article gives a more easily understood perspective on activity recognition than Erel's library or the Google docs. I think my problem will be to modify Erel's library to provide a snapshot of activity every minute or so to detect a change. I'll have to test the update rate against battery and cpu use.

I've also clarified the problem. I already know the time of any earthquake from a notification received from the observatory within a minute of the event. The problem is to determine whether the phone moved as a result of the earthquake and, if yes, send the approximate location of the phone as a notification to other users.

My app therefore needs to receive intents from the activity recognition api and store the times of any changes from still to not-still in a moving buffer of about 5 events in a kvs. Then, when an earthquake notification is received, my app can check the buffer for any corresponding movement events. Issues for testing will be sensitivity and battery use....

i think the still activity is where there will be a problem. for it to work, you would have to rest the phone at the edge of a table in which position some movement of the phone would make it fall. the key is the phone's righting itself at some point from a supine position. my understanding is that horizontal movement wouldn't count.

do you know who rube goldberg was? google some of his inventions. i can imagine your phone sitting horizontally atop a tower overlooking the village. when the earthquake knocks the phone off the tower, it falls into a bucket whose loud sound awakens a certain villager whose job it is to bang a drum to warn the villagers to flee the area.

update: for what it's worth, i grabbed my phone (which was sleeping or dozing or whatever google calls it when the screen has turned itself off and the phone is just lying there) and while trying to keep it relatively horizontal, i shooked it as hard as i could for a few seconds. nothing. then i simply righted it, and the screen came on immediately. and, by the way, if you "upside down right" a phone, it won't wake.

Thanks for your help drgottjr but I think I've reached a dead end. The activity recognition api is an interpretative layer above raw accelerometer data. It analyses movement patterns and and a small bump from an earthquake is not one of the recognized patterns. As for the accelerometer data we can no longer start long-running services from background, so my app will not be able to automatically start a 10-hour seismometer service at bed-time... I am foiled.

John calvin said:

Using the significant motion sensor to detect small earthquakes might be challenging due to its sensitivity threshold and potential false positives. However, you could experiment with triggering a receiver with the sensor and then implementing logic in the receiver to filter out irrelevant movements before sending notifications to your server.

Click to expand...

Agreed - I have previously used a long-running service to monitor the accelerator data and it was possible for my phone to detect a light finger tap on the desk it was lying on. However as we can no longer start a service from background I can't automatically start this service when a phone is plugged in and charging (and therefore still) and my app is in background. A receiver with the same purpose would be killed after a few seconds.

Given there is no relevant intent available it would be useful if the OS kept a buffer of the last 100 seconds of accelerator values that a receiver could check whenever my app received a notification of an earthquake. This would determine whether the phone moved as a result of the earthquake. However I haven't yet figured out a way to do this...

However as we can no longer start a service from background

Click to expand...

you don't start the service from background. you start it from foreground (aka, erel's famous tracking example). a receiver, if you had one, can invoke an already running service. otherwise, you need an alarm or a scheduler.

i thought it was clear from our exchanges that erel's example still works, but you don't want to use it due to battery concerns. if you're concerned about warning people in potentially life or death situations, buy another device and keep it plugged in.

drgottjr said:

you don't start the service from background. you start it from foreground (aka, erel's famous tracking example). a receiver, if you had one, can invoke an already running service. otherwise, you need an alarm or a scheduler.

i thought it was clear from our exchanges that erel's example still works, but you don't want to use it due to battery concerns. if you're concerned about warning people in potentially life or death situations, buy another device and keep it plugged in.

Click to expand...

Yes - I think you're correct. All I need to do is start a service when the app is opened which logs the last 100 seconds of accelerometer data, which keeps going when the app is closed or in background (and, if required, re-start when the app is next opened). When an earthquake notification comes in (about 60 seconds after the event) this log can be checked to see if the phone felt the earthquake. Presumably simply logging the accelerometer values in a kvs will use less power than continually processing the data to see if an earthquake has occurred (actually it will only record the data when plugged in and still, other times the data will be read and ignored..).

My purpose is to map the area where an earthquake has been felt rather than try to reproduce the monitoring function of the local seismic observatory. Next step is test and see..

i do not understand your fixation with the battery - or perhaps it's just my fixation - given the purpose of your monitoring. but, it is what it is.
the foreground service (which essentially doesn't have to do anything on start-up) is the ticket. that and a receiver which can call subs in the service or which can restart itself should get you a nice long-running app, battery status notwithstanding...
(i had such a foreground service/receiver running happily, but at some point i realized i could do what i wanted in the receiver alone. originally, though, the receiver called subs in an already long-running foreground service.
in your case the trick is getting a system broadcast to trigger the receiver. there is a battery-saving one relating to setting an alarm while the device is "dozing". it's called "setExactAndAllowWhileIdle". erel posted a nice little sub. plug that into the search box. i've used it. it's one of the few avenues android opened to allow alarms while saving battery (for those who might be interested in that sort of thing).

drgottjr said:

i do not understand your fixation with the battery - or perhaps it's just my fixation - given the purpose of your monitoring. but, it is what it is.
the foreground service (which essentially doesn't have to do anything on start-up) is the ticket. that and a receiver which can call subs in the service or which can restart itself should get you a nice long-running app, battery status notwithstanding...
(i had such a foreground service/receiver running happily, but at some point i realized i could do what i wanted in the receiver alone. originally, though, the receiver called subs in an already long-running foreground service.
in your case the trick is getting a system broadcast to trigger the receiver. there is a battery-saving one relating to setting an alarm while the device is "dozing". it's called "setExactAndAllowWhileIdle". erel posted a nice little sub. plug that into the search box. i've used it. it's one of the few avenues android opened to allow alarms while saving battery (for those who might be interested in that sort of thing).

Click to expand...

I've now got the foreground service running which logs the last 80 seconds of accelerometer values. Battery is one issue but mainly I was hoping to make the earthquake-felt monitor as unobtrusive and forgettable as possible to maintain the widest possible map coverage before users delete the app. For better or worse that's no longer possible (e.g. icon will always be visible) and I'll probably need an option for users to stop the monitor service if they prefer.

I already have a receiver which responds to incoming Firebase messages which contain earthquake time and location. I'll modify it to access the public log from the foreground service to determine whether the log shows phone movement at the time of the earthquake. If yes then I'll have another point on the felt-area map..

this might knock your phone off the table.