IssueTracker

class FixDrawerLayout @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
) : DrawerLayout(context, attrs) {

    fun registerToFragmentLifecycle(fragment: Fragment) {
        fragment.viewLifecycleOwner.launchOnLifecycleDestroy {
            super.onDetachedFromWindow()
        }
    }
}

With markdown the same:

I have a project on SingleActivity. And in manifest android:enableOnBackInvokedCallback="true". I have a Root Fragment with a toolbar to which I attach a DrawerLayout.

<!-- XML Root Fragment -->
<androidx.drawerlayout.widget.DrawerLayout>

    <androidx.coordinatorlayout.widget.CoordinatorLayout>
        <com.google.android.material.appbar.AppBarLayout>
            <com.google.android.material.appbar.MaterialToolbar />
        </com.google.android.material.appbar.AppBarLayout>
        <androidx.fragment.app.FragmentContainerView />
    </androidx.coordinatorlayout.widget.CoordinatorLayout>

    <androidx.core.widget.NestedScrollView
        android:layout_gravity="start">

</androidx.drawerlayout.widget.DrawerLayout>

On button click in DrawerLayout I change RootFragment and lose all View in this Xml after onDestroyView. I don't call close() or closeDrawer() because I need the old state when I return to this fragment. But!

The DrawerLayout calls onDetachedFromWindow() which calls updateBackInvokedCallbackState() where ViewCompat.isAttachedToWindow(this) returns true and all the following condition is also true.

boolean shouldBeRegistered = visibleDrawer != null
    && currentDispatcher != null
    && getDrawerLockMode(visibleDrawer) == LOCK_MODE_UNLOCKED
    && ViewCompat.isAttachedToWindow(this);

As a consequence, the following code cannot be executed:

        } else if (!shouldBeRegistered && mBackInvokedDispatcher != null) {
            Api33Impl.tryUnregisterOnBackInvokedCallback(
                    mBackInvokedDispatcher, mBackInvokedCallback);
            mBackInvokedDispatcher = null;
        }

Where mBackInvokedDispatcher != null is true, and shouldBeRegistered is true (but !shouldBeRegistered is false).

Consequently, my mechanical back button or slide (back gesture) is blocked and not called on a new Root fragment when the DrawerLayout is Destroyed.

<!-- new Root fragment -->
<androidx.coordinatorlayout.widget.CoordinatorLayout>
    <com.google.android.material.appbar.AppBarLayout>
        <com.google.android.material.appbar.MaterialToolbar />
    </com.google.android.material.appbar.AppBarLayout>

    <androidx.fragment.app.FragmentContainerView />

</androidx.coordinatorlayout.widget.CoordinatorLayout>

There may be a workaround, but that's not all. The fact is that LeakCanary reacts to this error, which claims that after registerOnBackInvokedCallback and not called tryUnregisterOnBackInvokedCallback, a memory leak occurs.

fast fix: android:enableOnBackInvokedCallback="false" or downgrade DrawerLayout to 1.1.1 or https://issuetracker.google.com/issues/296986132#comment2

after the drawer layout closed

According to my requirements, it should not close, since there is a screen animation where you can see that it is open. So the hot fix only helps through custom view.

fun registerToFragmentLifecycle(fragment: Fragment) {
    fragment.viewLifecycleOwner.launchOnLifecycleDestroy {
        super.onDetachedFromWindow()
    }
}

Here's my sample app btw - https://github.com/ZOlbrys/BackNavigationTestApp/tree/master

Again, I'm not sure if our issues are exactly the same, but I get "stuck" not being able to swipe back between fragments after navigating to a fragment starting from a menu item being selected in a Drawer Layout - so it sounds similar...

launchOnLifecycleDestroy ->

fun(block: suspend CoroutineScope.(Lifecycle.Event) -> Unit) {
    coroutineScope.launch {
        val observer = LifecycleEventObserver { _, event -> launch { if (Event.ON_DESTROY == event) block(event) } }
    
        addObserver(observer)
        
        try {
            awaitCancellation()
        } catch (_: CancellationException) {
            removeObserver(observer)
        }
    }
}

I found that if the drawer layout is part of a fragment, which is in turn replaced with another fragment as part of a navigation action, the bug occurs (back actions are consumed and not forwarded to the app as expected).

However, if you place the drawer layout as part of the parent activity, no bug occurs when you navigate from the drawer layout to another fragment/back/etc.

I assume that's because the drawer layout, when part of the activity, never goes destroyed/removed from the view, so it does not encounter the bug in question.

This is beginning to look like a separate issue related to navigation logic with drawer layouts in fragments/non-activity lifecycles.

I agree with you completely.

You download Flamingo or use adb my friend, they killed it by accident

Or you can download older build like chipmunk or disable experimental logcat. But in dolhin it is not available with the new logcat.

The missing info here is how to retrieve it in Flamingo. It's not called "Device Monitor", "Device File Explorer" doesn't exist as well.

What you look for is inside "Device Explorer" tab in bottom right, then there is a tab called "Processes" where you can Force stop or kill it.

Looks like this tab is missing again in the latest flamingo

The Device Monitor tool window is available in Studio Giraffe. Flamingo will not have it.

Note that if having the Terminate Application action is crucial for you, you can still disable the new Logcat tool window in EE and revert to the old tool window that has that action.

Settings -> Experimental

The Terminate Application action is available in Studio Giraffe, where is it is part of Device Explorer. In earlier Studio versions you may get it by switching to the old Logcat by unchecking Settings > Experimental > Enable new Logcat tool window.

+1