What happens to an Activity and its text on screen rotation?

What's really being asked

This question tests your fundamental knowledge of the Android Activity lifecycle, specifically how the system handles configuration changes like screen rotation. The interviewer is looking for three things: 1) Do you know that the Activity is destroyed and recreated by default? 2) Do you know the built-in mechanisms for saving UI state (onSaveInstanceState)? 3) Do you know the modern, lifecycle-aware architectural component for handling this (ViewModel and SavedStateHandle)? It separates candidates who just write code from those who understand the platform's architecture.

The full answer

A strong answer has four parts. First, explain that on screen rotation, the system destroys the current Activity instance and creates a new one. The lifecycle methods called are onPause(), onStop(), onSaveInstanceState(), onDestroy(), followed by onCreate(), onStart(), and onResume() for the new instance. Second, mention that for an EditText with a unique ID, the Android framework automatically saves its content in the onSaveInstanceState() bundle and restores it. This is a convenience for simple cases. Third, introduce the modern, recommended approach: using a ViewModel. Explain that a ViewModel is scoped to the Activity/Fragment and survives configuration changes, making it the ideal place to hold UI state. The text from the EditText should be observed and updated in the ViewModel. Fourth, for process death survival, mention using the SavedStateHandle within the ViewModel, which persists state through the same mechanism as onSaveInstanceState but integrates cleanly with the ViewModel.

The mistakes people make

A major red flag is stating the Activity is just paused and resumed. This is incorrect; it's fully recreated. Another common mistake is suggesting to save the state in onPause() or onStop(). These methods are for saving persistent data, not for transient UI state, and are not guaranteed to be called before the process is killed. Relying solely on the automatic EditText behavior without being able to explain the underlying onSaveInstanceState mechanism is a sign of a junior developer. Finally, saying you would handle the configuration change yourself by setting android:configChanges="orientation|screenSize" in the manifest is a huge red flag. While this prevents recreation, it's considered a last resort that often leads to bugs.

What usually comes next

"What's the difference between saving state in a ViewModel versus in onSaveInstanceState?" (Answer: ViewModel survives configuration changes, but not process death. onSaveInstanceState survives both, but is for small amounts of data). "When would you ever use onSaveInstanceState directly now?" (Answer: For custom views, or when not using Jetpack Architecture Components. SavedStateHandle is the modern bridge). "How much data can you store in onSaveInstanceState?" (Answer: It's meant for small amounts of data. The limit is around 1MB on recent Android versions, but you should aim for much less, a few kilobytes at most, as it impacts performance).

A concrete example

By default, the Activity is destroyed and recreated. The text in the EditText is usually saved. This is because TextView (the parent class of EditText), if it has an ID set in XML, implements onSaveInstanceState() to save its content. The system calls this before destroying the activity. When the new activity is created, its onCreate(savedInstanceState) receives the bundle, and the EditText automatically restores its state. The correct way to manage this yourself is to have a MyViewModel with a MutableStateFlow<String>. The Activity observes this state and updates the EditText. An addTextChangedListener on the EditText updates the ViewModel's state flow. This way, when the Activity is recreated, it gets a new EditText but connects to the same ViewModel instance, which still holds the text.