Confused about this Android Activity life cycle scenario - OnCreate gets called whenever app goes back to foreground

Question

To make things as simple and easy to follow I created a new empty project in Android Studio with only one MainActivity and Hello World text. This could not by any means be a consuming app. I also did override all the important life-cycle methods like onCreate ,onStart, onResume, onPause, onSaveInstanceState, onStop, onDestroy and logged them to see what is happening.

So here is what I am experiencing (in each step the list of life-cycle callbacks is printed)

1. After app/activity launches (expected behavior)

onCreate onStart onResume

2. After I press home button / app goes in background (expected behavior)

onPause onSaveInstanceState onStop

3. After I immediately return / app goes in foreground (expected behavior)

onStart onResume

4. After I press home button (app goes in background) and I open another app like Facebook and immediately return back to my app I expect it to resume, but instead onCreate gets called.

onCreate onStart onRestoreInstanceState onResume

I find this really strange because I am not low on memory on my device and I have basically empty activity. Is there some flag I can set in the manifest or any solution that will not recreate my activity when I return to it ?

Please don't suggest I save and restore state using onSaveInstanceState and onRestoreInstanceState, I am specifically interested why onCreate is called when I move my app back in foreground. I've done many apps in the past and I don't remember having this issue before with activities being destroyed so early.

Answer 1

I open another app like Facebook and immediately return back to my app I expect it to resume, but instead onCreate gets called

Apparently, Android terminated your process, either of its own volition to free up system RAM or at the behest of some other app (e.g., task manager). This may also be device-specific, as device manufacturers can tweak how this stuff works, from what I can tell.

I find this really strange because I am not low on memory on my device

Perhaps Android or the task manager disagreed with you. Perhaps your means of determining free memory isn't the same as what the out-of-memory killer uses. Also, bear in mind that Facebook uses some techniques that cause them to use an outsize amount of RAM for their process, so they will cause more of this sort of thing than will a leaner app.

Is there some flag I can set in the manifest or any solution that will not recreate my activity when I return to it ?

No.

That being said, there are a variety of factors that the out-of-memory killer will use to determine what process(es) to terminate to free up memory, including:

• process importance (are you in the foreground? do you have a service running?)
• process age
• process working set size (i.e., memory usage)

Please don't suggest I save and restore state using onSaveInstanceState and onRestoreInstanceState

I would suggest to all Android developers that they save and restore instance state using onSaveInstanceState() and onRestoreInstanceState(). That helps with configuration changes as well as these sorts of process termination scenarios.

I've done many apps in the past and I don't remember having this issue before with activities being destroyed so early.

Perhaps you did not test them on this device, or on this device and OS version (if you got an upgrade). Perhaps you did not test them in this scenario (e.g., launching Facebook). Perhaps you did not test them with the other apps you have running that might be affecting matters. Since you wrote those other apps, presumably you can re-run your tests using those apps, for more of an apples-to-apples comparison.

Answer 2

You can (and should) make this happen for testing by turning on the "don't keep activities" developer option. You cannot prevent it from happening. This can always happen, and you must handle it gracefully.

Please don't suggest I save and restore state using onSaveInstanceState and onRestoreInstanceState

That's what you have to do if you want your app to work reliably.

Answer 3

The android lifecycle guarantees some things and provides no guarantees about others. It's guaranteed that if your activity was destroyed, onCreate() will be called before onStart() and onStart() before onResume().

However, in most cases there is no guarantee that your activity will NOT be destroyed once it goes into the background. The reasons are not fully spelled out because this gives google (and individual android distributions) the freedom to modify such things in the future. Part of the downside of having no such guarantee means that just because your activity did not get destroyed in the past, does not mean that in a different version of android, different device, or different circumstance, that it will not get destroyed in the present.

If you must know the exact reason why, I would suggest monitoring the log output very closely, it may contain some clue. But keep in mind that android does not intend for the developer to try to avoid this, only to resume from where you left off when the activity is re-created.