Fixed
Status Update
No update yet.
Comments
jb...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit ae09f6e6686b32c5677c086d51d5737553e2aeb9
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
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1373433
Branch: androidx-master-dev
commit ae09f6e6686b32c5677c086d51d5737553e2aeb9
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
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
pr...@google.com
We've fixed this internally and are preparing a DrawerLayout 1.1.1 release with this fix.
ty...@gmail.com
Project: platform/frameworks/support
Branch: snap-temp-L48600000649720827
commit 6e863d72d89137a408907be4c44f5444b51f8dab
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/1374836
Branch: snap-temp-L48600000649720827
commit 6e863d72d89137a408907be4c44f5444b51f8dab
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
dr...@gmail.com
lb...@gmail.com
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
Description
Version used: 1.7.0
Devices/Android versions reproduced on: API 33
If this is a bug in the library, we would appreciate if you could attach:
Example project attached
Description:
It appears that ComponentActivity$ReportFullyDrawnExecutorApi16Impl.this$0 leaks memory when used in an ActivityScenario if the ActivityScenario is used to recreate the Activity soon after the Activity has been launched.
Reproduction steps:
1. Create an Activity that extends ComponentActivity
2. Set a content view for the Activity in the onCreate using either setContentView(View) or setContent { <Composable> }
3. Create an instrumented test that uses LeakCanary's DetectLeaksAfterTestSuccess Test Rule
4. In the test: Launch the Activity using ActivityScenario, and then call "recreate" on the ActivityScenario
5a. Expected result: The test launches the Activity, recreates it, and the test passes.
5b. Actual result: The test launches the Activity, recreates it, and then LeakCanary detects a memory leak from ComponentActivity$ReportFullyDrawnExecutorApi16Impl.this$0 leaking an instance of the Activity.
This issue does not occur for ComponentActivity instance that do not set a content view in onCreate, and does not occur for regular android.app.Activity instances.
I have attached an example project with eight instrumented tests that show case this issue. In the ExampleInstrumentedTest.kt tests `launchExampleViewActivityAndRecreate` and `launchExampleComposeActivityAndRecreate` both fail, and all other tests succeed. The expected behaviour is that all tests should pass.