IssueTracker

More generally, changing wallpaper results in an effect that feels a lot like a configuration change: activities get restarted. Yet, there does not seem to be an actual configuration change that maps to changing wallpaper.

The attached sample app just has an activity that shows its creation time. In the manifest, I have set up every config change that I can find in the Android 12 source code:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.commonsware.android.myapplication">

  <application
    android:allowBackup="false"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:roundIcon="@mipmap/ic_launcher_round"
    android:supportsRtl="true"
    android:theme="@style/Theme.MyApplication">
    <activity
      android:name=".MainActivity"
      android:configChanges="fontWeightAdjustment|fontScale|colorMode|layoutDirection|touchscreen|density|orientation|uiMode|mcc|mnc|locale|keyboard|keyboardHidden|navigation|screenLayout|fontScale|screenSize|smallestScreenSize"
      android:exported="true">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>

</manifest>

This app correctly ignores things like toggling dark mode. Yet, it still seems to undergo a configuration change when the wallpaper changes.

Update: on Android 12, changing wallpaper results in an unblockable configuration change. Apps that assume that they can opt out of all configuration changes will need to be adjusted.

See this Stack Overflow question and this blog post for more.

I'll just point out that this bug is affecting a lot more than just games. I've seen the following issues so far:

• Text entered in a private Twitter chat would be cleared and the keyboard would be hidden.
• My exercise app ("Starting Strength Official") would go from showing whichever screen I was currently on to showing the apps splash screen until I killed the app and restarted it.
• While scrolling the main feed in the YouTube app, the feed would refresh, and I'd be at the top of the newly refreshed feed.

Additionally, I've seen the screen refresh in these apps, though it didn't result in what I was doing at the time being negatively affected in a significant manner since I was just scrolling:

• Google Drive (PDF reader)
• Microsoft Outlook

It seems quite likely that, many other apps are affected (included many in a negative manner) since these are just the apps I've interacted with in the past couple days since updating.

Additional problematic app behavior due to this issue (copied from dup report 207645506):

• Facebook lite - The previously reported broken behavior is gone, instead the screen locks.
• Google Maps - map resets to the current GPS location.
• YouTube - screen flickers and video pauses.
• Netflix - the video stops, the screen blanks, then the video starts replaying a few seconds back from where it stopped.
• YouTube music - audio or video stops and the application goes back to the main screen with any playlist cleared.
• Slack - if a huddle is in progress, you are thrown out of the huddle and out of the application, otherwise just the workspace switcher sidebar appears unexpectedly.
• Juice SSH (com.sonelli.juicessh) - it starts two(!!) New sessions to the same connection that was active, though it didn't close the active connection.
• Instagram - feed gets reset to the top new post instead of wherever you scrolled down to.

Please check for this issue on the latest beta build / latest stable build and share the new bugreport, If the issue persists.

Please provide the information as requested in comment #34, for us to further investigate this issue. Unfortunately the issue will be closed within 7 days if there is no further update.

This remains an issue. The problem is that the system changes the RRO, which kills all apps. This code flow does not follow the standard configuration flow, so developers can neither opt out nor can they handle it directly.

The ideal solution is probably to handle this as a configuration change, so that apps can use the standard lifecycle. If that's not feasible for some reason, it would help to at least have some kind of opt out to say an app does not use any of the resource values that are changed by the RRO, so the app does not need to be killed.

Thank you for reporting this issue. We have a fix rolling out in the upcoming release.

How has this been fixed? Anything app and library developers need to know?