AL

Activity Lifecycle — Notes + Interview + Quiz

One-page revision website: Theory Notes 20 Q&A 50 Quiz

Most powerful interview line: “I never rely on onDestroy() for saving. I persist critical state earlier and keep UI state in ViewModel/SavedStateHandle.”
Daily plan (5 min):
  1. Read big diagram
  2. Revise key rules
  3. Attempt 10 quiz questions

Big Diagram (Memorise)

If you remember only this, you can answer 80% lifecycle questions.

[Launch] onCreate → onStart → onResume [Background] onPause → onStop [Return] onRestart → onStart → onResume [Back/Finish] onPause → onStop → onDestroy (not guaranteed in process death) [Rotation default] onPause → onStop → onDestroy → onCreate → onStart → onResume
Process death: OS can kill app after onStop() with no callbacks.

Theory Notes (Everything Important)

Clear theory + interview-safe explanations. Read this daily. Add your own project notes later.

Android Activity lifecycle is a state machine. Callbacks represent transitions between states. Your code must be written to handle:
  • Re-creation (rotation, process restore)
  • Interruptions (calls, permission dialogs, overlays)
  • OS killing background process (no callbacks)
[Stopped] --(onRestart)--> [Started] --(onResume)--> [Resumed] ^ ^ | | (onStop) | (onStart) | (onPause) | | v [Destroyed] <-(onDestroy)- [Paused]

Created: Activity object exists. UI inflated. Not yet visible.
Started: Activity is visible (maybe partially), not always interactive.
Resumed: Foreground + interactive (user can touch).
Paused: Lost focus, may still be visible (dialog/transparent overlay).
Stopped: Not visible. Can be killed anytime.
Destroyed: Instance removed (but callback not guaranteed in process death).

onCreate() — setup for this instance
inflate UI, init ViewModel, set listeners, read intent extras, lightweight restore
onStart() — visible state
register receivers tied to visibility, start UI collectors, lightweight animations
onResume() — interactive state
start camera preview, input focus, interactive sensors, real-time UI
onPause() — losing focus
pause media/animations, commit small UI state, MUST be fast
onStop() — not visible
release heavy resources, unregister receivers, persist important changes
onDestroy() — final cleanup (not guaranteed)
cleanup references; don’t rely on it for persistence

Home: onPause → onStop (no destroy)
Back/finish: onPause → onStop → onDestroy (normally)
A → B (opaque):
A: onPause() B: onCreate → onStart → onResume A: onStop()
A → B (transparent/dialog): A often only pauses (may NOT stop).

Default rotation: Activity recreated.
onPause → onStop → onDestroy → onCreate → onStart → onResume
If you set android:configChanges, Activity may NOT recreate. Then you must handle UI changes manually.
Best practice: Use ViewModel for UI state; avoid configChanges as a shortcut.

Purpose: store small UI state for recreation (IDs, scroll position, selected tab).
Common order:
onPause → onSaveInstanceState → onStop
Not called on: Back press / finish().
Don’t put huge data in Bundle (can crash with TransactionTooLargeException).

If app is in background, OS may kill process. In that case, your Activity may get no callbacks.
App background: onPause → onStop OS kills process later: (NO onDestroy) User returns: new process → onCreate(savedInstanceState may be non-null)
Persist important user data early. Do not wait for onDestroy.

Use lifecycle-aware collection to avoid leaks and crashes.
lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { // collect flows safely; stops automatically when not visible } }
Avoid GlobalScope for Activity work.

20 Interview Questions (Real Scenarios + Traps)

Answer = order + exception + best practice

Quiz Panel

Answer all 50, then check score.

Progress 0 / 50
Score
Accuracy

50-Question Quiz (MCQ)

Auto-rendered