Develop Reference

Guaranteed alternative to onDestroy()?

I'm trying to execute some code whenever my activity is killed, but not when it's simply moved to the background (so just calling it in onPause() isn't a solution), and I understand onDestory() is not guaranteed to be called. I've been searching all over and haven't found a way to do this. How can I go about tackling this problem? Is it possible?

Nothing. You can never be guarantied to be called when an app ends, because it can always be terminated abnormally- it could crash, the battery could be pulled out, etc. onDestroy is the closest you can come. But you should never write a program that requires cleanup at termination time.

I'm not sure, but I suspect you've got a few issues which you've conflated into one large issue;
As I read this question you have 2 or 3 concerns:
1) You want to garuntee something happens when the app exits.
2) You have state you want to maintain during onPause() but not after onDestroy()
3) You presumably have some content which should not persist between application usages.
Some answers:
1) As Gabe points out - there is no guarantee anything will ever be called. I can pop the back off the device and pull out the battery. Your calls aren't going to happen.
2) You might try onDestroyView() for this case. It won't be called in many circumstances in which onPause will be (for example when an alert dialog is shown), but will be called in others (when you replace a fragment with another fragment for example).
3) This issue makes me think you may want to reconsider your method of storing/saving this information. If you don't want it to exist on the system when you app isn't in use, it is best to never write the data to the filesystem. (Due to 1). Other options are keeping it in memory. You could also use shared preferences/preferences mechanism but this will still exist on the filesystem until your app is removed.

Stopping the activity from recreating when resumed

I got two activities. When I jump from first to second activity and then come back to first one, the activity gets recreated in some phones. Can anyone tell me how to prevent it?

I don't believe you can prevent it. If you have some state to save, consider saving it. If you need things to keep running in the background, consider using a Service.

You can't stop the recreating from an App, but you can save your state in onSaveInstanceState(Bundle) and retrieve the state in onCreate(Bundle) or onRestoreInstanceState(Bundle).

It's the intended behaviour, and you shouldn't be trying to stop it. But, as mentioned by gnobal, you will need to save the state, and recreate your data to handle these situations properly.
Some phones with low memory, will always do that. A good way to test your implementation is to go to "Developer options" and enable "Don't keep activities".

Is it important to use savedInstanceState and onSaveInstanceState?

I have an application which only supports portrait mode. I'm passing all my arguments using serialization, passing by means of intents - intent.putExtra() ant then in onCreate() - getIntent().getExtras().getX(MY_PARAM_NAME)...
This works even when the system shuts down the VM, because of crashes related to other things. The activities seem to be started again with the correct parameters thanks to serialization.
So the question is, is save instance state necessary in my case? It seems to work well without it... didn't get any problems yet. But maybe I'm missing something, or didn't test enough.

As you've pointed out, if your Activity gets killed off (i.e. due to low resources), when it is recreated, it is passed the original Intent that started it. In your case, that means you get your serialized objects back.
Overriding onSaveInstanceState is important for the scenario where something has changed during the execution of your Activity (that hasn't been persisted elsewhere) that you would like to maintain in case it gets killed off.
For example, storing member variables in your Activity is dangerous for when the Activity is killed and recreated, unless you store them in the Bundle in onSaveInstanceState, and then restore them from the Bundle passed to onCreate.
Update: A great way to test the need for implementing that method is to force Android to kill your activities as soon as you leave them. Then, run your app and see if there are any problems. You can do this with the Dev Tools App on an emulator, or in ICS by going to Settings -> Developer options, and checking "Don't keep activities".

onSaveInstanceState() and onRestoreInstanceState() are only explicitly called by Android when the Activity needs to be recreated, generally after a configuration change (ex. changing orientation).

How to understand android activity is launched directly or first killed- then recreated?

As you all knows all android activities create, start, resume, run, pause, stop, destroy. This process is shown well in the android manual.
In this lifecycle is there any possiblity to understand activity is created which way? I mean how can I understand whether activity is called directly or activity is created once then killed by android os and then recreated since user navigates back?
More basically how can I understand whether an activity is in its second life or first life?
Edit: Why do I need this?
In my design I have a main page where the data is loaded from the net. And when the user clicks some details, it puts the data in a static object just like session in web. This works well normally.
But when a user starts detail activity in second life, he data in static object is killed, and I got nullpointer exception.
I have 4 projects having same architecture so I want to solve this problem.

You've already got the flow chart information there. You can always keep some state for later use by storing the fact of your Activity's demise during onDestory() or similar. Then, the next time your Activity is resumed, you will know if you were actually destroyed or just stopped. I don't think you get any of that information for free from the OS, since it's not supposed to matter in the ideal case.

you should not distinguish between these, since even after it has been destroyed (at least the method has been called) it might "come back" just in the state as it was when it was destroyed. Which could be different than from the very initial state when it was created the first time.
Please explain the reason why you need this - you should "rethink" your issue, since Android is really behaving "strange" concering this question.
It is better to design your project livecycle according to Android system behaviour - which is actually not documented anywhere regarding this point (at least I have not come accross any good doc so far)

If I understand your question, you want to know when your activity has been destroyed by the OS or when it has only been paused. Simply use logcat statements:
onPause() {
super.onPause();
Log.v("Activity", "Paused");
}
onDestory() {
super.onDestroy();
Log.v("Activity", "Destroyed");
}
You can do the same for onCreate(), onResume(), anything really.

Android destroy activity with finish() in onPause()

I dont think putting finish() in onPause() is cutting it.
I have a Location activity and it is proving very hard to test, what I would like to do is be able to, when I leave the activity, completely destroy/kill any existence of it. So that when I go back, both when I leave the app or just the activity, everything is new, there is no cache, nothing and it has to start all over again.
The reason being is I don’t want it to remember Last Know Locations, they are not useful in this app, all I want is the current location and if it can’t be found, it can’t be found.
Cheers,
Mike.

This gets into some deep discussions about how android manages activities and memory and all kinds of things which you probably don't want to think about.
If you are currently trying to finish the activity in your onPause method (sounds like a horrible idea to me since your phone will call this whenver your screen goes to sleep -- after about 15 seconds of inactivity depending on your settings). But if that really is what you want to do then why not just make the call to get the last known location in your onResume method?

Put finish in onPause and in manifest add this for that activity android:stateNotNeeded="true"
so it want remember your last state on relaunch of that activity

For solving this problem you can use preferences for storing the data and you can use it for future.