Handling Configuration Changes in Android

Configuration changes occur when the device's state shifts in a way that affects available resources. Screen rotation, locale switches, dark mode toggles, and font size adjustments all qualify. By default, the Android system destroys and recreates the current Activity when a configuration change happens, which causes transient UI state to be lost unless the application explicitly preserves it. By the end of this lesson, you will be able to:

• Explain what triggers a configuration change and why the system recreates the Activity.
• Use ViewModel to retain data across configuration changes.
• Apply onSaveInstanceState and rememberSaveable for lightweight UI state.
• Evaluate when android:configChanges is appropriate and what trade offs it introduces.
• Describe how SavedStateHandle bridges ViewModel and saved instance state.

What Triggers a Configuration Change

Configuration changes include screen rotation, locale switches, dark mode toggles, font scale adjustments, keyboard availability changes, and screen density changes. Multi window transitions on foldable devices and tablets also trigger configuration changes when the available display area changes significantly.

Why the System Recreates the Activity

When a configuration change occurs, the system needs to reload resources that depend on the new configuration. Rotating from portrait to landscape may select different layout files, string resources, or drawable qualifiers. The simplest way for the system to guarantee correct resources is to destroy the Activity and create a new instance with the updated Configuration object.

This means the Activity goes through onPause, onStop, onDestroy, and then a fresh instance goes through onCreate, onStart, onResume. Any data stored only in Activity fields is lost. Understanding this lifecycle is essential for choosing the right state preservation strategy.

Not all configuration changes trigger the same set of resource reloads. A screen rotation may load different layout qualifiers, while a locale change reloads string resources. A dark mode toggle reloads theme attributes and color resources. Font size changes affect dimension resources scaled by sp. The system treats all of these uniformly by destroying and recreating the Activity unless the manifest explicitly opts out. Each type of change is identified by a constant in the Configuration class, such as CONFIG_ORIENTATION, CONFIG_LOCALE, or CONFIG_UI_MODE, and the system passes the updated Configuration object to the new Activity.

ViewModel for Surviving Configuration Changes

ViewModel is scoped to the Activity's ViewModelStoreOwner and survives configuration driven destruction. The ViewModelStore is retained by the framework's NonConfigurationInstances mechanism, so the same ViewModel instance is available to the new Activity:

class CounterViewModel : ViewModel() {
    private val _count = MutableStateFlow(0)
    val count: StateFlow<Int> = _count.asStateFlow()

    fun increment() {
        _count.value++
    }
}

The ViewModel holds the counter value through rotation and other configuration changes. It is cleared only when the Activity finishes permanently, at which point onCleared() is called.

ViewModel is the right choice for data that is expensive to recompute, like network responses, database query results, or computed UI state. It is not suitable for data that must survive process death, because the ViewModel is destroyed when the process is killed.