android - if service onDestory() is not guaranteed to be called, where should I release/remove listeners etc?

Question

So, I have a service which its onDestory() looks like this:

@Override
public void onDestroy() {
    super.onDestroy();
    stopLocationUpdates();
    googleApiClient.disconnect();
    Foreground.get(this).removeListener(this);
    // Here I have some code which sets shared preferences values
    phoneDataManager.markLastLocation();
    toastHandler.post(new Runnable() {

        @Override
        public void run() {
            Toast.makeText(getApplicationContext(), "service onDestroy", Toast.LENGTH_SHORT).show();
        }
    });
}

As you can see, I have a lot going on in here (disconnecting and stopping location updates, do some changes in SQLite database, and set some SharedPreferences values.

From what I read, onDestory is not guaranteed to be called. one scenario what I saw that it doesn't get called is -

Running the service -> closing application (removing from app list) -> I bring service to the foreground using service.startForeground(1, notification); , Notification is showing -> clicking notification action which fires a BroadcastReceiver :

public class ServiceShutDownReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {
        Intent serviceIntent = new Intent(context.getApplicationContext(), LocationService.class);
        context.stopService(serviceIntent);
    }

}

The context.stopService(serviceIntent); should call onDestory but it doesn't get called -> so all the code in onDestory wasn't executed.

What is the best practice for this problem? Ideally I want to have a piece of code that is guaranteed to be called when service is stopped.

Answer 1

In general you should not be concerned about situations where onDestroy() is not called because this means that the System is forcefully and immediately destroying the service (and all of its associated resources and local variables, kept in memory).

It is recommended to always put here the code that releases persistent handlers like MediaPlayer, BroadcastReceiver, GPS location updates, etc. This is good practice and will handle 90% of the situations where the service is gracefully stopped.

However, if you want to implement some custom "last minute checks", you are right that this method may never be called by the system and this code will never get executed. Your development strategy should follow this pattern and should not depend on this since there is no other reliable way of knowing when a Service is about to be destroyed.

As a last resort, you can listen for the Application::onLowMemory() callback, which is triggered when the System is low on memory and is close to starting killing processes, but even this is not 100% guaranteed.