Develop Reference

My activity invokes onCreate() before onResume()

I am new to Android, but after studying the Activity Lifecycle, I understood that if I minimise the app, it should call onPause(), and while I reopen it should call onResume(). But, in my case, it calls onCreate() first and then onResume(). This is causing my widgets and other variables to enter wrong state.
My app only has an activity.
Why is the onCreate() method being invoked before onResume()?

It is possible that the app process is killed by the system either from onPause() or onStop() to create room in memory for other apps in the foreground, in which case when you reopen the activity, it will be created. In that case onCreate() -> onStart() -> onResume() is the expected sequence. When the activity is no longer visible, onStop() will be called, so when you navigate back to the activity onStart() -> onResume() is what takes place.
More on activity lifecycle here.
Additionally, since Android 10 there are some restriction of apps running from background. And "an app running a foreground service is considered to be running in the background" which is what you are describing. That may be why it is destroyed and app lifecycle starts from onCreate()

If I understand the issue correctly, it sounds like you're receiving a new instance of your Activity when you're looking to resume it instead. You can change how Activities are handled by setting their launch mode.
To resume an Activity if it already exists you could change its launchMode value in your Manifest to something like this:
<activity
android:name=".MySingleInstanceActivity"
android:launchMode="singleTask" />
There are several launch modes available and there may be one that's better suited for your project. You can read more about tasks and launch modes at https://developer.android.com/guide/components/activities/tasks-and-back-stack#TaskLaunchModes.

activity finishes itself but onDestroy() call for this activity happen so late

I found a bug in our code that we are launching the activity(let's call this as SCREEN_ACTIVITY) by
Intent intent = new Intent(SharedIntents.INTENT_SCREEN);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
Android documentation : When using FLAG_ACTIVITY_NEW_TASK, if a task is already running for the activity you are now starting, then a new activity will not be started; instead, the current task will simply be brought to the front of the screen with the state it was last in.
So everything works fine in most of the case.
That screen activity will call finish() when user click something. Also this screen activity will get launch or create by incoming event from the service.
6053 I/ScreenActivity(15395): onCreate
6682 E/ScreenActivity(15395): finish() Activity
6832 I/ScreenActivity(15395): onDestroy
7284 I/ScreenActivity(15395): onCreate
7911 E/ScreenActivity(15395): finish() Activity
8063 I/ScreenActivity(15395): onDestroy
10555 I/ScreenActivity(15395): onCreate
13413 E/ScreenActivity(15395): finish() Activity
13701 I/ScreenActivity(15395): onCreate
13799 I/ScreenActivity(15395): onDestroy
The last one is the issue. ScreenActivity is created and then call finish() itself. But the problem is that onDestroy is being called very late. Before that there is incoming event from the server and calling startActivity() trigger a new ScreenAcitivty onCreate(). The problem is that ScreenManager class keeps flags for that activity created and destroyed.
The flag is set when onCreate() callback and onDestroy() callback.
So for line 10555 and 13701 the ScreenManager set createFlag = true. for line 13799 set createFlag = false.
The event comes after line 13799 will assume that the activity is not created and events are not notified to the activity.
Hope my description for the issue is clear to you.
Is this kind of scenario onStop() and onDestroy() call so late after calling finish() is expected to happen? If yes, i have to think about the solution.
If not, then is there any places to modify?
Thanks a lot.

onDestroy() may or may not be called. You cannot rely on it being called all the time. From the docs:
Note: do not count on this method being called as a place for saving
data! For example, if an activity is editing data in a content
provider, those edits should be committed in either onPause() or
onSaveInstanceState(Bundle), not here. This method is usually
implemented to free resources like threads that are associated with an
activity, so that a destroyed activity does not leave such things
around while the rest of its application is still running. There are
situations where the system will simply kill the activity's hosting
process without calling this method (or any others) in it, so it
should not be used to do things that are intended to remain around
after the process goes away.
If you need to know that your Activity is finishing, a reliable way to know if it is finishing is the isFinishing() method. You can call it in onPause() to find out if this pause will eventually lead to this Activity being destroyed:
#Override
protected void onPause() {
super.onPause();
if (isFinishing()) {
// Here you can be sure the Activity will be destroyed eventually
}
}

use Handler,
new Handler().postDelayed(new Runnable() {
#Override
public void run()
//enter code here for open an Activity
}
},300);
after that, we are getting log should be:
onCreate
onStop
onDestroy
onCreate

fragments, when am i "active"?

i've been constantly frustrated by this and i can't find a good answer, so hoping someone here can offer guidance.
i have a fragment that uses AsyncTask quite extensively. i'm constantly plagued by bugs where the fragment calls getActivity(), which returns null. i assume these are happening because some method in the fragment are invoked before the activity is attached, or after it is detached.
what's the correct way to handle this in my code? i don't want to have this idiom littered all over the place,
Activity activity = getActivity();
if (activity != null) { // do something }
looking at the docs for Fragment, i can come up with many possible hooks to solve this: isDetached(), onActivityCreated(), onAttach(), isResumed(), and so on. what is the right combination?
EDIT:
A few people have suggested canceling tasks when paused, but this implies that the standard idiom,
new AsyncTask<...>.execute();
cannot be used. It implies that every exec'd AsyncTask needs to be tracked to completion, or canceled. I have simply never seen that in example code from Google or elsewhere. Something like,
private final Set<AsyncTask<?>> tasks = new HashSet<>;
...
AsyncTask<?> t = new AsyncTask<...>() {
...
public void onPostExecute(...) {
tasks.remove(this);
...
}
}
tasks.add(t);
t.execute();
...
#Override
public void onPause() {
for (AsyncTask<?> t: tasks) {
t.cancel();
}
tasks.clear();
}

Try to cancel your AsyncTasks in the onPause or onStop methods. That will prevent the onPostExecute from being called when the Fragment is not active anymore (getActivity() returns null).
Or you could check if the Fragment is attached by calling this.isAdded() in your Fragment.

I could not find a good solution. In summary, either use a Loader, or check that getActivity() does not return null before using it. I looked into using Loaders, but the pattern makes a lot of assumptions about the structure of the app and the nature of data retrieval that didn't work for me.

In terms of coordinating lifecycles, I keep onActivityCreated as a mental benchmark - it marks the point at which the underlying activity has finished its own onCreate. Prior to that I do not believe there is an activity to getActivity() from.
That get activity is returning null sounds like either you're calling getActivity() too early (i.e. before it is created) or too late (i.e. when it stopped interacting with the fragment). Stopping your tasks in onPause() would prevent getActivity from returning null since it would cut off the task once the fragment stopped interacting with the underlying activity becuase the activity itself was paused. I think waiting for onStop() may be too late since, if the task were to still be running when the underlying activity paused it may still reutrn null.

What does this.finish() really do? Does it stop my code running?

I'm a bit hazy about what exactly this.finish() does. Specifically, I just wrote the following lines of code in an activity:
this.finish();
Globals gs = (Globals) getApplication();
gs.MainActivity.finish();
The code is meant to close the current activity and also close the core activity of the app. And it works great. However, I got wondering... obviously the current activity isn't quite ended after the first line is executed. And what if I was to call this.finish() and then start on some complicated computation?
My question is: When I call this.finish(), when exactly does my Activity get taken down?

Whatever method called finish() will run all the way through before the finish() method actually starts. So, to answer your question, after the calling method finishes then your activity will run its finish method.
If you don't want the method to continue then you can add a return statement after finish

I'm a bit hazy about what exactly this.finish() does
Calling finish() basically just notifies the Android OS that your activity is ready to be destroyed. Android will then (whenever its ready) call onPause() on the activity and proceed to destroy it (no guarentee onDestroy() will be called), via the activity lifecycle. In general, you probably should not be doing any more execution after you call finish(). According to the Android docs, you should call finish() when you are ready to close the activity.
when exactly does my Activity get taken down?
I am guessing your activity will simply be added to some destroy queue. During this time you might be able to continue executing until the OS destroys it. I believe you are for sure allowed to finish executing the method from which finish() was called.

Activity.finish() will not stop the current activity until the method is completely executed so to skip the remaining part of the code, you may use a return; use it with some condition to validate your skip.
if ( condition = true ) {
this.finish();
return;
}

Chris, I am no expert, but at the answer here about finish() in android is basically what codeMagic just said. The link is valuable because of the discussion regarding onStop() and onDestroy()

LoaderCallbacks.onLoadFinished not called if orientation change happens during AsyncTaskLoader run

Using android-support-v4.jar and FragmentActivity (no fragments at this point)
I have an AsyncTaskLoader which I start loading and then change the orientation while the background thread is still running. In my logs I see the responses come through to the background requests. The responses complete and I expect onLoadFinished() to be called, but it never is.
As a means of troubleshooting, in the Manifest, if I set android:configChanges="orientation" onLoadFinished() gets called as expected.
My Activity implements the loader callbacks. In the source for LoaderManager.initLoader() I see that if the loader already exists, the new callback is set to the LoaderInfo inner object class but I don't see where Loader.registerListener() is called again. registerListener only seems to be called when LoaderManagerImpl.createAndInstallLoader() is called.
I suspect that since the activity is destroyed and recreated on orientation change and since it is the listener for callbacks, the new activity is not registered to be notified.
Can anyone confirm my understanding and what the solution so that onLoadFinished is called after orientation change?

Nikolay identified the issue - Thank you.
I was calling initLoader fron onResume(). The Android documentation states:
"You typically initialize a Loader within the activity's onCreate()
method, or within the fragment's onActivityCreated() method."
Read "typically" as a bit more emphatic than I did when it comes to dealing with configuration change life cycle.
I moved my initLoader call to onCreate() and that solved my problem.
I think the reason is that in FragmentActivity.onCreate() a collection of LoaderManagers is pulled from LastNonConfigurationInstance and in FragmentActivity.onStart() there is some start up work regarding Loaders and LoaderManagers. Things are already in process by the time onResume() is called. When the Loader needs instantiated for the first time, calling initLoader from outside onCreate() still works.

It's actually not the call to initLoader() in onCreate() that's fixing it. It's the call to getLoaderManager(). In summary, what happens is that when an activity is restarted, it already knows about the loaders. It tries to restart them when your activity hits onStart(), but then it hits this code in FragmentHostCallback.doLoaderStart()*:
void doLoaderStart() {
if (mLoadersStarted) {
return;
}
mLoadersStarted = true;
if (mLoaderManager != null) {
mLoaderManager.doStart();
} else if (!mCheckedForLoaderManager) {
mLoaderManager = getLoaderManager("(root)", mLoadersStarted, false);
// WTF: Why aren't we calling doStart() here?!
}
mCheckedForLoaderManager = true;
}
Since getLoaderManager() wasn't called yet, mLoaderManager is null. It therefore skips the first condition and the call to mLoaderManager.doStart().
You can test this by simply putting a call to getLoaderManager() in onCreate(). You don't need to call init / restart loaders there.
This really seems like a bug to me.
* This is the code path even if you aren't using fragments, so don't get confused by that.