Android Question How to keep apps running that use StartServiceAt in a loop

[JackKirk]

This is more of an open discussion than a solution.

According to this thread StartServiceAt uses the Android AlarmManager to do its tricks.

While googling Android AlarmManager I came across this hit which I found most interesting:

https://stackoverflow.com/questions/34729966/alarmmanager-not-working-in-several-devices

Basically the discussion revolves around how some phone manufacturers add "power/battery saving" apps that pay no attention to AlarmManager settings and kill apps as they please.

I have looked at the 2 android phones I use to run apps that use StartServiceAt in Service_Start to create a continuously running app and found both of them had "power/battery saver" apps and both were set to destroy my continuously running apps at some point.

I have now reconfigured the "power/battery saver" apps to leave my apps alone.

I will report back in this thread what the ultimate effect is.

One other thing that came out of the interesting hit was the suggestion of Android devices running "vanilla Android" - i.e. with out battery savers.

Does anyone know of such a "vanilla" device?

 

[JohnC]

You could display a quick message when a new user starts your app for the first time telling them that if they have any problems with your app not running reliably, they should visit "donotkillmyapp.com" for suggestions on how to disable the power savings for your app on various different devices:

Don’t kill my app!

Hey Android vendors, don’t kill my app!

dontkillmyapp.com

 

[JackKirk]

JohnC - that looks like a great resource and reinforces what I have come across - thanks.

Fortunately both my apps are not customer facing - they are solely for my own use - they handle aspects of a large AWS-centric project.

 

[JohnC]

Do your apps need to run on your personal phone or can they run on a separate dedicated phone?

If they can run on a dedicated device, then you might be able to use wake lock to keep the phone/screen on all the time and have the device powered continuously by connecting it to an adapter 24/7. This might increase the reliability of scheduled events.

 

[JackKirk]

Do your apps need to run on your personal phone or can they run on a separate dedicated phone?

If they can run on a dedicated device, then you might be able to use wake lock to keep the phone/screen on all the time and have the device powered continuously by connecting it to an adapter 24/7.

1 app runs on a dedicated Android device and is configured and powered as you suggest. I have had fewer failures with this one for fairly obvious reasons (now) but when it does fail it is more of a problem because it runs unattended.

The other app runs on my personal Android and therefor is competing with everything else. This one has historically failed more frequently but because it is attended has been less of an issue.

I have a mechanism in the AWS project that monitors to ensure stuff it has sent to these apps is read by the apps in a timely fashion - if it isn't read in this timely fashion then the AWS monitors issue an SMS alert. Of course if this fails...

 

[JohnC]

The app that can run on a dedicated device could instead be installed on one of those Android Boxes that don't use a battery, so you could connect it to a hardware watchdog timer that would reboot the android box if it doesn't get a heartbeat from your dedicated app. So that should take care of that part of the equation.

As far as suggestions for the app that runs on your personal phone, I would need some more info on:
1) How often does it need to run
2) Why does it need to run on time
3) What will happen it if doesn't run on time

 

[JackKirk]

The app that can run on a dedicated device could instead be installed on one of those Android Boxes that don't use a battery, so you could connect it to a hardware watchdog timer that would reboot the android box if it doesn't get a heartbeat from your dedicated app. So that should take care of that part of the equation.

That is a possibility but this project is likely to be installed in multiple places so I'd like to see if I can get it to run stably on an off the shelf Android phone.

As far as suggestions for the app that runs on your personal phone, I would need some more info on:
1) How often does it need to run
2) Why does it need to run on time
3) What will happen it if doesn't run on time

The app that runs on my personal phone receives various alerts and diagnostics on what is going on in the AWS project.

1. It runs every 60 seconds - I could blow this out but 60 seconds seems to work well - it doesn't generate much Internet traffic.

2. It doesn't need to run on time - +60 secs would not be an issue.

3. If it does not run on time (within above limitations) then the significance would depend on the severity of the alert - worse case scenario is customers could lose content (photos and videos) that they would otherwise get - but if they never knew they could get it? - a lengthy outage would be obvious though.

 

[JohnC]

Well, if you can get the dedicated device to run reliably, then you could configure it to send recurring push messages to the app running on your device as mentioned in one of your first posts:

Service/StartServiceAt reliability - advice sought

Hi, I have a couple of B4A v10.7 apps that use services with StartServiceAt to periodically check for certain changes in AWS S3 files. They work pretty reliably on my Samsung S5 and I have a SMS alert mechanism for when they do fail. I would like to find some way to improve their reliability...

www.b4x.com

Phones are pretty reliable in waking up to a push/sms message, so that might work.

Otherwise, I am out of suggestions to increase the reliability of scheduled tasks on your portable device.

 

[JackKirk]

On the subject of push notifications I reiterate what I said in the thread you point to:

Push notifications are more reliable.

I looked at this mechanism before I wrote these apps but came to the conclusion that the extra complexity of additional accounts and 3rd party servers - which need to be maintained, documented and explained to users - was too much.

I was looking for the simplest possible solution within the "AWS bubble" I have to work in - and came up with simple periodic polling - not as elegant probably but way simpler.

The only real issue is the annoyance of the odd failure of the StartServiceAt mechanism - which the SMS alert mechanism provides a workaround for - and which I was hoping to improve by raising the question in post #1.

Otherwise, I am out of suggestions to increase the reliability of scheduled tasks on your portable device.

Thanks for your thoughts - they have increased my confidence that managing the host phone's "power/battery saving" shenanigans may be the answer.

Only time will tell...

 

[JohnC]

I actually have not written an app that uses push notification, but from what I understand, it's not that difficult and only requires doing a post to a specific URL.

I am also confused because you said "Fortunately both my apps are not customer facing", but then you also just said "[need to be] documented and explained to users".

My impression is that this is not a mass-market app that wouldn't even be offered in the playstore and will have a low user count, but it sounds like my understanding might be wrong.

 

[JackKirk]

I actually have not written an app that uses push notification, but from what I understand, it's not that difficult and only requires doing a post to a specific URL.

If I recall correctly you have to have an account with the push service and you have to send stuff to another server for the push to be executed - another account, another server in the loop - all requiring documentation, maintenance and explanation.

I am also confused because you said "Fortunately both my apps are not customer facing", but then you also just said "[need to be] documented and explained to users".

My impression is that this is not a mass-market app that wouldn't even be offered in the playstore and will have a low user count, but it sounds like my understanding might be wrong.

Sorry for the confusion, the apps I am referring to are not customer facing if the customer is defined as an ordinary end user. However it is possible in the future that I will have customers for the AWS project (and hence using these apps).

 

[JohnC]

My last suggestion is to maybe look a little more into using firebase to send push notifications - I think it can be a part of your google developer account (and won't need a third-party account) and it might be easier to implement then you think.

 

[JackKirk]

My last suggestion is to maybe look a little more into using firebase to send push notifications - I think it can be a part of your google developer account (and won't need a third-party account) and it might be easier to implement then you think.

This is true re accounts and implementation is not really the issue - it still involves another server that has to be relied upon both for uptime and long-term consistency - particularly when it is a "free" service (check the number of products and services that google has canned over the years at https://killedbygoogle.com/ - I was particularly galled by what they did to the programming interface to Google Earth). I think fewer moving parts is better.

 

[wes58]

Be aware of changes in Android 12 - and more restrictions by Google - https://developer.android.com/about/versions/12/foreground-services

 

[JackKirk]

Be aware of changes in Android 12 - and more restrictions by Google - https://developer.android.com/about/versions/12/foreground-services

This seems important and probably needs the StartServiceAt writer (presumably Erel) to comment.

 

[Erel]

1. StartServiceAt will not help you if you need to do something every 30 seconds. The minimum interval is 15 minutes or 30 minutes.
2. StartServiceAt will not help too much if you want your app to run in the background.

The only way to do it is demonstrated in the background location example.
As you wrote, it will not work on all devices.

StartServiceAt will be indeed more restricted when targetSdkVersion 31 is required, however it isn't too useful for most cases right now.

 

[JackKirk]

1. StartServiceAt will not help you if you need to do something every 30 seconds. The minimum interval is 15 minutes or 30 minutes.

Erel I have had 2 apps using StartServiceAt one is running on 60sec loop on Android 6.0.1 the other on 30sec loop on Android 7.0 - they fail every so often but the failure interval is in the weeks.

2. StartServiceAt will not help too much if you want your app to run in the background.

The Android 6.0.1 app runs in the background and issues notifications when it finds something - this is my everyday personal phone.

The only way to do it is demonstrated in the background location example.

I used the guts of https://www.b4x.com/android/forum/threads/background-location-tracking.99873/#content for my apps - only with 30/60 seconds instead of 30 minutes.

As you wrote, it will not work on all devices.

The gist of what I think I wrote in this thread is that it is most likely failing on some devices because they have "power/battery saver" apps that kill it - I'm hoping by reconfiguring these that my apps will run indefinitely.

StartServiceAt will be indeed more restricted when targetSdkVersion 31 is required

Questions:
1. why do you say that it won't work properly at short intervals (I should note that I don't need exactly 30/60seconds, I just need averaging 30/60seconds)
2. what is the suggested approach when targetSdkVersion 31 is required

Thanks...

 

[Erel]

1. StartServiceAt is not accurate by definition. StartServiceAtExact will be more accurate.
2. Android 6 is quite old now. Test it on newer versions.
3. I didn't find a documented minimum interval, though from my experience with tenth of similar questions, the minimum interval should be 15 minutes+.
4. The suggested approach in all versions is demonstrated in the example -> use a foreground service.

 

[OliverA]

3. I didn't find a documented minimum interval, though from my experience with tenth of similar questions, the minimum interval should be 15 minutes+.

15 minutes is mentioned here (https://developer.android.com/reference/android/app/AlarmManager):

These alarms can significantly impact the power use of the device when idle (and thus cause significant battery blame to the app scheduling them), so they should be used with care. To reduce abuse, there are restrictions on how frequently these alarms will go off for a particular application. Under normal system operation, it will not dispatch these alarms more than about every minute (at which point every such pending alarm is dispatched); when in low-power idle modes this duration may be significantly longer, such as 15 minutes.

 

[JackKirk]

15 minutes is mentioned here (https://developer.android.com/reference/android/app/AlarmManager):

If you read that web page carefully it is saying that 1 minute is fine in normal system operation but may be delayed 15 odd minutes when in low power mode.

That is totally different to saying you should not set the interval to less than 15 mins.