What the interviewer is testing

The interviewer is checking whether you understand what each lifecycle state means and can place work according to visibility, user interaction, and resource ownership.

A strong answer goes beyond reciting callback order. It explains where setup and cleanup belong, recognises that configuration changes create a new Activity instance, and avoids treating lifecycle callbacks as storage for business logic.

❌ Common mistake

If they ask you to elaborate

Think of each callback as Android notifying you that the Activity has entered a different state. The callback names matter, but understanding the state transition and the responsibility that comes with it is what interviewers are really assessing.

The normal launch path is:

onCreate() → onStart() → onResume()

When another screen fully covers the Activity, it usually moves through:

onPause() → onStop()

If the user returns, the existing instance normally receives:

onRestart() → onStart() → onResume()

If the Activity finishes, it proceeds toward onDestroy(). The exact path depends on what happens: a partially covering window may trigger onPause() without onStop(), while multi-window mode means an Activity can remain visible without being the currently resumed Activity.

A useful rule is to acquire and release resources symmetrically. Work started in onStart() should normally stop in onStop(); work started in onResume() should normally stop in onPause().

A configuration change, such as a rotation or window-size change, usually destroys the current Activity instance and creates a new one. A ViewModel can retain screen state across that recreation, but it does not survive system-initiated process death. Restorable UI state belongs in saved state APIs, while durable application data belongs in persistent storage.

Code example

class OrdersActivity : AppCompatActivity(R.layout.activity_orders) {
    private val viewModel: OrdersViewModel by viewModels()
    private lateinit var locationUpdates: LocationUpdates

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect(::render)
            }
        }
    }

    override fun onStart() {
        super.onStart()
        locationUpdates.start()
    }

    override fun onStop() {
        locationUpdates.stop()
        super.onStop()
    }

    private fun render(state: OrdersUiState) {
        // Render the latest state into the existing view hierarchy.
    }
}

The ViewModel owns screen state instead of the Activity instance. repeatOnLifecycle collects only while the lifecycle is at least STARTED, cancels the collection when the Activity stops, and restarts it when the Activity becomes visible again.

The location resource is acquired in onStart() and released in onStop() because this example needs updates only while the screen is visible. A resource needed exclusively while the user can interact would instead be paired across onResume() and onPause().

Follow-up questions

What separates a senior answer

Key takeaways

Learn more