Activity Lifecycle Quiz
ANDROID › Lifecycle
On device rotation, what is the callback sequence for the existing activity instance?
- onPause, onStop, onDestroy
- onPause, onStop, onRestart
- onStop, onDestroy, onSaveInstanceState
- onDestroy only
Answer: onPause, onStop, onDestroy
Rotation is a configuration change: the activity is torn down (onPause, onStop, onDestroy) with instance state saved, then a fresh instance is created and restored.
The user presses the Home button. Which statement is true?
- onDestroy is guaranteed to run immediately as soon as Home is pressed
- onPause then onStop run, onSaveInstanceState may fire, and it can be killed
- Only onPause runs and the activity remains in the Resumed state
- onSaveInstanceState is skipped entirely because the user chose to leave voluntarily
Answer: onPause then onStop run, onSaveInstanceState may fire, and it can be killed
Home sends the activity to the background (onPause then onStop); state is saved so it can be restored if the process is later reclaimed, but the instance is kept until then.
You call finish() inside onCreate(). What runs next?
- onStart, onResume, onPause, onStop, then onDestroy in full
- onStart, then onResume, and finally onDestroy run in order
- onRestart, then onStart, then onResume run in sequence
- onDestroy runs immediately, skipping all the other callbacks
Answer: onDestroy runs immediately, skipping all the other callbacks
This is the documented exception: finish() in onCreate causes onDestroy to run directly without onStart, onResume, onPause, or onStop.
In multi-window mode an activity loses focus to the other window but stays fully visible. Its state is:
- Stopped; onStop has already been called, so it's no longer visible
- Paused; onPause is called, but the activity can still show
- Destroyed; the activity has been torn down and cannot remain onscreen
- Resumed; it keeps focus, so losing focus would not change its state
Answer: Paused; onPause is called, but the activity can still show
Only one window holds focus at a time; the unfocused activity is Paused yet may remain visible, which is exactly why UI teardown belongs in onStop, not onPause.
Which scenario passes a non-null savedInstanceState Bundle to onCreate()?
- The app’s very first cold launch, before any state was saved
- Returning to a stopped activity that was never destroyed
- Recreation after a config change or process death
- Relaunching from the launcher after the user pressed Back
Answer: Recreation after a config change or process death
The Bundle is populated only when the system saved state to recreate the activity (config change or process death). Back discards state, and a merely stopped activity is not recreated.
Activity A starts a full-screen opaque Activity B. What is the correct interleaving of callbacks?
- A.onStop, B.onCreate, B.onResume, then A.onPause follows
- A.onDestroy, B.onCreate, B.onStart, B.onResume, then onStop
- B.onCreate, A.onPause, A.onStop, then B.onResume completes
- A.onPause, B.onCreate, B.onStart, B.onResume, A.onStop
Answer: A.onPause, B.onCreate, B.onStart, B.onResume, A.onStop
A pauses first, B comes fully up (create, start, resume), and only then does A stop once it is no longer visible behind B.
An activity with launchMode="singleTop" is already at the top of the task and is launched again. Which callback receives the new intent?
- onNewIntent on the existing instance; onCreate is skipped
- onCreate, because a new instance is always created instead
- onRestart, after the activity has been stopped and relaunched
- onSaveInstanceState, then onCreate for the new instance
Answer: onNewIntent on the existing instance; onCreate is skipped
singleTop reuses the existing top instance and delivers the intent via onNewIntent (typically onPause, onNewIntent, onResume) rather than creating a new instance with onCreate.
On API 29+ several activities can be RESUMED at once. Which callback tells an activity it now owns exclusive singleton hardware like the camera, and how should it react?
- onResume: take the camera here, because resumed always means focused
- onTopResumedActivityChanged(true): take the camera; release it on false
- onWindowFocusChanged: take the camera on focus; it only tracks the top activity
- onStart: take the camera because becoming visible implies exclusive ownership
Answer: onTopResumedActivityChanged(true): take the camera; release it on false
onTopResumedActivityChanged(Boolean) was added for multi-resume so an activity learns when it becomes the single top-focused one; acquire the exclusive resource on true and release on false.
Inside onDestroy(), how do you reliably distinguish a permanent finish from a transient destroy that will be followed by recreation?
- Check savedInstanceState; null means a real finish, so use that
- Inspect getChangingConfigurations(); non-zero means the user pressed Back
- Call isFinishing(): true means a real finish, false a recreation
- There’s no reliable way to tell them apart from inside onDestroy()
Answer: Call isFinishing(): true means a real finish, false a recreation
isFinishing() returns true only when the activity is genuinely finishing; on a configuration change it returns false because the instance is being destroyed only to be recreated.
Activity A launches Activity B, but B uses a translucent (dialog-style) theme so A stays partly visible behind it. What happens to A?
- A receives onPause but not onStop, since A remains visible behind B
- A receives onPause then onStop, like launching a fully opaque activity
- A receives onStop only, because it loses focus even though it still shows
- A receives onDestroy because B replaces it completely on the back stack
Answer: A receives onPause but not onStop, since A remains visible behind B
onStop fires only when an activity becomes fully invisible; a translucent activity does not cover A, so A stops at Paused and onStop is not called.
For an app targeting a modern Android version (API 28+), when is onSaveInstanceState() invoked relative to onStop()?
- Always before onPause(), so it never sees a stopped activity
- Exactly between onPause() and onStop() on every API level
- It is folded into onStop() and never fired as a separate call
- After onStop(), since Android P changed the guaranteed order
Answer: After onStop(), since Android P changed the guaranteed order
Since apps targeting Android P (API 28), onSaveInstanceState is guaranteed to run after onStop; on older targets it ran before onStop with no firm ordering against onPause.
The user navigates from a stopped (but not destroyed) Activity back to it via Recents. What callback sequence does that instance receive?
- onCreate, onStart, onResume, because returning rebuilds the activity
- onRestart, onStart, onResume, with no onCreate
- onResume only, since the views were never torn down
- onRestoreInstanceState, onStart, onResume
Answer: onRestart, onStart, onResume, with no onCreate
A stopped instance that was never destroyed re-enters the foreground via onRestart then onStart then onResume; onCreate is skipped because no new instance is built and no Bundle is involved.
A ViewModel holds UI state. The app is backgrounded and the OS later kills the process to reclaim memory; the user then returns. What is restored?
- The same ViewModel instance, since it is meant to outlive the app process
- Nothing is restored automatically, because the ViewModelStore stays after kill
- Only state from onSaveInstanceState/SavedStateHandle; the ViewModel is new
- Both the ViewModel and the savedInstanceState Bundle come back unchanged
Answer: Only state from onSaveInstanceState/SavedStateHandle; the ViewModel is new
ViewModels survive configuration changes but not process death; after the process is recreated only the saved-state Bundle (e.g. via SavedStateHandle) is restored, and a fresh ViewModel is built.