Configuration changes

Lifecycle and app components Junior Kotlin 2.0+ API 24+ Reviewed By Best Latest Apps

Pick the fix

A form loses its typed text when the user switches the phone to dark mode. The team locked the screen to portrait to fix rotation. What's the right fix?

Options
Hint 1 of 1

Is rotation the only thing that recreates an Activity?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Keep the input in rememberSaveable or a ViewModel's SavedStateHandle

Correct. Dark mode is a configuration change too; state has to live where it survives recreation.

Why not the others?
  • B Also lock dark mode in the manifest. There are many configuration changes; you can't lock them all.
  • C Save the text in a static field. It survives recreation but not process death, and it leaks between screens.
  • D Call recreate() yourself. That's what's causing the loss.
Two scenarios: rotation and switching to dark mode. Both recreate the Activity, and the grid shows the same survival.

Illustrative, based on Compose and Android rules; not a device recording

Text version

Rotate

  1. A onPause
  2. A onStop
  3. A onDestroy
  4. A' onCreate
  5. A' onStart
  6. A' onResume

Dark mode on

  1. A onPause
  2. A onStop
  3. A onDestroy
  4. A' onCreate
  5. A' onStart
  6. A' onResume
What survives
StateRotateDark mode on
local var✕ lost✕ lost
remember✕ lost✕ lost
rememberSaveable✓ kept✓ kept
ViewModel✓ kept✓ kept
SavedStateHandle✓ kept✓ kept
Room / disk✓ kept✓ kept

30-second answer

By default, the Activity is destroyed and recreated with new resources for the new configuration: orientation, screen size, locale, dark mode or font scale. ViewModels survive; views and remember state don't; rememberSaveable and saved instance state are restored. The right fix is to keep state in the right holder, not to block recreation.

Practise saying it · 35 s. No recording, just a timer

Explain configuration changes.

Say your answer out loud, then check which of these points you covered:

  • Activity is recreated with new resources
  • ViewModel survives; remember doesn't
  • Many triggers, not only rotation
  • configChanges is a trade-off

Deep dive

android:configChanges in the manifest stops recreation for listed changes, and you get onConfigurationChanged instead. It's a legitimate choice for some cases (Compose-only apps, video players) but you must then handle every resource change yourself.

Rotation isn't the only trigger: resizing in multi-window, foldables and changing the system language all recreate.

Test with 'Don't keep activities' and by rotating mid-request.

Locking orientation doesn't remove the problem, because other configuration changes still recreate.

Common mistakes

  • Declaring configChanges="orientation" to avoid fixing state handling.
  • Assuming that locking portrait removes all recreation.
  • Keeping screen data in Activity fields.

Senior take & follow-ups

Explain recreation, then where each kind of state lives. Mention that orientation lock isn't a fix.

Follow-up questions

Think of your answer first, then open the hint.

  1. Which configuration changes recreate the Activity?

    Show hint

    Orientation, screen size, locale, night mode, font scale and more.

  2. When is configChanges reasonable?

    Show hint

    When the UI fully adapts itself, such as a video player or a Compose-only app that reads configuration from Compose.

Related questions

Suggest a fix if something here is wrong or out of date.