Sample questions
Kt Android Lifecycle Background ExecutionDifficulty 1
What is onCreate() in an Android Activity primarily responsible for?
- aReleasing all resources before the activity disappears.
- bInflating the layout and setting initial state, once.✓
- cHandling every touch event the user performs.
- dRunning continuously in the background after the screen is closed.
Explanation:onCreate() runs once per Activity instance's creation and is where you inflate the layout, set up views, and restore any saved instance state — it is not called again just because the user returns to the screen.
Kt Android Lifecycle Background ExecutionDifficulty 1
Which pair correctly describes the difference between onCreate() and onStart()?
- aThey always run at the exact same moment, order is irrelevant.
- b
onStart() runs before onCreate() on every launch. - c
onCreate() can be called multiple times per instance, onStart() only once. - d
onCreate() runs once; onStart() runs whenever it becomes visible.✓
Explanation:onCreate() fires once (initial setup). onStart() fires every time the activity is about to become visible — including when returning from the background — so it can run multiple times per instance while onCreate() runs once.
Kt Android Lifecycle Background ExecutionDifficulty 1
What is the key practical difference between onPause() and onStop()?
- a
onPause() fires losing focus; onStop() once invisible.✓ - bThey are two names for the exact same callback.
- c
onStop() always fires before onPause() in every scenario. - d
onPause() only exists for fragments, never for activities.
Explanation:onPause() runs when the activity is still partially visible but losing focus (e.g. a dialog appears on top). onStop() runs once the activity is no longer visible at all.
Kt Android Lifecycle Background ExecutionDifficulty 2
Is it guaranteed that onDestroy() will always be called before an Activity's process disappears?
- aYes, always, with no exceptions whatsoever.
- bNo,
onDestroy() never actually runs on real devices. - cNo — the system can kill the process without calling it.✓
- dYes, but only if the user explicitly presses a back button.
Explanation:onDestroy() is the final lifecycle callback, but it is not a hard guarantee — if the system needs to reclaim memory, it can kill the process outright without ever calling onDestroy(), which is why critical cleanup shouldn't rely solely on it.
Kt Android Lifecycle Background ExecutionDifficulty 2
A device is rotated while an Activity with a plain (non-ViewModel) var count = 0 property is on screen. What happens to count by default?
- aIt is automatically written to disk and restored exactly.
- bRotation never affects a running Activity's instance at all.
- cThe Activity is recreated, so
count resets to 0.✓ - d
count is guaranteed to keep incrementing across the rotation.
Explanation:By default, a configuration change like rotation destroys and recreates the Activity instance, so any plain in-memory property not explicitly saved (e.g. via onSaveInstanceState or a ViewModel) is lost and reset to its initial value.
Kt Android Lifecycle Background ExecutionDifficulty 1
Why does a ViewModel instance survive a configuration change (like rotation) while the Activity itself is destroyed and recreated?
- aIt doesn't survive; every
ViewModel is also destroyed and recreated on rotation. - bA
ViewModel is actually a special kind of Activity subclass. - cThe framework retains it across recreation and reattaches it.✓
- dIt survives because it is automatically serialized to disk on every rotation.
Explanation:The Architecture Components ViewModel is scoped to a lifecycle owner and kept alive by the framework across configuration-change recreations; the new Activity instance is simply reattached to the same retained ViewModel, so its in-memory state survives.