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

Thanks for the report!

Could you please confirm for us which version of Compose is your project using? Does it happen if you change the version?

Relevant crash from device:

2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A    NOTE: Function names and BuildId information is missing for some frames due
                                                                                                      NOTE: to unreadable libraries. For unwinds of apps, only shared libraries
                                                                                                      NOTE: found under the lib/ directory are readable.
                                                                                                      NOTE: On this device, run setenforce 0 to make the libraries readable.
                                                                                                      NOTE: Unreadable libraries:
                                                                                                      NOTE:   /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #00 pc 000000000004b5bc  /apex/com.android.runtime/lib64/bionic/libc.so (__strncmp_aarch64+252) (BuildId: 058e3ec96fa600fb840a6a6956c6b64e)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #01 pc 00000000000028f4  /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so (compose_inspection::analyzeLines(_jvmtiEnv*, int, _jvmtiLineNumberEntry*, int, _jvmtiLocalVariableEntry*, int*, int*)+160) (BuildId: 0990d56fd5c4090102a504def1e5a1657300399e)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #02 pc 0000000000002eb4  /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so (compose_inspection::resolveLocation(_JNIEnv*, _jclass*)+840) (BuildId: 0990d56fd5c4090102a504def1e5a1657300399e)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #03 pc 0000000000440154  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: 5de55fd6e2a9191dd8c1362ea79ef5f6)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #04 pc 000000000044049c  /apex/com.android.art/lib64/libart.so (BuildId: 5de55fd6e2a9191dd8c1362ea79ef5f6)
2022-07-05 03:42:05.730   771-771   tombstoned              tombstoned                           E  Tombstone written to: tombstone_09

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

Marked as fixed.

I can confirm same crash
composeVersion = '1.2.0-beta03'
+ these deps included
debugImplementation "androidx.compose.ui:ui-tooling:$composeVersion"
debugImplementation "androidx.compose.ui:ui-tooling-preview:$composeVersion"
debugImplementation "androidx.customview:customview:1.2.0-alpha01"
debugImplementation "androidx.customview:customview-poolingcontainer:1.0.0-rc01"

also tested 1.2.0-beta02, 1.3.0-alpha01 (with 1.2.0 composeCompiler)..., same crash

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

I was using Compose 1.2.0-rc03 and Compose Compiler 1.2.0. But this issue was present in previous versions (1.2.0-RCxx) of the compiler too.

Yesterday I was testing how it works with Compose 1.1.1 and Compose 1.3.0-alpha01. It seemed to be working better, I could inspect the app for 5-10 minutes until it crashed. However, fetching view atributes was really unreliable: sometimes instantaneous, other times with a huge delay or not it all. And I believe crashes are related to the attributes section.

Most of the crashes had these messages in the Logcat afterwards: (see the attached file)

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

It looks like jvmti->GetMethodName(methodId, &name, nullptr, nullptr) returns a nullptr for name without returning an error.

Slightly surprising. I will add a nullptr guard to avoid this.

It would be nice to find out what the kotlin code that causes looks like. It will be a lambda expression.

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

Okay, I did some testing and found out that this code crashes the app while using Layout Inspector. Once I removed all the parameters of ModalBottomSheetState (or of my wrapper *UiState class with ModalBottomSheetState in constructor) – it began to work fine.

I have other crashes on second screen and there are no functions with parameter ModalBottomSheetState. That screen has much more functions and I will need more time to find the cause. At least it's safe to say that this the crash is not caused by ModalBottomSheetState exclusively

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

Great, thanks. I will take a look.

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

This fix will be included in the compose 1.3.0-alpha03 release

PS: You mention that there are other crashes on the second screen.
If logcat shows the same lines like #2 i.e.
```
.../apex/com.android.runtime/lib64/bionic/libc.so (__strncmp_aarch64+252)
.../libcompose_inspection_jni.so (compose_inspection::analyzeLines(_jvmtiEnv*, int, _jvmtiLineNumberEntry*, int, _jvmtiLocalVariableEntry*, int*, int*)
.../libcompose_inspection_jni.so (compose_inspection::resolveLocation(_JNIEnv*, _jclass*)
```
then it is likely the same bug.

If crash looks different in logcat, it is likely a different bug: Please create a new bug (you could update this bug with a link to the new bug. Then I will see the new bug before the it goes through triaging).
Thank you so much for reporting.

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

Tested Compose 1.3.0-alpha03 with my project. Layout inspector works like a charm now Thank you for the fix

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

Thank you for reporting the bug and about the bug fix.

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

#8
I found an issue may related to this.
Detail is here 244376735.

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