Life Cycle Activity Stack (Part 1)

Perhaps the most popular question during interviews with an Android developer is: “tell us about the Activity life cycle”. At first glance, there is nothing difficult about this, in which only the blog has not yet written about it, and the candidate immediately begins to draw the well-known flowchart and explain in the course of the process. Spherical life cycle in a vacuum, which abounds in all the lessons, is really quite simple to understand, but after all, activity is only part of a certain generalizing essence. This entity is called Activity Stack, and we will now try to understand its life cycle.

Life Cycle Activity Stack (Part 2)

There is:
ActivityA, ActivityB, ActivityC

<activity android:name=".ActivityA"> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> <activity android:name=".ActivityB" /> <activity android:name=".ActivityC" /> 

On the layout of each of their Activities there is one button, which makes the usual launch of the next Activity:

 Intent intent = new Intent(view.getContext(), ActivityB.class); startActivity(intent); 

That is, ActivityA starts ActivityB, ActivityB starts ActivityC, and ActivityC starts ActiviyA again.

The Activity stack is the one for the rule that “the last to come — the first to go” rule works for him. On the back button, the current Activity is destroyed ( onDestroy() ), and the previous one is restored ( onCreate() and / or onStart() ), if the deleted was not the root.
')
For clarity, the log A-> B-> C-> back-> back-> back:

 ***   *** I/ActivityManager(249): START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.habrahabr.ActivityStackLifeCycle/.ActivityA u=0} from pid 8672 D/ActivityA(28229): onCreate() D/ActivityA(28229): onStart() I/ActivityManager(249): Displayed com.habrahabr.ActivityStackLifeCycle/.ActivityA: +234ms ***   ActivityB *** I/ActivityManager(249): START {cmp=com.habrahabr.ActivityStackLifeCycle/.ActivityB u=0} from pid 28229 D/ActivityB(28229): onCreate() D/ActivityB(28229): onStart() I/ActivityManager(249): Displayed com.habrahabr.ActivityStackLifeCycle/.ActivityB: +135ms D/ActivityA(28229): onStop() ***   ActivityC *** I/ActivityManager(249): START {cmp=com.habrahabr.ActivityStackLifeCycle/.ActivityC u=0} from pid 28229 D/ActivityC(28229): onCreate() D/ActivityC(28229): onStart() I/ActivityManager(249): Displayed com.habrahabr.ActivityStackLifeCycle/.ActivityC: +206ms D/ActivityB(28229): onStop() ***  Back *** D/ActivityB(28229): onStart() D/ActivityC(28229): onStop() D/ActivityC(28229): onDestroy() ***  Back *** D/ActivityA(28229): onStart() D/ActivityB(28229): onStop() D/ActivityB(28229): onDestroy() ***  Back *** D/ActivityA(28229): onStop() D/ActivityA(28229): onDestroy() 

Everyone is familiar with this behavior, but is our Activity Stack protected if we decide to leave the application in the background and start a resource-intensive third-party application?

App1-> A-> B-> C-> Home-> App2-> back-> App1:

 ***   *** I/ActivityManager(249): START {flg=0x10000000 cmp=com.habrahabr.ActivityStackLifeCycle/.ActivityA u=0} from pid 1195 I/ActivityManager(249): Start proc com.habrahabr.ActivityStackLifeCycle for activity com.habrahabr.ActivityStackLifeCycle/.ActivityA: pid=1267 uid=10060 gids={1028} D/ActivityA(1267): onCreate() D/ActivityA(1267): onStart() ***  Home,  - , , ,      *** <...> I/ActivityManager(249): Process com.habrahabr.ActivityStackLifeCycle (pid 1267) has died. <...> ***    ,     *** I/ActivityManager(249): Start proc com.habrahabr.ActivityStackLifeCycle for activity com.habrahabr.ActivityStackLifeCycle/.ActivityC: pid=1879 uid=10060 gids={1028} D/ActivityC(1879): onCreate() D/ActivityC(1879): onStart() 

From the log, we see that the process of our application ( id=1267 ) was killed, but this did not prevent Android from returning to our application to create a new one ( id=1879 ) and open the last ActivityC we were on when we turned off the application.

We will do something similar, but we will not wait until the third-party application requires memory and kills our application, and do it ourselves through the Application Manager with the Force Stop button.

App1-> A-> B-> C-> Home-> App Manager-> Force Stop-> App1

 ***   *** I/ActivityManager(249): START {flg=0x10000000 cmp=com.habrahabr.ActivityStackLifeCycle/.ActivityA u=0} from pid 32050 I/ActivityManager(249): Start proc com.habrahabr.ActivityStackLifeCycle for activity com.habrahabr.ActivityStackLifeCycle/.ActivityA: pid=32090 uid=10060 gids={1028} D/ActivityA(32090): onCreate() D/ActivityA(32090): onStart() <...> ***  Home,  Application Manager,       Force Stop *** I/ActivityManager(249): Force stopping package com.habrahabr.ActivityStackLifeCycle uid=10060 I/ActivityManager(249): Killing proc 32090:com.habrahabr.ActivityStackLifeCycle/u0a60: force stop I/ActivityManager(249): Force finishing activity ActivityRecord{419ba4b0 com.habrahabr.ActivityStackLifeCycle/.ActivityA} I/ActivityManager(249): Force finishing activity ActivityRecord{41c392b8 com.habrahabr.ActivityStackLifeCycle/.ActivityB} I/ActivityManager(249): Force finishing activity ActivityRecord{41ac4588 com.habrahabr.ActivityStackLifeCycle/.ActivityC} <...> ***   Application Manager,     *** I/ActivityManager(249): START {flg=0x10104000 cmp=com.habrahabr.ActivityStackLifeCycle/.ActivityA u=0} from pid 337 I/ActivityManager(249): Start proc com.habrahabr.ActivityStackLifeCycle for activity com.habrahabr.ActivityStackLifeCycle/.ActivityA: pid=32378 uid=10060 gids={1028} D/ActivityA(32378): onCreate() D/ActivityA(32378): onStart() 

We get a completely different behavior: Activity Stack is lost, and when the application starts after force stop, we find ourselves in the root ActivityA.

We also note that in both cases, when our process was completely destroyed, the onDestroy() method was not called in any Activity, this should certainly be taken into account when developing.

We dealt with the default behavior, but Android’s arsenal has the tools to change the behavior to fit our needs. We will look at them in the next section.

PS Added your comments to the logs at the request of Vest . Thank! It seems to be clearer.