Change the wallpaper on Android 12, return to the app you were using, and the activity gets wiped and rebuilt. That is the behaviour described in a Stack Overflow question flagged by a developer on CommonsWare. The activity tears down even though no android:configChanges value in the manifest appears to suppress it.
For most users this is invisible. For developers whose apps rely on keeping state across rotations and similar events, it is a real problem.
At a glance
- The trigger is changing the system wallpaper while an app is in the background.
- The foreground activity is destroyed and recreated when the user returns to it.
- No documented android:configChanges value suppresses the rebuild.
- The effect is most likely linked to Material You's dynamic theming.
Background: configuration changes in Android, briefly
Every Android developer meets the configuration change early. Rotate the device, change the locale, swap dark mode, and the activity is destroyed and recreated so the new resources can be loaded. The standard escape is to declare android:configChanges in the manifest, which lets the activity handle the change in onConfigurationChanged rather than going through the destroy-rebuild cycle.
The catch is that configChanges only covers events Android knows about. New behaviours sometimes slip in without a matching flag, and developers are left with an activity that rebuilds itself for reasons that look like a configuration change but officially are not.
What it means for you
If your app holds transient state in fields that do not survive onSaveInstanceState, you will see data loss. ViewModel-scoped state is safe. Anything kept in the activity itself—including unsaved form input—is gone.
The workaround until Google clarifies is the same one the SO poster suggested: try undocumented configChanges values such as uiMode, screenLayout or fontScale. None of them were confirmed to cover this case, but they are the only knobs available. The other option is to listen for onConfigurationChanged and pull the new wallpaper-derived colours through the Material You APIs instead of relying on a fresh activity.
Who should care
| App type | Risk level | Primary concern |
|---|---|---|
| Notes, editors, messaging | High | Unsaved user input lost |
| Games mid-session | Medium-High | Progress state may reset |
| Media players | Low | Playback state usually ViewModel-backed |
| Background services | None | No foreground activity to destroy |
Our analysis
This is a textbook example of platform behaviour leaking into app code without a clean off switch. Google needs to recreate the activity when the wallpaper changes because Material You must recompute the colour palette and push it to the foreground window. A configuration change is one way to do that. The trade-off is that apps lose transient state with no way to opt out.
The implication is asymmetric: Google gains a consistent theming system, while developers inherit a rebuild they cannot suppress through documented channels. Until Google ships a dedicated flag—something uiMode-style that lets apps opt into manual handling—the practical advice is blunt. Assume any Android 12 device can rebuild your activity the moment the user glances at the launcher. Anything you cannot afford to lose must already live in a ViewModel or saved instance state.
The lesson generalises beyond this specific bug: treat every Android release as a prompt to audit what survives a configuration change. Platform priorities and developer experience do not always align.
What to watch next
Watch the Android issue tracker and the AOSP source for a new configChanges flag tied to wallpaper or theme. If Google ships one, you can opt back into manual handling and skip the rebuild. Until then, harden your state management and treat the activity as disposable.
Key takeaways
- The behaviour is most likely tied to Material You, not a generic Android 12 bug.
- No documented android:configChanges value stops the activity rebuild today.
- Move important state out of the activity and into a ViewModel.
- Audit saved instance state every release; this is the cheapest insurance you can buy.
Frequently asked questions
Is the wallpaper rebuild bug fixed?
The original report references a follow-up post covering the resolution, suggesting later Android 12 releases or Android 13 may behave differently. Check the CommonsWare follow-up for the definitive answer.
Does this affect every Android 12 device?
It was reported on the shipping Android 12 release. Devices on older versions that do not apply the wallpaper-derived palette are not affected.
Should I add android:configChanges to suppress it?
Not without a confirmed flag. Adding undocumented values can mask other behaviour changes and is not worth the risk.
Will using Material You in my own app trigger the same rebuild?
No. The rebuild is triggered by the system applying a new palette to your activity, not by anything your code does inside the activity.