IssueTracker

I lied, there's a second issue: AndroidViewBinding always use the Activity's LayoutInflater (i.e., LayoutInflater.from(context)). This means that all inflating fragments are added to the Activity's FragmentManager, thus completely breaking the save/restore of state when it comes to nesting Composables and AndroidViewBinding inside another Fragment.

The updated project attached updates FragmentAwareAndroidViewBinding to handle this case as well:

@Composable
fun <T : ViewBinding> FragmentAwareAndroidViewBinding(
    bindingBlock: (LayoutInflater, ViewGroup, Boolean) -> T,
    modifier: Modifier = Modifier,
    update: T.() -> Unit = {}
) {
    val fragmentContainerViews = remember { mutableStateListOf<FragmentContainerView>() }
    val localView = LocalView.current
    AndroidViewBinding({ parentInflater, parent, attachToRoot ->
        // Find the right FragmentManager
        val inflater = try {
            val parentFragment = localView.findFragment<Fragment>()
            parentFragment.layoutInflater
        } catch (e: Exception) {
            parentInflater
        }
        bindingBlock(inflater, parent, attachToRoot)
    }, modifier = modifier) {
        fragmentContainerViews.clear()
        val rootGroup = root as? ViewGroup
        if (rootGroup != null) {
            findFragmentContainerViews(rootGroup, fragmentContainerViews)
        }
        update()
    }
    val activity = LocalContext.current as FragmentActivity
    fragmentContainerViews.forEach { container ->
        DisposableEffect(container) {
            // Find the right FragmentManager
            val fragmentManager = try {
                val parentFragment = container.findFragment<Fragment>()
                parentFragment.childFragmentManager
            } catch (e: Exception) {
                activity.supportFragmentManager
            }
            // Now find the fragment inflated via the FragmentContainerView
            val existingFragment = fragmentManager.findFragmentById(R.id.fragment_container_view)
            onDispose {
                if (existingFragment != null && !fragmentManager.isStateSaved) {
                    // If the state isn't saved, that means that some state change
                    // has removed this Composable from the hierarchy
                    fragmentManager.commit {
                        remove(existingFragment)
                    }
                }
            }
        }
    }
}

Verified with a snapshot of androidx.compose.ui:ui-viewbinding:1.0.0-SNAPSHOT with build 7236835 fixes all of the issues in the above FragmentInCompose app.

This means that you can use AndroidViewBinding directly with layouts that inflate fragments via FragmentContainerView. I'd suggest inflating fragments into your Compose hierarchy only as a transitional step and not as a suggested final architecture. :-)

Note: the <fragment> tag should never be used in any app, much less an app built on Compose. It is expected that inflating the same <fragment> layout twice will still crash your app.

Re comment#10 - please file a new issue with a sample project that reproduces your issue and we can take a look at your specific case.

I think the problem is that the onRelease code assumes that the localContext (see --->) can be cast to an Activity. But this doesn't work when it's a ContextThemeWrapper.

    onRelease = { view ->
        view.getBinding<T>().onRelease()

        (view as? ViewGroup)?.let { rootGroup ->
            // clean up inflated fragments when the AndroidViewBinding is disposed
            // Find the right FragmentManager
            val fragmentManager = parentFragment?.childFragmentManager
  --->              ?: (localContext as? FragmentActivity)?.supportFragmentManager
            forEachFragmentContainerView(rootGroup) { container ->
                // Now find the fragment inflated via the FragmentContainerView
                val existingFragment = fragmentManager?.findFragmentById(container.id)
                if (existingFragment != null && !fragmentManager.isStateSaved) {
                    // If the state isn't saved, that means that some state change
                    // has removed this Composable from the hierarchy
                    fragmentManager.commitNow {
                        remove(existingFragment)
                    }
                }
            }
        }
    },

Re comment#12 - that particular problem has been addressed as part of the introduction of AndroidFragment in Fragment 1.8's fragment-compose artifact, which is what we suggest for embedding your fragment in a Compose hierarchy now.

Re comment#13 just need to be aware of the bug: b/347706985. It seems like a deal-breaker.