IssueTracker

We could add an API to make the weighted distance customizable, aosp/3271691 has more info.

Here's my temporary solution on the problem. I provide a custom context that returns the correct resources:

@Composable
fun rememberThemeAwareContext(isDarkTheme: Boolean): Context {
    val context = LocalContext.current

    return remember(context, isDarkTheme) {
        ThemeAwareContext(context, isDarkTheme)
    }
}

private class ThemeAwareContext constructor(
    context: Context,
    isDarkTheme: Boolean,
) : ContextWrapper(context) {
    private val configurationContext = Configuration(context.resources.configuration)
        .let { conf ->
            conf.setNightMode(isNight = isDarkTheme)
            context.createConfigurationContext(conf)
        }

    override fun getResources(): Resources = configurationContext.resources

    override fun getTheme(): Resources.Theme = configurationContext.theme
}

private fun Configuration.setNightMode(isNight: Boolean) {
    val notUiNightMask = Configuration.UI_MODE_NIGHT_MASK.inv()
    val uiModeWithoutNight = uiMode and notUiNightMask
    val flag = if (isNight) Configuration.UI_MODE_NIGHT_YES else Configuration.UI_MODE_NIGHT_NO
    uiMode = uiModeWithoutNight or flag
}

Which I embed into my theme like this:

CompositionLocalProvider(
    LocalContext provides rememberThemeAwareContext(isDarkTheme = isDarkTheme),
) {
    MaterialTheme(

I've only faced a single problem and only on API 33: LocalImageVectorCache sometimes caches the images. This is especially irritating since I not only use this technique for overriding system theme, but also for a couple of dark-only screens - they look the same both in dark and light modes.

The only thing I seem to be missing is that LocalImageVectorCache and obtainImageVectorCache would be public, then I could provide one of the two cache objects depending on the needed schema in each case.

Any update on this? Looking at this ticket, it's been a year since the last update and it looks like a solution hasn't been started yet? Would be great to see this - it's a key feature that's missing from the Android developer experience!

One workaround that we have noticed to be effective is to use non-compose methods to switch the app's appearance

UiModeManager#setApplicationNightMode (API level 31 and above), AppCompatDelegate.setDefaultNightMode() (API level 30 and below). But AppCompatDelegate requires extending AppCompatActivity and using AppCompat theme.

I'm not sure how the issue as described can be solved, the 'app theme' is just a selection of properties used inside Compose. Part of the intent behind the design of APIs such as MaterialTheme is that it's valid to have more than just two themes for light and dark, and these shouldn't be based on the system definition of dark (night) theme.

What is the motivation for using the -night qualifier, if you don't rely on the system theme, and you allow user overrides for light / dark? Instead you probably want these to be tied to your theme object, similar to how MaterialTheme provides colors / shapes / typography. That way you can support more than two configurations here, and icons can be unique per theme as well