android activity lifecycle,Simplest Android Activity Lifecycle

The mature, full-featured and full functional Android app gets transitioned (state = function of time) according to the answer provided by @Felix.

But what if you just want to create an app which doesn't even have GUI. And you want the simplest lifecycle then I have the answer below.

This answer probably you would find interesting. Android system after reading AndroidManifest.xml knows which is entry point. Whichever activity has this

will be the starting or entry point for the system to start with. After this, your app process got the memory where it can start itself.

Your main process creation is the task of Android system. When an application component starts and the application does not have any other components running, the Android system starts a new Linux process. After the process calls the onCreate(), it creates main thread. That's the reason why you must call onCreate(), because the main thread is then initialized and the main thread is the trigger for all of your future actions.

On onCreate(), you got your main thread. After that, it is totally up to you, what callbacks you want to call. There is no rule you must call onStart() after onCreate().

Only one lifecycle method onCreate() is guaranteed to be your component's life cycle back.

And, furthermore, to understand, what each lifecycle method is doing inside it, put the below code.

//add the log line

Log.i(this.getClass().getCanonicalName(), "##############");

int count = 0;

for (StackTraceElement stackTraceElement: Thread.currentThread().getStackTrace()) {

count++;

Log.i(this.getClass().getCanonicalName(), "\""+Thread.currentThread().getStackTrace()[2].getMethodName()+"\" "+count+" "+stackTraceElement.getMethodName());

}; //end of log line

So, always add above same code to view logs in log cat console.

When your app starts GUI, it calls onStart(). If you don't call super() method inside the callback, android system shows broken pipe error and it can't do further processing and debugging.

But, you can implement your own logic inside each callback method. Eg, you can do summation of two numbers on onStart().

So, all android callback methods are partially implemented methods. They are not purely abstract methods because you should call the super() method inside them.

The attached picture tells: Application main process calls onCreate(), it delegates it's responsibilities to main thread (UI thread) and main thread calls these 16 other callbacks.

Further, if you would like to see all of your methods at particular time, put this below code.

//to see all the methods (including super methods) at this time, you call use the java reflection as below

Log.i(this.getClass().getCanonicalName(), "##############");

int count1 = 0;

for (Method method: this.getClass().getMethods()) {

count1++;

count++;

Log.i(this.getClass().getCanonicalName(), count1+" "+method);

}; //end of log line

//At another time, after you add some other methods or android using GC removes some methods, you see your changed state (Bundle Snapshot) of your class

//Because your bundle (i.e, the state of your class/activity) is the function of time.

In my scenario, from the just above code snippet, I see it has called 375 methods.

Note: If you had added another method inside onCreate() before you print all of your methods using just above code snippet, you would have seen that method as well. It means, your state of the class (i.e., snapshot) is according to you, what you do time after time, you keep updating your snapshot.