Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
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
[Deleted User] <[Deleted User]> #3
We've fixed this internally and are preparing a DrawerLayout 1.1.1
release with this fix.
il...@google.com <il...@google.com> #4
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
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
il...@google.com <il...@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
Description
Version used: 1.0.0-alpha11
Devices/Android versions reproduced on: irrelevant
I have a fragment like this:
<fragment
android:id="@+id/teamDetailFragment"
android:name="com.optima_apps.fkcz.ui.team.teamdetail.TeamDetailFragment"
android:label="{player_name}" <== PARAMETRIZED LABEL (from a plain string argument)
tools:layout="@layout/fragment_team_detail">
<argument
android:name="player"
app:argType="com.optima_apps.fkcz.models.Player" /> <== CUSTOM CLASS ARG TYPE
<argument
android:name="player_name"
app:argType="string" />
</fragment>
When parametrized label is used in combination with custom class argument type on a fragment, the app crashes when activity is recreated with a saved instance state. To reproduce, have a fragment configured as shown above, then in Developer Options enable "Don't keep activites" to force activity to destroy as soon as you leave it, then return to activity and it should crash like below:
2019-02-05 12:57:22.012 5790-5790/com.optima_apps.fkcz E/Parcel: Class not found when unmarshalling: com.optima_apps.fkcz.models.Player
java.lang.ClassNotFoundException: com.optima_apps.fkcz.models.Player
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:400)
at android.os.Parcel.readParcelableCreator(Parcel.java:2489)
at android.os.Parcel.readParcelable(Parcel.java:2443)
at android.os.Parcel.readValue(Parcel.java:2346)
at android.os.Parcel.readArrayMapInternal(Parcel.java:2698)
at android.os.BaseBundle.unparcel(BaseBundle.java:269)
at android.os.BaseBundle.containsKey(BaseBundle.java:345)
at androidx.navigation.ui.AbstractAppBarOnDestinationChangedListener.onDestinationChanged(AbstractAppBarOnDestinationChangedListener.java:90)
at androidx.navigation.ui.ToolbarOnDestinationChangedListener.onDestinationChanged(ToolbarOnDestinationChangedListener.java:57)
at androidx.navigation.NavController.addOnDestinationChangedListener(NavController.java:218)
at androidx.navigation.ui.NavigationUI.setupWithNavController(NavigationUI.java:292)
at androidx.navigation.ui.NavigationUI.setupWithNavController(NavigationUI.java:241)
at com.optima_apps.fkcz.FKCZActivity.onCreate(FKCZActivity.kt:41)
at android.app.Activity.performCreate(Activity.java:6915)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2746)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2864)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1567)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:6523)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:832)
Caused by: java.lang.ClassNotFoundException: com.optima_apps.fkcz.models.Player
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java:1346)
at java.lang.BootClassLoader.loadClass(ClassLoader.java:1406)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:400)
at android.os.Parcel.readParcelableCreator(Parcel.java:2489)
at android.os.Parcel.readParcelable(Parcel.java:2443)
at android.os.Parcel.readValue(Parcel.java:2346)
at android.os.Parcel.readArrayMapInternal(Parcel.java:2698)
at android.os.BaseBundle.unparcel(BaseBundle.java:269)
at android.os.BaseBundle.containsKey(BaseBundle.java:345)
at androidx.navigation.ui.AbstractAppBarOnDestinationChangedListener.onDestinationChanged(AbstractAppBarOnDestinationChangedListener.java:90)
at androidx.navigation.ui.ToolbarOnDestinationChangedListener.onDestinationChanged(ToolbarOnDestinationChangedListener.java:57)
at androidx.navigation.NavController.addOnDestinationChangedListener(NavController.java:218)
at androidx.navigation.ui.NavigationUI.setupWithNavController(NavigationUI.java:292)
at androidx.navigation.ui.NavigationUI.setupWithNavController(NavigationUI.java:241)
at com.optima_apps.fkcz.FKCZActivity.onCreate(FKCZActivity.kt:41)
at android.app.Activity.performCreate(Activity.java:6915)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2746)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2864)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1567)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:6523)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:832)
Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack trace available
I have already Googled this a bit and this could be the solution:
When I change the label to be a static string, the library never goes into part of code that's crashing, and everything works properly, so I'm sure the issue is not on my side.
If you need any additional info I'm here.