Theme change isn't applied immediately anymore and requires a restart, regressing from 1.2.2

[Porkepix]

Describe the bug
This is a regression from 1.2.2; in version 1.2.2 switching the theme was applying the change immediately. With version 1.3.0 when changing the theme, no change is immediately visible and user needs to restart the application (kill it then relaunch) to see the theme correctly changed.

To Reproduce
Switch theme
Notice it's not immediately applied
Restart the application (kill it, relaunch it)
Theme now have changed

Expected behavior
Change should be visible immediately, as it was in version 1.2.2.

Versions
Latest release from F-droid (1.3.0) on Android Oreo (8.0), stock build

Affirmation
I have checked other issues for this project (open and closed) and I cannot find one that matches the problem I am reporting.

[nikclayton]

I can't reproduce this on an emulator running Android Oreo, can you get a video of it happening?

There are some other preferences that are supposed to take effect immediately (font family, UI text size). Do they work as expected for you, or do you also need to restart the app?

[Porkepix]

I can't reproduce this on an emulator running Android Oreo, can you get a video of it happening?

There are some other preferences that are supposed to take effect immediately (font family, UI text size). Do they work as expected for you, or do you also need to restart the app?

I don't have anything to record my screen at hand, and I'd think the description is pretty clear and straightforward?

The font question is interesting: if I change the font family or size, no immediate change is visible.
But then, if I go back from preferences, still no changes and if I return to preferences, font have changed (both in family and size); the theme is still the same as on startup though, even if I changed it.

Can't tell if this font behavior was that way on 1.2.2 too as I didn't changed that back then.

[nikclayton]

Huh. Works in debug mode, doesn't work in release mode. That's weird...

[nikclayton]

For future me coming back to this for a description longer than a code comment will allow.

Defining the shared preferences listener as:

private val listener = ...

and registering it does not create a strong reference to the field. This is fine in debug mode, but breaks in release after R8 has had a chance to optimise things. With no strong reference, and no writes to listener, it is eventually garbage collected, dropping the listener and stopping any further preference changes from being emitted to the changes shared flow.

Annotating the field with @Keep seems to be sufficient. See https://issuetracker.google.com/issues/137836288