Android Studio – Set callback in intent BACKGROUND Location Android Studio Java

This is the official documentation about services – there are a few sections on the side. It’s worth reading because it does pretty much cover everything.

I don’t think you want a foreground service. The terminology is a bit confusing, but a foreground service is one that still runs when the user isn’t interacting with the app, like a music player. (There’s more info in the Foreground services section of those docs.)

It’s foreground because the service is basically elevated from a background thing, and becomes a foreground component that will keep the app’s process running, on the same level as an Activity. The difference is you can see an Activity, but you don’t necessarily know that a foreground Service is running. That’s why Android puts a bunch of restrictions on foreground services, including requiring you to display a permanent notification while it’s running. That’s why you have to call startForeground to put a Service in the foreground, and why you have to pass a Notification when you do it.

So let’s assume you don’t want a foreground service – you shouldn’t run one unless you need to. If your Service only runs while the user is interacting with your app (and maybe keeps going a little while the app is in the background your app and its background services won’t be killed immediately) then just a plain service is fine.

There’s two ways to run a Service – call startService or bind to it with bindService. startService makes it run until you call stopService. bindService adds to the count of clients bound to the service – if it’s not already running it will start, and it’ll keep running until all the clients unbind from it.

These two systems work together to keep the service running. If you’ve called startService and all the clients unbind, it will still run because it’s been explicitly started, until you call stopService. If you call stopService but clients are still bound, the service will still run. So you might find it more useful to use both of these methods, instead of just one, to keep the service running.

Generally speaking, if you want access to the running Service you want to bind to it. Here’s the documentation for that, but the basic idea is the Service creates an IBinder object with a bunch of methods and variables that interact with that running instance, and when something binds to the service, it gets that Binder object and has access to the service through those methods. Or if you like, you could just put a bunch of public methods on the Service and stick a reference to the service instance in the Binder, like in the documentation example:

class LocalService : Service() {
    // Binder given to clients
    private val binder = LocalBinder()

    inner class LocalBinder : Binder() {
        // Return this instance of LocalService so clients can call public methods
        fun getService(): LocalService = this@LocalService
    }

    override fun onBind(intent: Intent): IBinder {
        return binder
    }
}

So basically, you can access the running service by binding to it, and you receive an object that has a reference to that service.

Using startService is more like telling the service to run and do its thing, like an independent component you don’t directly interact with. It’s possible for a started service to e.g. interact with some application-level variables, like a global var or something that an Activity or whatever can also look at, but that’s limited and often hacky. Using a bound service is the way you’re meant to do it.

I’ve skimmed over some of the stuff (like the boilerplate you need to bind to a service) but that’s all in the docs – once you know what you want their example code is a good place to start building from!