Activity rotation: what happens to EditText text?

WHAT THIS TESTS: This question tests whether you understand the Activity lifecycle during configuration changes and the difference between framework-automatic view state saving and developer-managed state persistence. Interviewers want to hear that rotation destroys and recreates the Activity, that standard views with IDs get their state saved automatically, and that you know the modern alternatives to manual Bundle juggling.

A GOOD ANSWER COVERS: First, state that a screen rotation triggers a configuration change, so the system destroys the current Activity instance and creates a new one, calling onPause, onStop, onDestroy, then onCreate, onStart, and onResume. Second, explain that by default an EditText will preserve its entered text automatically through the framework's built-in onSaveInstanceState and onRestoreInstanceState mechanism, but only if the EditText has an android:id attribute assigned in the layout; without an ID the view state is not saved. Third, describe the manual approach for data that is not automatically saved or for custom logic: override onSaveInstanceState to place values into the outState Bundle, then read that Bundle in onCreate or onRestoreInstanceState to repopulate the field. Fourth, mention the modern architecture approach using a ViewModel, which survives configuration changes, and pair it with the Saved State module for ViewModel if the data must also survive process death.

COMMON WRONG ANSWERS: A major red flag is claiming the text is always lost by default; this shows a lack of familiarity with how the framework handles view state. Another red flag is immediately jumping to SharedPreferences, Room, or a database to store transient text for a rotation; persistent storage is inappropriate for temporary UI state. Similarly, suggesting that a static variable or a singleton should hold the text indicates poor understanding of memory leaks and lifecycle boundaries.

LIKELY FOLLOW-UPS: The interviewer may ask how ViewModel differs from onSaveInstanceState, which opens a discussion about memory limits of Bundles versus in-memory objects and process death behavior. They might also ask what happens if the user puts the app in the background and the system kills the process, or how Jetpack Compose handles state restoration with rememberSaveable.

ONE CONCRETE EXAMPLE: Suppose an Activity contains an EditText with android:id="@+id/name_input". When the user types "Alice" and rotates the device, the Activity is torn down and rebuilt. Because the EditText has an ID, the framework saves "Alice" in the instance state Bundle without any code from you, and the new Activity's EditText shows "Alice" after onResume. If you also needed to preserve a custom counter integer, you would override onSaveInstanceState, call outState.putInt("counter", count), and restore it in onCreate by reading savedInstanceState.getInt("counter", 0).