Regarding this comment, if this is something that is safe to do, could we get some explanation/details about it on the official documentation? I haven’t found anything on the official docs but it seems like it’s a pretty interesting difference that we can take advantage of if we’re compose-first Activities.

I tried this and didnt see any issues in a few beta releases, but the lack of documentation made me remove it before the production release - so +1 for more docs!

same; this question gets asked a lot on my team, and its awkward not having official docs to point to for this important info

Yeah this is exactly my issue too. I wouldn’t feel comfortable introducing this:

android:configChanges="colorMode|density|fontScale|fontWeightAdjustment|keyboard|keyboardHidden|layoutDirection|locale|mcc|mnc|navigation|orientation|screenLayout|screenSize|smallestScreenSize|touchscreen|uiMode"

to my team without proper documentation behind it. I haven’t found issues myself but I know not to trust my own testing when it comes to stuff like configChanges.

In the meantime you can check the source code, how it works: https://twitter.com/arkann1985/status/1387150638879059969 https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]/compose/ui/platform/AndroidCompositionLocals.android.kt;l=97

FWIW the Tivi sample from Chris Banes does this: https://github.com/chrisbanes/tivi/blob/f0170cde2cffe6facb5762a8d2e5825d430d7378/app/src/main/AndroidManifest.xml#L35 You can also see a few places in the app where it uses the LocalConfiguration inside the Composables to "dynamically react" to the config change.

fontWeightAdjustment

is not specified in this tivi sample, I wonder if it’s by accident or not

Do note that the factor to consider is not only whether you are Compose-first. The factor is whether you use any (potentially third-party) XML-based views at all in your app. If you do, then there is a chance that those views are not equipped to handle this situation (i.e, they assume that config changes cause activity recreation and hence they do not override the View's

onConfigurationChanged

).

In those situations you can react to changes in LocalConfiguration and call that method yourself

I think

View#onConfigurationChanged

is protected. Moreover even if you could call it, you don't know if the View reacts to it at all.

You can use

key(LocalConfiguration.current) {
    AndroidView()
}

to force recreate the view on configuration change.

Interesting quirk I got into while doing this. When I switch to dark mode, and at the same time using this theme wrapper

MdcTheme(setDefaultFontFamily = true, content = content)

I am actually not getting the updated version of the system theme. Tested it by doing this

val isLight = MaterialTheme.colors.isLight
val isSystemInDarkMode = isSystemInDarkTheme()
SideEffect {
    d { "isSystemInDarkMode: $isSystemInDarkMode" }
    d { "isLight: $isLight" }
}

and it doesn’t change when I change the phone’s dark/light mode When I change it to a plain

MaterialTheme(
    colors = if (isSystemInDarkTheme()) { darkColors() } else { lightColors() },
    content = content
)

The logging does work as it should, and the UI works as well provided I do the key() trick you’re showing above.

MdcTheme

seems to create and remember the theme parameters using this key which may be the culprit as to why it doesn’t recompose with the changes. This feels like a bug, or am I missing something super obvious? p.s I am displaying a simple

AndroidViewBinding(GenericErrorBinding::inflate)