Android Lifecycle Interview Questions

An Activity is a single screen with a UI, and its lifecycle is the set of callback methods the system calls as that screen moves between being created, visible, focused, backgrounded, and destroyed.

There are seven you should know cold.

• onCreate() runs once, when the activity is first created. That's where you inflate the layout, set up your ViewModel, and restore any saved state.
• onStart() fires when the activity becomes visible.
• onResume() fires when it gains focus and the user can actually interact with it. This is the foreground state.
• onPause() fires the moment the user starts leaving. It has to be fast, because the next screen is waiting on it.
• onStop() fires once the activity is no longer visible at all. That's where you do heavier cleanup.
• onRestart() fires when a stopped activity is about to become visible again, right before onStart(). It's the one people forget, because it only runs on the way back and never on first launch.
• onDestroy() fires when the activity is finishing or being recreated, for final cleanup.

the Activity lifecycle−100%+Esc

The rule of thumb interviewers are checking for is symmetry. Whatever you start in onResume(), like a camera preview or a sensor listener, you release in onPause(). Whatever you start in onStart(), you release in onStop().

One trap worth mentioning. A configuration change, like a screen rotation, destroys and recreates the activity by default, running the whole onPause through onDestroy then onCreate through onResume sequence again. There is no onRecreate() callback, which people sometimes expect. recreate() is a method you call to trigger that cycle yourself, not something the system calls on you. That's exactly why ViewModel exists, to hold UI state across that destroy and recreate cycle without you having to manually save and restore everything in onSaveInstanceState().

The other callback worth knowing is onNewIntent(), which sits outside that sequence. If an Activity is launched again while an instance already exists, and its launch mode is singleTop, singleTask or singleInstance, Android does not build a second instance and does not call onCreate() again. It calls onNewIntent() on the existing instance, then onRestart(), onStart() and onResume() if it had been stopped.

The gotcha interviewers like here is that getIntent() still returns the original Intent after onNewIntent() runs. You have to call setIntent(intent) yourself inside onNewIntent(), otherwise you keep reading stale data from whenever the Activity was first launched. This is the classic bug behind a notification tap that opens the wrong screen.

The scenario questions interviewers ask

Most of this topic gets asked as small puzzles. Here is the trigger and the exact callback order for the ones that keep coming up.

• A starts B. A onPause, then B onCreate, onStart and onResume, and only after that A onStop. A stops last on purpose, because the system waits until B is actually on screen before it tears down what A was holding. That is also why onPause has to be tiny. B is waiting on it, so a disk write or a network call there turns into visible jank on every navigation.
• Back from B to A. B onPause, then A onRestart, onStart and onResume, then B onStop and onDestroy. Same rule, the leaving screen finishes last. A is the same instance, so there is no onCreate.
• Home on A. onPause and onStop, with onSaveInstanceState next to them. On API 28 and later it runs after onStop, and before API 28 it ran before onStop. Coming back from the launcher gives you onRestart, onStart and onResume, with no onCreate, because the instance was never destroyed.
• A dialog themed or transparent activity on top of A. A gets onPause and nothing more. It is still partly visible, so it never reaches the stopped state. A plain Dialog, the kind you show from the activity itself, is only a window inside that same activity, so it fires no lifecycle callback at all. People get that second half wrong constantly.
• Rotation on A. onPause, onStop, onSaveInstanceState, onDestroy, then onCreate with the saved Bundle, onStart, onRestoreInstanceState, onResume. A ViewModel survives, because the system keeps it as the retained non configuration instance and hands it to the new activity. Fields on the activity do not survive. android:configChanges is the opt out, and it is discouraged, because you then owe correct handling of every change you claimed and recreation can still happen for other reasons.
• Process death in the background, then return. You come back on a brand new process, so onCreate runs with a non null Bundle. The ViewModel is gone, since it only ever lived in memory. What comes back is whatever you wrote in onSaveInstanceState or in a SavedStateHandle, which is the whole reason SavedStateHandle exists.
• Multi window or split screen. Before Android 10 only one activity is resumed at a time and the rest sit in the started state. On Android 10 and later, multi resume keeps both resumed, and onTopResumedActivityChanged() is the callback that tells you which one currently has focus. That is where you grab or release a singleton resource like the camera or the microphone.
• An incoming call or the lock screen on A. The full screen case is onPause then onStop, and onRestart, onStart, onResume when the user comes back. A call shown as a heads up overlay is the other case. A stays partly visible, so it only pauses, which is exactly the dialog themed activity rule again.
• finish() called inside onCreate. onDestroy runs and onStart and onResume never do. The activity is finishing before it was ever visible, so nothing you set up for the visible states gets torn down for you. Clean up whatever you already allocated.
• A notification opens A while B is on top. With standard, you get a second A instance stacked above B. With singleTop, singleTask or singleInstance, the existing A gets onNewIntent(), then onRestart, onStart and onResume if it was stopped, and no onCreate. The full set of stack puzzles lives in launch modes.

Three of those, drawn out. Time runs left to right and the arrow follows the order the system actually calls things.

A starts B−100%+Esc

Back from B to A−100%+Esc

Rotation on A−100%+Esc

What all of these are really checking is three habits. That you treat onPause as a place for tiny work only, that onStop is where you release what the screen was holding, and that onDestroy is not guaranteed at all when the system kills your process. If cleanup has to happen, it belongs in onStop, not in onDestroy.

By default the system treats a rotation as a configuration change, and destroys and recreates the Activity entirely, running onPause(), onStop(), onDestroy(), then a fresh onCreate(), onStart(), onResume() on a brand new instance.

Anything you did not explicitly preserve is gone, views get reinflated, in flight animations reset, and any local variable holding state just disappears with the old instance. This is exactly why ViewModel exists, its instance is handed off to the new Activity instance through a retained store the framework keeps aside from the destroy and recreate cycle, so your UI state does not have to be manually rebuilt from nothing every time.

You can opt out of this behavior by declaring android:configChanges="orientation|screenSize" in the manifest for that Activity, which tells the system not to destroy it for those specific changes, instead just calling onConfigurationChanged() so you can adjust the layout yourself. This is uncommon in practice, most apps let the recreate happen and rely on ViewModel plus onSaveInstanceState() rather than taking on the responsibility of handling every layout adjustment by hand.

onCreate() runs once for the entire life of an Activity instance and the Activity is not visible to the user yet, it is where you inflate the layout, set up a ViewModel, and restore any saved state. onStart() is where the Activity actually becomes visible on screen, though it is still not interactive at that point.

The other difference is how often each runs. onCreate() only fires once per instance, right after the Activity is constructed. onStart() can fire many times over that same instance's life, every time the Activity comes back to the screen after being stopped, for example returning from another Activity, onStart() runs again but onCreate() does not.

In practice this means anything that should only ever happen once, setting up view references, creating objects, belongs in onCreate(). Anything that needs to re run each time the screen becomes visible again, restarting a listener you released in onStop() for instance, belongs in onStart().

onActivityResult() is called on the calling Activity once the Activity it launched with startActivityForResult() finishes and returns a result, and it runs after onRestart() but before onResume() on the way back.

@Deprecated("Deprecated in Java")
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
    if (requestCode == PICK_IMAGE && resultCode == Activity.RESULT_OK) {
        val uri = data?.data
    }
}

It is deprecated in favor of the Activity Result API, registerForActivityResult(), because request codes had to be managed by hand across the whole Activity or Fragment, which got messy fast once a screen launched more than one thing for a result, and there was no compile time guarantee that the code reading the result matched the code that launched it.

val pickImage = registerForActivityResult(ActivityResultContracts.GetContent()) { uri ->
    // handle result directly, no request code to match up
}

onSaveInstanceState(outState: Bundle) is called before the Activity is destroyed for a reason the system might not bring it back exactly as it was, a rotation, or the system killing the process in the background to reclaim memory. You pack small, simple values into the Bundle, scroll position, a selected tab, text a user was mid typing.

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putInt("scrollPosition", scrollPosition)
}

onRestoreInstanceState(savedInstanceState: Bundle) is called after onStart(), with that same Bundle, and hands you a guaranteed non null value, unlike onCreate() where the savedInstanceState parameter can be null on a fresh launch. Most people just read it back in onCreate() instead since it is called earlier and the null check is trivial, onRestoreInstanceState() exists mainly for the cases where you want restoration to happen strictly after the rest of onStart() has run.

One thing worth remembering, this Bundle is meant for small amounts of UI state, not your whole app's data, it gets serialized and there are real size limits on how much you can safely stuff into it. It also does not fire when the user presses back and the Activity finishes normally, only when the destruction is not the user's own choice to leave.

onPause() fires whenever the Activity is about to lose focus, which is a broader condition than losing visibility entirely, that is what onStop() is for.

• The user presses Home, or opens Recents, taking focus away from the app.
• Another Activity is launched on top of this one, including a translucent or dialog themed Activity that leaves this one partially visible underneath.
• A system level UI appears over the app, an incoming call, a permission prompt, a system dialog.
• The user switches focus to a different app window in split screen or multi window mode.
• The device locks, the screen turns off, or the user starts using another app entirely.

The common thread is loss of focus, not loss of visibility, an Activity can be fully on screen and still onPause(), for example sitting behind a translucent Activity or a system dialog. That is also why onPause() has to be fast, whatever triggered it is usually waiting on it to finish before it can fully take over.

Honestly, it does not, not in the way the question implies. onPause() and onStop() always run before onDestroy() for a normal Activity finish, the framework does not skip earlier callbacks in that sequence.

The scenario people usually mean by this question is calling finish() very early, inside onCreate() before the Activity is even shown. What actually happens there is that the Activity still runs the full sequence, onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(), it just happens in one quick burst instead of being spread out over user interaction, which can make it look from a casual glance like the middle steps were skipped when they were not.

The other case that can genuinely look like "only onDestroy() ran" is the system killing the process outright, low memory, a force stop, a crash. That is actually the opposite of the premise, none of the lifecycle callbacks run reliably in that case, onDestroy() included, because the process is simply terminated rather than walked through its normal teardown.

If you are asked this in an interview, the strongest answer is naming the false premise directly, Android's lifecycle callbacks fire in a fixed, guaranteed order for a normal Activity finish, and the two situations that break that expectation either still run every callback in sequence or run none of them at all.

Use onResume(), not onStart(). onStart() only tells you the Activity became visible, onResume() is the point it actually has focus and the user can interact with it, which is what most people mean by "came to the foreground."

override fun onResume() {
    super.onResume()
    analytics.logScreenView(screenName)
}

Remember it fires every time the Activity returns to the front, not just on first launch, returning from a dialog, from another Activity, from the recents switcher, or after the screen turns back on, all trigger onResume() again, so anything you put there needs to be safe to run repeatedly.

If what you actually need is knowing when the whole app comes to the foreground, not just this one Activity, onResume() on a single Activity is the wrong tool, since it also fires when navigating between your own screens. That case calls for ProcessLifecycleOwner, which exposes app level foreground and background events independent of which Activity is currently showing.

A Fragment is a reusable piece of UI and behavior that lives inside an Activity, and its lifecycle is similar to an Activity's but with a few extra states because a Fragment has to attach to a host and manage its own view separately.

The order runs like this.

• onAttach(), the Fragment gets a reference to its host Activity.
• onCreate(), the Fragment itself is created, but there's no view yet.
• onCreateView(), you inflate and return the layout.
• onViewCreated(), the view now exists, so this is where you set up RecyclerView adapters or observe LiveData.

Then onStart() and onResume() mirror the Activity's, followed on the way out by onPause(), onStop(), onDestroyView(), onDestroy(), and onDetach().

the Fragment lifecycle−100%+Esc

The one thing that actually gets asked in interviews is why there are two separate "destroy" points, onDestroyView() and onDestroy(). A Fragment can be kept alive in the back stack while its view is torn down, for example when you navigate away. So the Fragment object survives but its view doesn't. That's why Fragments expose a separate view lifecycle through viewLifecycleOwner, and why you should always observe LiveData or collect Flows using viewLifecycleOwner, not the Fragment itself. If you use the Fragment's own lifecycle for that, you can leak observers that outlive the view and even get called after the view is gone, which crashes or silently updates a view that no longer exists.

One more thing worth saying out loud. Any view references you grab in onCreateView() should be cleared in onDestroyView() (this is the whole reason for the "clear the binding" pattern with view binding), otherwise you're holding a reference to a destroyed view.

The scenario questions interviewers ask

The rule underneath all of these is that a Fragment can never be in a higher state than its host. The host moves first on the way up and last on the way down.

• Adding F in the Activity's onCreate(). The transaction is committed there, so F runs onAttach, onCreate, onCreateView and onViewCreated while the Activity is still creating. Then the Activity's onStart is followed by F's onStart, and the Activity's onResume by F's onResume. On the way out the order flips, F pauses and stops before its host does.
• Replacing F with G, with addToBackStack. F runs onPause, onStop, onDestroyView, and stops there. No onDestroy, no onDetach. The instance stays alive in the back stack with only its view torn down. Press Back and the same instance gets onCreateView and onViewCreated again with a brand new view, then onStart and onResume. That is why view references must be cleared in onDestroyView() and why viewLifecycleOwner exists at all.
• Replacing F without addToBackStack. F goes the whole way, onPause, onStop, onDestroyView, onDestroy, onDetach. The instance is gone and nothing about it comes back.
• Rotation with a Fragment on screen. It is destroyed and recreated along with the Activity. The arguments Bundle survives, and so does anything you wrote in the Fragment's onSaveInstanceState. Plain fields do not. A ViewModel scoped to the Fragment survives. The FragmentManager restores the Fragment for you, so committing it again in the Activity's onCreate() without checking savedInstanceState == null gives you two copies stacked on each other. That is one of the most common bugs on this topic.
• ViewPager or tabs. Off screen pages get created but should not be resumed, otherwise every tab starts its own analytics ping or video player. FragmentStateAdapter on ViewPager2 uses setMaxLifecycle() to cap off screen pages at the started state, so only the visible one reaches resumed. On the old ViewPager, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT is the setting that does the same job.
• A DialogFragment shown and dismissed. Showing it runs the normal creation path, onAttach through onResume, and the host Activity gets no callback, because the dialog is a window inside it. Dismissing runs onPause, onStop, onDestroyView, onDestroy, onDetach, unless you added it to the back stack, in which case it stops at onDestroyView like any other Fragment.
• Nested child fragments. A child can never be in a higher state than its parent, so the parent starts first and the child stops first. Use childFragmentManager for fragments hosted inside this Fragment, so they are torn down with it, and parentFragmentManager for the container the Fragment itself lives in. Using the wrong one is how children leak or get restored into the wrong host.
• Two lifecycles, one classic bug. Collecting a Flow in lifecycleScope inside onViewCreated() looks fine until you navigate away and come back. The Fragment instance was never destroyed, so the old collector is still alive, onViewCreated() runs again, and now you have two. The updates arrive twice and can hit a view that no longer exists. Use viewLifecycleOwner.lifecycleScope with repeatOnLifecycle, which dies with the view.

The back stack case, drawn out, because it is the one people get wrong.

Replace F with G, then Back−100%+Esc

What the interviewer is really checking is that you know there are two lifecycles here, the Fragment's and its view's, and that the FragmentManager restores fragments for you. Candidates who miss the first one leak observers. Candidates who miss the second one add duplicate fragments on every rotation.

There are eleven core callbacks you should be able to list in order.

• onAttach(), the Fragment gets a reference to its host Activity.
• onCreate(), the Fragment object itself is created, no view yet.
• onCreateView(), you inflate and return the layout.
• onViewCreated(), the view now exists.
• onStart(), the Fragment becomes visible.
• onResume(), the Fragment gains focus and is interactive.
• onPause(), the Fragment is losing focus.
• onStop(), the Fragment is no longer visible.
• onDestroyView(), the view is torn down, the Fragment object can still be alive after this.
• onDestroy(), the Fragment object itself is being cleaned up.
• onDetach(), the Fragment loses its reference to the host Activity.

Two more show up depending on what you count. onViewStateRestored() runs right after onViewCreated() once the saved view hierarchy state has been restored, and onSaveInstanceState() runs on the way out to let the Fragment save state into a Bundle. Most interviewers are checking that you know the two destroy points, onDestroyView() versus onDestroy(), matter more than the exact total count.

This is really four questions bundled into one, and interviewers use it as a starting point to see how much ground you can cover before they drill into whichever area interests them.

• A Fragment is a reusable piece of UI and behavior hosted inside an Activity, with its own lifecycle that layers on top of the Activity's, onAttach(), onCreate(), onCreateView(), onViewCreated(), then onStart() and onResume() mirroring the Activity, and on the way out onPause(), onStop(), onDestroyView(), onDestroy(), onDetach().
• The Activity lifecycle is the outer container for all of this, onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(), with a Fragment's state capped by whatever state its host Activity is in.
• A View is a single drawable, interactive element, a Button or a TextView. A ViewGroup is a container that holds other Views and ViewGroups and is responsible for measuring and positioning its children.
• A Layout is a ViewGroup subclass with a specific arrangement strategy, LinearLayout stacks children in a line, ConstraintLayout positions children relative to each other or the parent using constraints, and layouts are what you inflate from XML into an actual View tree at runtime.

The follow up worth preparing for is how these pieces interact, a Fragment's onCreateView() is where you inflate its layout, and the resulting View tree only lives as long as the Fragment's separate view lifecycle, which is shorter than the Fragment object's own lifecycle since a Fragment can sit in the back stack with its view destroyed but the Fragment instance still alive.

Lifecycle.State is the enum the Jetpack Lifecycle library uses underneath the callback methods, and it is what repeatOnLifecycle() and lifecycle aware components actually check against, rather than the callback names themselves.

• INITIALIZED, the starting state right after the object is constructed, before any callback has run.
• CREATED, reached once onCreate() has run, and also the state an Activity or Fragment falls back to after onStop().
• STARTED, reached once onStart() has run, and the state it falls back to after onPause().
• RESUMED, reached once onResume() has run, this is the only state where the component is actually in the foreground and interactive.
• DESTROYED, the terminal state, reached once onDestroy() has run, an object never leaves this state.

For a Fragment specifically, this matters more than it sounds, because the Fragment's own Lifecycle and its view's Lifecycle track this enum independently. The Fragment's Lifecycle moves CREATED to DESTROYED across onCreate() through onDestroy(), while viewLifecycleOwner's Lifecycle only exists between onCreateView() and onDestroyView(). That's why repeatOnLifecycle(Lifecycle.State.STARTED) called on viewLifecycleOwner.lifecycle is the safe way to collect a Flow, the block automatically stops and restarts as the view crosses that STARTED boundary instead of you tracking callback pairs by hand.

A Fragment Lifecycle Observer watches getLifecycle(), the Fragment object's own lifecycle, which spans from onAttach() all the way to onDetach(). A View Lifecycle Observer watches viewLifecycleOwner.lifecycle, which only exists between onCreateView() and onDestroyView().

The gap between those two matters because a Fragment can be kept alive in the back stack while its view is destroyed, for example after you navigate away from it. The Fragment object survives that, the view does not.

// wrong, can outlive the view and crash or update a destroyed view
viewModel.items.observe(this) { updateList(it) }

// right, tied to the view's own lifecycle
viewModel.items.observe(viewLifecycleOwner) { updateList(it) }

If you observe LiveData or collect a Flow using the Fragment's own lifecycle instead of viewLifecycleOwner, the observer can keep firing after onDestroyView() has already torn down the view it is meant to update, which either crashes trying to touch a null binding or silently updates a view that is no longer on screen. Always use viewLifecycleOwner for anything view related, and reserve the Fragment's own lifecycle for things that genuinely need to live as long as the Fragment object does.

The right tool depends on what kind of state it is, and most real screens end up using two of these together.

• UI state that is expensive to rebuild, a list you fetched from the network, form data the user typed, filters the user applied, belongs in a ViewModel. Rotation destroys and recreates the Activity, but the ViewModel instance survives that cycle untouched, so the new Activity just reconnects to the same object and the screen redraws itself from whatever is already there.
• Small, simple values the system itself needs to restore, like scroll position or a selected tab index, belong in onSaveInstanceState(outState: Bundle). The system hands that Bundle back to you in onCreate(), or via onRestoreInstanceState(), after recreation.
• Anything that needs to survive process death, not just rotation, needs to actually be persisted, either through SavedStateHandle inside the ViewModel, which is backed by that same Bundle mechanism, or written to disk or a database.

The distinction interviewers are listening for is that a ViewModel alone is not enough, it protects you from rotation but not from the system killing your process in the background, which is what onSaveInstanceState() and SavedStateHandle are actually for.

A ViewModel is a class that holds and manages UI-related data so that it survives configuration changes, like a screen rotation, without you having to manually save and restore it.

Without a ViewModel, if you load a list of results in onCreate() and the user rotates the phone, the Activity gets destroyed and recreated, and you'd have to fetch that data all over again, or stash it in a Bundle, which only works for small amounts of data. A ViewModel is scoped to the Activity or Fragment's lifecycle, but the framework keeps the same ViewModel instance alive across a configuration change and only actually clears it when the screen is truly finishing, calling onCleared() at that point so you can cancel jobs or release resources.

The other big benefit is separation of concerns. Your ViewModel holds the state and the logic for producing it, usually exposed as LiveData or StateFlow, and your Activity or Fragment just observes that state and renders it. That keeps business logic out of the Activity, which makes it testable without needing an actual Android device or emulator, since ViewModel itself doesn't hold a reference to a View or Context.

class UserViewModel : ViewModel() {
    private val _user = MutableStateFlow<User?>(null)
    val user: StateFlow<User?> = _user

    fun loadUser(id: String) {
        viewModelScope.launch {
            _user.value = repository.getUser(id)
        }
    }
}

One thing worth flagging. A ViewModel is not for long-term persistence. It survives rotation, but it does not survive process death or the user leaving the app entirely. That's what SavedStateHandle or actual storage is for.

A ViewModel survives configuration changes because it's not actually owned by the Activity. It's held in a separate ViewModelStore object that the Android framework keeps alive across the destroy and recreate cycle, and only throws away when the Activity is finishing for real.

Your Activity or Fragment implements ViewModelStoreOwner, which just means it holds a ViewModelStore, essentially a map of ViewModel instances keyed by class name (or a key you provide). When you call by viewModels() or ViewModelProvider(this).get(MyViewModel::class.java), the ViewModelProvider first checks that store. If a ViewModel already exists there, it hands you back the same instance instead of creating a new one.

On a configuration change, the framework retains that ViewModelStore in a special non-configuration instance and reattaches it to the new Activity instance that gets created right after. So the Activity object itself is brand new, but the ViewModelStore, and every ViewModel inside it, is literally the same object as before. That's the whole trick. Nothing is being serialized or restored. It's just not thrown away in the first place.

The store only gets cleared, and onCleared() called on each ViewModel, when the Activity is actually finishing, meaning isFinishing() is true and it's not just a rotation. That's also when viewModelScope, which is backed by a Job tied to onCleared(), gets cancelled, which is why any coroutines you launch in viewModelScope stop automatically instead of leaking.

You scope the ViewModel to the shared host instead of to each Fragment individually, usually the parent Activity, so both Fragments get back the same instance.

class SharedViewModel : ViewModel() {
    val selectedItem = MutableLiveData<Item>()
}

class FragmentA : Fragment() {
    private val sharedViewModel: SharedViewModel by activityViewModels()
}

class FragmentB : Fragment() {
    private val sharedViewModel: SharedViewModel by activityViewModels()
}

activityViewModels() asks the hosting Activity's ViewModelStore for a SharedViewModel, not the Fragment's own store. Since both Fragments point at the same store and the same key, ViewModelProvider hands back the identical instance to each of them. FragmentA writing to selectedItem is immediately visible to FragmentB observing it, no direct Fragment to Fragment reference needed.

If two Fragments belong to the same navigation graph but not the same Activity relationship you want to lean on, navGraphViewModels() does the same trick scoped to the graph's back stack entry instead, which is tighter than sharing at the Activity level.

A ViewModel does not survive whenever its owner is finished for good, rather than just recreated, and it never survives process death at all.

• The user presses back and the Activity finishes, or you call finish() yourself, onCleared() runs and the ViewModel is gone.
• A Fragment is removed through a transaction that did not add it to the back stack, so it is not coming back the way a back stack entry would restore it.
• The system kills the whole process in the background to reclaim memory. Rotation survives because the process itself stays alive and the retained store just gets handed to the new instance, process death takes the entire process, retained store included, with it.

The one thing that reliably survives process death, unlike the ViewModel object itself, is whatever you stored in its SavedStateHandle, since that is backed by the same saved instance Bundle mechanism the system writes to disk before killing the process. So a ViewModel surviving rotation is not the same guarantee as a ViewModel surviving everything, it is specifically scoped to configuration changes, not to the process being killed.

ViewModelProvider(owner).get(MyViewModel::class.java) looks up an existing instance in the owner's ViewModelStore by key, and only creates a new one through the factory if nothing is there yet. The owner, an Activity or a Fragment, is a ViewModelStoreOwner, and that store is what actually holds the ViewModel objects.

The retention trick is that the ViewModelStore itself is not tied to the Activity or Fragment instance that gets destroyed on a configuration change. It is stashed in a special non configuration instance the framework keeps aside specifically to survive recreation. So when the Activity is destroyed and rebuilt after a rotation, the new Activity instance is handed back the same ViewModelStore, and ViewModelProvider finds your ViewModel already sitting in it instead of creating a fresh one.

onCleared() is called, and the store is actually thrown away, only when the owner is going away for good, the Activity finishes because the user pressed back or you called finish(), or the Fragment is removed and not on the back stack. A rotation never triggers that path, which is exactly why a ViewModel survives rotation but not a deliberate exit, and never survives process death, since the whole process including that retained store is gone at that point.

Process death is the system killing your app's entire process while it is in the background, usually to reclaim memory for whatever the user is actively using. It is different from the destroy and recreate cycle a rotation triggers, that keeps the process alive and just rebuilds the Activity, process death ends the process itself, taking every in memory object with it.

That distinction matters because of what survives each one.

• A ViewModel survives rotation, since its retained store lives inside the process, but it does not survive process death, the whole process including that store is gone.
• onSaveInstanceState() state does survive process death, because the system writes that Bundle out to disk before killing the process, and hands it back to onCreate() if the user returns to that same task later.
• SavedStateHandle inside a ViewModel is the bridge between the two, it is backed by that same saved Bundle mechanism, so values you put there come back even after a real process death, not just a rotation.

You can trigger process death on purpose while debugging by running adb shell am kill <package name> after backgrounding the app, then reopening it from Recents, which is the honest way to check whether your screen actually restores state instead of just surviving rotation.