Android Question Background runing issues with targetSdkVersion 28

[vikingivesterled]

There is a problem with background jobs when converting to targetSdkVersion28 and running on a Samsung S10e with Android version 9.
Apps that runs fine in the background under targetSdkVersion 26 stops nearly immediately with 28.
This happens within a couple of minutes from you select the phone's main screen using the home button.
No better if you put the screen to off with the power button.

Logs shows messages like:

** Service (servicetimer3) Destroy **
** Service (starter) Destroy (ignored)**
** Service (httputils2service) Destroy **

Is there something special with the starter service since the Destroy of that is ignored.

Tried the lock.PartialLock but it just ignores it.
Restarting the servicetimer3 service via a timer in the starter service just leads to it being destroyed again in seconds.
It is not a navigation app but one that uses mediaplayer to play a timetelling tune every halve hour, or every minute in Demo mode, utilizing a timer in the servicetimer3 service to change the tunes and get the playtime exact.

And now from August you have to submit updates to Google Play with targetSdkVersion 28
This is becoming like on iphone's where I have to bypass its unwillingness to let stuff run in the background by scheduling notifications.

 

[Erel]

This is the expected behavior with Android 8+.

Your app will be stopped if there is no foreground service.

Example: https://www.b4x.com/android/forum/threads/99873/#content

 

[vikingivesterled]

That is a serious step back in functionality and Android's advantage over iOs.
Scheduling a logger for jogging to activate only every 10 seconds is close to uselss missing corners and speed changes.
And having the screen on all the time is a battery drain.

But why is the Destroy of the starter service ignored?
And would it work if I moved all functionality from the service servicteimer3 to the service called starter. Or is there a limit to what the starter service can do.

 

[Erel]

Scheduling a logger for jogging to activate only every 10 seconds is close to uselss missing corners and speed changes.

You don't need to schedule anything. You need to have a foreground service.

And having the screen on all the time is a battery drain.

You don't need to keep the screen on. You do need to acquire a partial wake lock to prevent the device from sleeping.

But why is the Destroy of the starter service ignored?

It is not related to background functionality.

And would it work if I moved all functionality from the service servicteimer3 to the service called starter. Or is there a limit to what the starter service can do.

It will not help. The app will be killed if there is no foreground service.

 

[vikingivesterled]

I have now implemented the foreground service from the sample and it runs nicely in the background.
However it is creating a tag with the number 1 on the app's icon. Like a new notification counter when you have notifications implemented. But they disappear normally when you open an app. Here it don't.
I see the B4A-Bridge have the same "1" notification constantly on its icon and I assume it is for the same reason. It seems impossible to get writh of that one also.
I will se if I can implement some dummy notification removal in the app because it does look flawed with the "1" displaying on the icon constantlly.

A related question is with what SDK version did this foreground service to run in background become necessary.
I am just doing some layout changes for the newer phones (I will take up the AutoScale issues between different screens height to width ratios in a different post) and I want to keep the older version of the app going for older phones, so will need a minimum version where this changed backgrond behaviour started.
I so far had my apps on targetSDKversion 26 but I see that the Samsung S10e Android 9 phone isn't running the apps well in the background with that either.

 

[KMatle]

It's all about Google's policy. Running apps in the background without knowledge of the user is seen as dangerous. Another point is energy saving.

See wakelock to improve the behaviour. This prevents the device going to (deep)sleep which stops the app. See your energy settings, too. On some phones apps must be allowed to continue when screen is off.

 

[vikingivesterled]

There is no point in releasing apps to Google Play that requires special settings changes, like for energy savings. Potential users will just install it, determine it don't work, mark a low review you can't reply to, uninstall it and move on. Nobody ever asks why or looks for additional instruction on what it takes to use it, unless you have a previous direct relationship with them.

I see DonManfred's comment in other post that says the "1" on the badge is a notification of a running foreground service and is impossible to get writh off.

 

[vikingivesterled]

If you schedule a just in case restart of a service with:
StartServiceAt(Me, DateTime.Now + 30 * DateTime.TicksPerMinute, True)
Is there a way of cancelling the scheduled restart without it resulting in stopping the service immediatley like with StopService(Me).

 

[Erel]

CancelScheduledService(Me) 'or YourService instead of Me