I have a very noob question. What is the easiest way to definitely recompose a View? In other words, completely remove from the tree and reinsert like it's brand new.

Why do you want to do that? Are you talking only about Android Views, or composables in general?

There is a lifecycle to the views. (onActive/onDispose) normally you do not want that a view is completely removed because this reduce the performance. I worked the complete weekend on a Transition effect to optimize it so it does not recompose and also do not get disposed and reattached. So when you just want to make sure that the view gets recomposed you can use following code:

Stack {
   val recompose = invalidate
   //your views here.
   // call recompose() when you want to trigger a recompose
 }

You might want to do this in an advanced case, but typically you don't. You should think about composables as describing your UI and they'll automatically recompose based on their parameters changing, or reading from state/observables. If you find yourself needing to reset state based on a parameter changing, it's likely you have added state too low in the tree and should hoist it to the caller where it can become a single source of truth. Sometimes in loops the source position won't be "keyed" correctly, and you can manually give it a key using this API: https://developer.android.com/reference/kotlin/androidx/compose/package-summary#key(kotlin.Any,%20kotlin.Function0) Key can also be used to reset the state of the subtree rooted at key. That said – it's better to hoist state than it is to hold logic like this in composition when it can be avoided.

Thanks for the answers. I also thought to myself that this was something I've never needed when coding in React or Flutter. Declarative already suggests that the state should perfectly describe the view layer and the framework should handle state changes. Unfortunately, mixing

AndroidView

with some old callbacks like surface updates for

TextureView

threw me off a little bit. A mediaplayer needs a surface, which becomes available asynchronously, to play the video. I struggled with implementing the source URL as a dependency to my Composable view so that when this URL changes, MediaPlayer should start playing the new video. It felt like the easiest way was to completely get rid off the surface(TextureVuew) and restart from scratch because the initial source always worked as expected. I decided to tweak my design a bit and move MediaPlayer related functionality to a specific controller. That helped a lot to figure out how to map other video player related stuff like seekbar into compose.