Post

It was great to see both familiar faces and new ones at #dcnyc25 last week - especially to see how everyone's figuring out what #AndroidDev will look like with the new tools are moving at a blistering speed. The slides for my talk are available here: alex.vanyo.dev/talks/configurationchanges

Alex Vanyo

@vanyo.dev

1 July 2025

...and the source for my slides is here! github.com/alexvanyo/al... I built my talk with Compose itself, using @bnorm.dev's github.com/bnorm/storyb... project. Shared elements and transitions galore, directly using the Compose APIs for it.

Alex Vanyo

@vanyo.dev

TL;DR: if you know the promise you are making, you can opt-out of Activity recreation via android:configChanges. The golden rule to do so properly in Compose is to have everything using configuration depend on a snapshot-state-backed source for it, like LocalConfiguration and LocalResources.

1/7/25, 10:21 pm0 reposts0 likes

Alex Vanyo

@vanyo.dev

1 July 2025

It's also not all or nothing! Most Android apps can probably opt-out of recreation for some configuration changes that don't need apps to do much (if anything), like keyboard, touchscreen, and colorMode. That'd immediately solve a whole class of bugs for physical keyboards and connected displays.

Alex Vanyo

@vanyo.dev

1 July 2025

Some are a lot trickier to handle directly - and it's pretty easy to write code that works assuming that recreation happens. Opting out of recreation is also a promise that new code works properly with updating in-place when the configuration changes.

Alex Vanyo

@vanyo.dev

1 July 2025

And to reiterate again: configuration changes will happen, and you have to react to them. For each type of configuration change, your options are: - using Activity recreation, and properly preserving state through it - opting-out of recreation, and updating everything in place