Distinguish Android onDestroy events

Question

I'll start by saying that I've seen the Activity Lifecycle diagram (http://developer.android.com/reference/android/app/Activity.html) and actually I thouht that I understand it perfectly.

How I andestood it is that if there is an onDestroy event, then there is no coming back and the activity is definitely in a process of being shut down.

All the others that involve the ability to show the activity again are between onCreate and onStop (both inclusive).

I am creating an application that polls a custom bluetooth device for some measurements result. I want the connection (Bluetooth) to be kept, but I also want to discover if the user kills the activity (from the taskbar by killing the application) so I can send one more thing to the device and disconnect the socket. So by what I understood, I can just put the code in onDestroy. It turned out however (Sony Xperia Z3 and Samsung Galaxy S2) that onDestroy is also being executed when the user clicks the power button, thus locking the screen. When the screen is unlocked, a new Activity (that is my guess) is created and onCreate is run. And as You can guess - my device is disconnected because of the code i put to onDestroy

Normal automatic screen off + lock does not do onDestroy...

So the point is: Is there a way to distinguish the onDestroy that really destroys the activity, and the onDestroy that will recreate the same activity afterwards when the user unlocks the screen? I want just to react to this really-really onDestroy event

Answer 1

Yes there is a way to distinguish onDestroy that destroys your activity:

@Override
protected void onDestroy() {
    super.onDestroy();
    if (isFinishing()) {
        // Bye-bye
    } else {
        // I'll be back
    }
}

Answer 2

Just to point out - onDestroy() is not an 'event' it's a method which is called by the system when the Activity is going through the destruction phase of its lifecycle.

As for onDestroy() NOT being called as a result of automatic screen off is simply because the Activity currently being shown is stopped and not destroyed - as a result, onPause() and onStop() will be called and that's it. When the device is unlocked, the Activity is restarted and resumed (onRestart(...), onStart() and onResume() are called.

If the two devices you mention are causing different behaviour to other mainstream devices then this is obviously an example of non-standard implementations (certainly nothing new there when it comes to Samsung who have repeatedly done non-standard things with their devices).

I'd recommend you create your own base Activity and add logging to it in order to track what exactly is happening. Example...

public class MyBaseActivity extends Activity {

    protected final String TAG = this.getClass().getName();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.d(TAG, "Entering onCreate(...)");
    }

    // Override all of the lifecycle methods and add a
    // single line to log entering the method as above.
    // Don't add any other code except the call to the
    // super methods if mandatory.
}

All you need to do from then on is to always extend your base Activity whenever you add an Activity to your app and always make sure to call through to super.<method-name> from any of the lifecycle methods you override.

If you find what you suspect really is true for the devices you mention it seems your only real choice is to handle of the Bluetooth stuff in a Service rather than in an Activity.