IssueTracker

Yeah, it is our API issue. It is very unclear to developer that this will happen. Should we pass lifecycle as parameter?

IMO it is complicated issue/feature.

I see three possible use case scenarios:
1. Single actionBar/toolbar per activity. NavigationUI.setupWithNavController works fine.
2. Every fragment has its own toolbar. NavigationUI.setupWithNavController leaks views. And managing back arrow inside Toolbar is not necessary since it it not going to change.
3. Same toolbar used only for some fragments. Such case can occur when parent fragment has back stack with childFragmenManager.

I am not sure how to solve this best. If SDK user will pass fragmentLifecycle instead of viewLifeCycle then view is still be leaked for some time.

I decided not to use these methods at all because in my case (2nd) it is needed to update Toolbar only once - after Toolbar view create.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d87596efaefed2570133a883d7c304e9ea95e7a8
Author: Ian Lake <ilake@google.com>
Date:   Wed Aug 15 16:04:39 2018

    Use WeakReferences in NavigationUI
   
    Avoid storing a strong reference to views
    (such as a Toolbar within a Fragment) in
    OnNavigatedListeners created by
    NavigationUI.
   
    NavigationUI makes an effort to clean up
    after itself by removing the
    OnNavigatedListener if one of its
    WeakReferences was garbage collected.
   
    Test: ran the integration test app
    BUG: 111961977
    Change-Id: Iea466591cc77e79b3b056108d2818afe22d1ddc6

M       navigation/ui/src/main/java/androidx/navigation/ui/NavigationUI.java

https://android-review.googlesource.com/732894
https://goto.google.com/android-sha1/d87596efaefed2570133a883d7c304e9ea95e7a8

Project: platform/frameworks/support
Branch: snap-temp-L59700000649811929

commit 8c0814d1467e02e617f002b61b09a5737a3a1e94
Author: Ian Lake <ilake@google.com>
Date:   Mon Jul 27 17:51:04 2020

    Ensure open() and close() always work
   
    As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
    and LOCK_MODE_LOCKED_OPEN, the app should
    still be able to open() and close() the drawer
    programmatically.
   
    This change aligns open() and close() with
    openDrawer() and closeDrawer() to allow
    programmatic usage no matter what LOCK_MODE
    is used.
   
    Test: tested in sample app
    BUG: 162253907
    Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
    (cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)

M       drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java

https://android-review.googlesource.com/1375020

Project: platform/frameworks/support
Branch: snap-temp-L27600000649911717

commit 63fcaff3662ea1236d84e644362f35b7618b56dd
Author: Ian Lake <ilake@google.com>
Date:   Mon Jul 27 17:51:04 2020

    Ensure open() and close() always work
   
    As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
    and LOCK_MODE_LOCKED_OPEN, the app should
    still be able to open() and close() the drawer
    programmatically.
   
    This change aligns open() and close() with
    openDrawer() and closeDrawer() to allow
    programmatic usage no matter what LOCK_MODE
    is used.
   
    Test: tested in sample app
    BUG: 162253907
    Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
    (cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)

M       drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java

https://android-review.googlesource.com/1375064

Project: platform/frameworks/support
Branch: snap-temp-L68100000649916060

commit e33fcbc8c30a40594cfcfbb643018e2bfe024820
Author: Ian Lake <ilake@google.com>
Date:   Mon Jul 27 17:51:04 2020

    Ensure open() and close() always work
   
    As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
    and LOCK_MODE_LOCKED_OPEN, the app should
    still be able to open() and close() the drawer
    programmatically.
   
    This change aligns open() and close() with
    openDrawer() and closeDrawer() to allow
    programmatic usage no matter what LOCK_MODE
    is used.
   
    Test: tested in sample app
    BUG: 162253907
    Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
    (cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)

M       drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java

https://android-review.googlesource.com/1375066

Project: platform/frameworks/support
Branch: snap-temp-L86900000650841826

commit 3ad4cab4e570828fddbf650934a4e9efdd8405e0
Author: Ian Lake <ilake@google.com>
Date:   Mon Jul 27 17:51:04 2020

    Ensure open() and close() always work
   
    As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
    and LOCK_MODE_LOCKED_OPEN, the app should
    still be able to open() and close() the drawer
    programmatically.
   
    This change aligns open() and close() with
    openDrawer() and closeDrawer() to allow
    programmatic usage no matter what LOCK_MODE
    is used.
   
    Test: tested in sample app
    BUG: 162253907
    Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
    (cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)

M       drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java

https://android-review.googlesource.com/1377801

Project: platform/frameworks/support
Branch: snap-temp-L89900000650843240

commit 978cae5a010bf4c0c1b6fcfd68fd1b1c7802e126
Author: Ian Lake <ilake@google.com>
Date:   Mon Jul 27 17:51:04 2020

    Ensure open() and close() always work
   
    As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
    and LOCK_MODE_LOCKED_OPEN, the app should
    still be able to open() and close() the drawer
    programmatically.
   
    This change aligns open() and close() with
    openDrawer() and closeDrawer() to allow
    programmatic usage no matter what LOCK_MODE
    is used.
   
    Test: tested in sample app
    BUG: 162253907
    Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
    (cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)

M       drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java

https://android-review.googlesource.com/1378183

Project: platform/frameworks/support
Branch: snap-temp-L89900000650864753

commit 2754768be7ccfd570f9355ab74406157e3a69d92
Author: Ian Lake <ilake@google.com>
Date:   Mon Jul 27 17:51:04 2020

    Ensure open() and close() always work
   
    As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
    and LOCK_MODE_LOCKED_OPEN, the app should
    still be able to open() and close() the drawer
    programmatically.
   
    This change aligns open() and close() with
    openDrawer() and closeDrawer() to allow
    programmatic usage no matter what LOCK_MODE
    is used.
   
    Test: tested in sample app
    BUG: 162253907
    Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
    (cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)

M       drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java

https://android-review.googlesource.com/1378185

Project: platform/frameworks/support
Branch: androidx-master-dev

commit c403da82b263cf8078bacafb9f4661e279a3089c
Author: Ian Lake <ilake@google.com>
Date:   Tue Oct 06 13:24:40 2020

    Update navigation-ui to depend on DrawerLayout 1.1.1
   
    DrawerLayout 1.1.1 includes a fix to the open()
    call used by NavigationUI when locking the drawer.
   
    Test: tested as part of b/162253907
    Relnote: "`navigation-ui` now depends on
    [DrawerLayout 1.1.1](/jetpack/androidx/releases/drawerlayout#1.1.1),
    ensuring that `NavigationUI` is able to open the drawer
    even when using `LOCK_MODE_LOCKED_CLOSED` or
    `LOCK_MODE_LOCKED_OPEN`."
   
    Change-Id: Ie2eeec35770138e9d69396c0eea3c1a45e7d757b

M       navigation/navigation-ui/build.gradle

https://android-review.googlesource.com/1451099