Foreground service vs WorkManager for location tracking

Question

Let's say I want to build an app which requests current location periodically (e.g., every 10 minutes, this number should be configurable) and submits to a server.

I'm aware that Foreground Service and WorkManager are normally suggested for this kind of scenario. However which is would suit more? Below are my thoughts and doubts.

1. WorkManager - is mainly for deferrable background work whose execution is guaranteed. However I know that from Android 8 (API 26) background location was introduced and that restrict location to be updated only a few times every hour https://developer.android.com/about/versions/oreo/background-location-limits. Thus this perhaps doesn't meet the periodical updates as per the requirement.

2. ForegroundService - is perfect for something that runs and needs to make users aware of. It's recommended for this kinda scenario (location tracking) for privacy purpose. Google also creates a sample app to promote this practice https://github.com/android/location-samples/tree/master/LocationUpdatesForegroundService.

From the above analysis, it seems ForegroundService is the one. However I also found that WorkManager has a built-in support to use Worker in conjunction with ForegroundService via androidx.work.impl.foreground.SystemForegroundService https://developer.android.com/topic/libraries/architecture/workmanager/advanced/long-running#long-running-kotlin

That makes me confused as to what should I use and what Google really recommend for this specific scenario.

Anyone has any idea?

Mayfield

Would you mind sharing what you decided on? – Selma

Answer 1

If you want to communicate somehow with the service then use foreground service and if you want to have some processed input based on something else you did in that work manager then choose work manager.

Work manager doesn't have option to redeliver intents and all other commands like start sticky etc...

Since work manager is more suitable for syncing data with db, processing a file etc..

If you were to ask me, I'd choose foreground service since you can add a type location to the xml tag when you register it in the manifest.

Both of these solutions don't survive OEMs aggressive battery restrictions since WorkManager's work can be deferred and if I want instant execution combined with wake locks I can easily do it in the foreground service since it also has a binder option that works well for UI sync.

Classless

Hi there, Would you mind sharing what your suggestion would be if it's a requirement that, if the OS kills the process sending the periodic location updates to the server, an update is also sent to the server to notify that this has happened, i.e the location updates will no longer be received. I'm thinking that foreground services have higher priority so, yes this is the best way to maintain the location update process, but how would I notify the server if the OS kills the foreground service. – Selma

The best way to check this is, keep sending location updates periodically to the server and have a flag hasEnded, if that's always false and the backend detects that you haven't made a call in 30seconds it should send a push notification where you check if the foreground service is killed and ping the API – Classless

Hi there, thanks for the suggestion. I was hoping there would be some kind of onDestroy event fired when foreground service is killed. – Selma

Late response, but for new guys with the same question, you can implement that in on overridden taskRemoved function. Called once the foreground service is killed – Robertroberta

If you target the latest android API there is an issue with foreground services: medium.com/@manish_bannur/…. Seems they are left for a few cases, others use cases should use Coroutines or WorkManager – Loss