Activities & the Complete Lifecycle

What is an Activity?

An Activity is a single screen the user interacts with — the login screen, the home screen, a details page. Most apps have several. Android does not let your screen live forever: as the user opens other apps, takes a call, presses Home, or rotates the device, the system starts, pauses, stops and even destroys your activity to manage memory.

To run code at the right moment, you override lifecycle callback methods. Using them correctly is what keeps an app from losing data or crashing.

The complete lifecycle

The diagram below shows the order the callbacks are called, from creation at the top to destruction at the bottom. When the user comes back to a stopped activity, Android calls onRestart() and the cycle resumes.

Each callback explained

• onCreate() — called once when the activity is first created. Set up the UI here with setContentView(), bind views, and read saved state. The most important method.
• onStart() — the activity becomes visible (but not yet interactive).
• onResume() — the activity is in the foreground; the user can interact. Start animations, camera, or sensors here.
• onPause() — something is taking focus (a dialog, a call). Runs quickly — only pause work and save small critical data.
• onStop() — no longer visible. Release heavier resources here.
• onRestart() — a stopped activity is returning; followed by onStart().
• onDestroy() — being removed from memory. Final cleanup.

Three lifetimes to remember

• Entire lifetime — onCreate() to onDestroy().
• Visible lifetime — onStart() to onStop().
• Foreground lifetime — onResume() to onPause().

See it for yourself

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        Log.d("LIFE", "onCreate")
    }
    override fun onStart()   { super.onStart();   Log.d("LIFE", "onStart") }
    override fun onResume()  { super.onResume();  Log.d("LIFE", "onResume") }
    override fun onPause()   { super.onPause();   Log.d("LIFE", "onPause") }
    override fun onStop()    { super.onStop();    Log.d("LIFE", "onStop") }
    override fun onDestroy() { super.onDestroy(); Log.d("LIFE", "onDestroy") }
}

Run it and watch Logcat as you open, leave, return to, and rotate the screen — the order will make the lifecycle click.

The rotation problem

When you rotate the phone, Android destroys and recreates the activity, so plain variables are lost. Two ways to keep data:

1. onSaveInstanceState — for small UI values:

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("name", binding.nameField.text.toString())
}

2. ViewModel — the modern fix for real data; it survives rotation automatically.

class MainViewModel : ViewModel() {
    var userName: String = ""   // kept across rotation
}
private val viewModel: MainViewModel by viewModels()

Common mistakes

• Doing heavy work in onResume()/onPause() — they must be fast.
• Storing important data in plain activity variables (lost on rotation).
• Forgetting to call super in a callback.

Summary: tiny UI state → onSaveInstanceState; real data → ViewModel. Learn the callback order and your app will behave predictably.