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

For one of observables (single, maybe) we don't specify a subscvription thread so that developer can control where the action happens.
For flowables / observables; we always use the Room IO thread fo rthe actual query since we may repeat the work.

For LiveData, ti si always the Room IO Thread.

Until we can extend Room Query methods to receive non-query parameter (e.g. a Scheduler) we cannot do this.
At least room catches this instantly since it will crash w/ db access on main thread exception.

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

Marked as fixed.

Hello Yigit, nice to meet you here! :)
Probably I should have described the problem more clearly.

I'm using Flowable, and hopefully it executes queries in background thread (at least, app does not crash with IllegalStateException, as with Single).

But nevertheless subscribing and disposing(!) does cause StrictMode violations. Stack trace examples:

D/StrictMode: StrictMode policy violation; ~duration=17 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.addObserver(InvalidationTracker.java:249)
at androidx.room.RxRoom$1.subscribe(RxRoom.java:79)
at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:71)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableObserveOn.subscribeActual(FlowableObserveOn.java:56)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe.subscribeActual(FlowableFlatMapMaybe.java:54)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.Flowable.subscribe(Flowable.java:14416)
at io.reactivex.Flowable.subscribe(Flowable.java:14306)
at gmk57.strictroom.MainActivity.onCreate(MainActivity.java:30)

StrictMode policy violation; ~duration=108 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.removeObserver(InvalidationTracker.java:281)
at androidx.room.RxRoom$1$2.run(RxRoom.java:83)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:30)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:19)
at io.reactivex.disposables.ReferenceDisposable.dispose(ReferenceDisposable.java:43)
at io.reactivex.internal.disposables.DisposableHelper.dispose(DisposableHelper.java:124)
at io.reactivex.internal.disposables.SequentialDisposable.dispose(SequentialDisposable.java:72)
at io.reactivex.internal.operators.flowable.FlowableCreate$BaseEmitter.cancel(FlowableCreate.java:301)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.cancel(FlowableObserveOn.java:154)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe$FlatMapMaybeSubscriber.cancel(FlowableFlatMapMaybe.java:158)
at io.reactivex.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:189)
at io.reactivex.internal.subscribers.LambdaSubscriber.cancel(LambdaSubscriber.java:119)
at io.reactivex.internal.subscribers.LambdaSubscriber.dispose(LambdaSubscriber.java:104)
at gmk57.strictroom.MainActivity.onDestroy(MainActivity.java:37)

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

oh this is bad :/ we should fix it, thanks!

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

Looks like it is broken for both add observer and remove observer since both are sync.
We need to investigate this better because these methods were not @WorkerThread before and we had to change them to fix some invalidation problems (see internal bug

b/73592149

).
Luckily this is not an issue for LiveData since it uses ComputableLiveData and always calls observe on a background thread.

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

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

commit 79deed62f2188a6ce2d21244dd28c3dc8ab6d0de
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Oct 17 11:07:39 2018

Specify subscribeOn and unsubscribeOn scheduler in RxRoom.

Setting subscriber and unsubscriber schedulers prevents triggers being
synced in the main thread when subscribing or disposing a RxRoom
flowable / observable.

Moved beginTransaction() calls in InvalidationTracker outside the try,
finally with endTransaction() so that exceptions thrown by
beginTransaction() aren't aborted nor forgotten.

Bug: 117201279
Test: Manual test with sample app.
Change-Id: Iefb33dc63cf78e125a8805bd66a26ada365d8453

A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/InvalidationTrackerTest.java
M room/runtime/src/main/java/androidx/room/InvalidationTracker.java
M room/rxjava2/src/main/java/androidx/room/RxRoom.java
M room/rxjava2/src/test/java/androidx/room/RxRoomTest.java

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

https://goto.google.com/android-sha1/79deed62f2188a6ce2d21244dd28c3dc8ab6d0de

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

Dupe

https://issuetracker.google.com/issues/74227569

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

Run

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

Run

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

Run

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