open() and close() don't work when using LOCK_MODE_LOCKED_CLOSED [162253907]

Fixed

Bug

Status Update

No update yet.

Description

il...@google.com

created issue #1

Jul 27, 2020 08:18PM

Component used: DrawerLayout Version used: 1.1.0

When attempting to use the Openable APIs of open() and close(), they do not work if you are using LOCK_MODE_LOCKED_CLOSED. As per its documentation:

The user may not open it, though the app may open it programmatically.

So programmatically opening/closing the drawer should be allowed. This would make it consistent with openDrawer() and closeDrawer().

Comments

il...@google.com <il...@google.com> Jul 28, 2020 12:57AM

Accepted by il...@google.com.

ap...@google.com <ap...@google.com> #2Jul 28, 2020 03:42PM

Oh I forgot to mention that I thought it might be connected to this issue: https://issuetracker.google.com/issues/243778589. But after trying 2.5.2 I can say that the issue persists.

il...@google.com <il...@google.com> #3Jul 28, 2020 05:47PM

Marked as fixed.

Please provide a minimal sample project along with the minimal steps to recreate the issue in the project.

ap...@google.com <ap...@google.com> #4Jul 28, 2020 05:55PM

Sorry for the delay. I got a working example here: https://github.com/Del-S/issues. The project is set up to crash when navigating to ThirdFragment (nested nav graph) with poping the graph.

I poked into it a little bit and it seems to be connected to SafeArgs gradle plugin. When safe args is used to navigate to ThirdFragment (with nested graph poped) it will try to recreate te parent but there were no arguments passed so it crashes.

Steps to reproduce:

Navigate from Second Fragment to Child nav graph (with non-nullable parameters).
Navigate to Third fragment using SafeArgs and the app crashes.

Crash log:

Process: cz.dels.issues, PID: 1743
java.lang.NullPointerException: null cannot be cast to non-null type kotlin.Long
at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:352)
at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:342)
at androidx.navigation.NavArgument.verify(NavArgument.kt:76)
at androidx.navigation.NavDestination.addInDefaultArgs(NavDestination.kt:502)
at androidx.navigation.NavController.addEntryToBackStack(NavController.kt:1865)
at androidx.navigation.NavController.addEntryToBackStack$default(NavController.kt:1813)
at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1721)
at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1719)
at androidx.navigation.NavController$NavControllerNavigatorState.push(NavController.kt:287)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:246)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:162)
at androidx.navigation.NavController.navigateInternal(NavController.kt:260)
at androidx.navigation.NavController.navigate(NavController.kt:1719)
at androidx.navigation.NavController.navigate(NavController.kt:1545)
at androidx.navigation.NavController.navigate(NavController.kt:1472)
at androidx.navigation.NavController.navigate(NavController.kt:1930)
at cz.dels.issues.SecondFragment.onViewCreated$lambda-0(SecondFragment.kt:38)
at cz.dels.issues.SecondFragment.$r8$lambda$XDYnOS_cYrafiNQ5rcCu1WCn0IE(Unknown Source:0)
at cz.dels.issues.SecondFragment$$ExternalSyntheticLambda0.onClick(Unknown Source:2)

Note: If in step 2 SaveArgs is not used then navigation works correctly. More information is here: https://github.com/Del-S/issues/blob/master/app/src/main/java/cz/dels/issues/SecondFragment.kt#L37.

ap...@google.com <ap...@google.com> #5Jul 28, 2020 06:01PM

Ups a typo: Navigate from ~~Second~~ First Fragment to Child nav graph (with non-nullable parameters).

Note: sorry for the spam but I am not able to edit my own comment.

ap...@google.com <ap...@google.com> #6Jul 28, 2020 07:29PM

This has been fixed and will be available in navigation 2.6.0-alpha08

ap...@google.com <ap...@google.com> #7Jul 28, 2020 07:31PM

Project: platform/frameworks/support
Branch: androidx-main

commit 6b358154b794a0456b089ac8e548bfb830dd6c22
Author: Clara Fok <clarafok@google.com>
Date: Tue Mar 14 17:56:12 2023

Fix missing non-nullable arg when rebuilding hierarchy

When navigating with NavDirections, args is populated with an empty bundle. This causes issue when we rebuild parent hierarchy while adding a new entry to NavBackStack. If the Entry being rebuilt contains a non-nullalbe arg, i.e. Long, this empty bundle will cause an exception.

Test: ./gradlew navigation:navigation-runtime:cC
Bug: 249988437
Change-Id: I5c8ce739ad9a3428c8a8de13eae391bfff0db5df

M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt

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

ap...@google.com <ap...@google.com> #8Jul 28, 2020 09:09PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.navigation:navigation-runtime:2.6.0-alpha08

ap...@google.com <ap...@google.com> #9Jul 28, 2020 09:11PM

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

ap...@google.com <ap...@google.com> #10Jul 29, 2020 08:31PM

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

ap...@google.com <ap...@google.com> #11Jul 29, 2020 08:35PM

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

ap...@google.com <ap...@google.com> #12Jul 29, 2020 08:55PM

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

an...@google.com <an...@google.com> #13Jul 29, 2020 08:56PM

The following changes were cherrypicked through Coastguard
Release Track: 5549033339944960
Changes: aosp/1373433

an...@google.com <an...@google.com> #14Oct 5, 2020 08:26PM

The following changes were cherrypicked through Coastguard
Release Track: 6205454677704704
Changes: aosp/1378185

ap...@google.com <ap...@google.com> #15Oct 6, 2020 09:30PM

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

an...@google.com <an...@google.com> #16Oct 6, 2020 09:43PM

The following changes were cherrypicked through Coastguard
Release Track: 6205454677704704
Changes: aosp/1451099