Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
il...@google.com <il...@google.com> #3
ap...@google.com <ap...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically ( b/140759491 ).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: snap-temp-L11100000649726887
commit 4b1419f8d1c41233b1af357a178c1eb6e71e3fb0
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/1374876
Branch: snap-temp-L11100000649726887
commit 4b1419f8d1c41233b1af357a178c1eb6e71e3fb0
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
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: snap-temp-L37200000649809909
commit 8e12fa9761f7d1ad254bd278392ed2020de2cec1
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/1375018
Branch: snap-temp-L37200000649809909
commit 8e12fa9761f7d1ad254bd278392ed2020de2cec1
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
ap...@google.com <ap...@google.com> #7
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
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
ap...@google.com <ap...@google.com> #8
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
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
ap...@google.com <ap...@google.com> #9
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
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
ap...@google.com <ap...@google.com> #10
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
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
ap...@google.com <ap...@google.com> #11
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
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
ap...@google.com <ap...@google.com> #12
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
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
an...@google.com <an...@google.com> #13
The following changes were cherrypicked through
Release Track:
Changes: aosp/1373433
an...@google.com <an...@google.com> #14
The following changes were cherrypicked through
Release Track:
Changes: aosp/1378185
ap...@google.com <ap...@google.com> #15
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
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
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
an...@google.com <an...@google.com> #16
The following changes were cherrypicked through
Release Track:
Changes: aosp/1451099
Description
Component used: DrawerLayout Version used: 1.1.0
When attempting to use the
Openable
APIs ofopen()
andclose()
, they do not work if you are usingLOCK_MODE_LOCKED_CLOSED
. As per its documentation:So programmatically opening/closing the drawer should be allowed. This would make it consistent with
openDrawer()
andcloseDrawer()
.