What happens to `AndroidView`s during orientation changes? Are they re-measured with swapped width/h...

# compose

[natario1]

What happens to `AndroidView`s during orientation changes? Are they re-measured with swapped width/height? Drawn with rotated canvas?

My activity has android:configChanges="(everything)" as suggested by compose team, so compose handles UI rotations. But I'm seeing issues with `SurfaceView`s in the compose hierarchy. Would love to have some insight about what's happening under the hood

[Adam Powell]

They're measured and laid out as usual. Can you describe the issues you're seeing?

[natario1]

Seeing different issues whenever SurfaceView is involved (camera preview is rotated, exoplayer preview messed up). They only happen when config change is managed by compose, that's why I was asking for info. How does compose know that there was a config change?

To answer my original question, looks like `View`s are not recreated, they're just remeasured with swapped dimensions, then laid out and drawn in this rotated environment. In the surface world this means that the underlying surface is the same and you just get a new surfaceChanged callback with new dimensions.

[Adam Powell]

It knows because the underlying views receive onConfigurationChanged and that propagates to the LocalConfiguration, plus the views hosting the compose content remeasure and relayout for the new available space.

[Adam Powell]

`AndroidView`s indeed are not recreated and are treated the same way. This has always been fine to do with views and handling your own config changes, the reasons to recreate are usually for things read from config-variant resources during view construction/inflation.

[romainguy]

In the surface world this means that the underlying surface is the same and you just get a new surfaceChanged callback with new dimensions.

[romainguy]

It shouldn’t be the case. Like Adam said, the SurfaceView is measured and laid out again, so you should be getting a new Surface

[romainguy]

then laid out and drawn in this rotated environment.

[romainguy]

As far as the UI toolkit is concerned, there’s no “rotation”. After the configuration change, you are just using a screen that’s now wider than it is tall.

[natario1]

That'd be great but it's not what I'm seeing. I get the same Surface, updated with flipped size after a surfaceChanged callback. I see now that this is not related to compose, though compose guidelines around android:configChanges make you hit it.

Just for context, to fix camera preview I had to restart it in a DisplayListener, because I assumed that the display rotation can't change within the lifecycle of the surface. I fear I'll have to do something similar with video rendering issue.

Basically android:configChanges was so discouraged that most people/libs have 0 experience with it, it seems. Thanks for helping guys

[romainguy]

But again, that’s no different than having to handle a layout size change.

[romainguy]

updated with flipped size after a surfaceChanged callback

[romainguy]

Don’t read too much in the Surface object itself, what matters are the underlying buffers. The size change means you’ll produce new graphic buffers at the new dimensions

[romainguy]

The point is that anything that uses SurfaceView should properly handle size changes, either because of rotation, or simply because of a layout change

[natario1]

Yeah 👍 I just didn't expect that with android:configChanges a surfaceChanged event can also mean that display rotation changed (my gl renderer uses it)