ClassNotFoundException when unmarshalling SavedState [37133281]

Infeasible

Bug

[AOSP] assigned

NeedsInfo

Status Update

No update yet.

Description

wo...@gmail.com

created issue #1

Jan 18, 2017 06:32PM

This ticket is a duplicate (sorry for doing this on purpose) of

https://code.google.com/p/android/issues/detail?id=196430.

The referenced issue is closed because the bug was fixed in an older release. However the bug reappears in the support library 25.x again and there are a lot of comments that are asking for opening the ticket.

But apparently no maintainer is reading closed tickets so I'm opening this to pull the attention there.

Comments

ar...@google.com <ar...@google.com> #2Jan 19, 2017 08:51AM

Assigned to ar...@google.com.

BTW, the source code for this is fairly straightforward. I just added the source into the sample for now, but it would be nicer if we had the function.

From source:

 /**
 * Gets the current navigation back stack entry as a [MutableState]. When the given navController
 * changes the back stack due to a [NavController.navigate] or [NavController.popBackStack] this
 * will trigger a recompose and return the top entry on the back stack.
 *
 * @return a mutable state of the current back stack entry
 */
@Composable
public fun NavController.currentBackStackEntryAsState(): State<NavBackStackEntry?> {
    return currentBackStackEntryFlow.collectAsState(null)
}

wo...@gmail.com <wo...@gmail.com> #3Jan 19, 2017 08:54AM

Here's the code from my PR if you want to see what I was doing.

ar...@google.com <ar...@google.com> #4Jan 31, 2017 06:43AM

Project: platform/frameworks/support
Branch: androidx-main

commit 804463f3f416212296133fe53e30b5d5cbc2fba9
Author: stevebower <stevebower@google.com>
Date: Wed Jan 05 15:04:02 2022

Add currentBackStackEntryAsState to Wear Compose Navigation.

Test: Run tests for wear.compose.navigation.

Bug: 212739653

Relnote: "We have added NavController.currentBackStackEntryAsState()
to the Wear.Compose.Navigation library."
Change-Id: If90286c7debe623df926a091f15766abf04f2ecc

M wear/compose/compose-navigation/api/restricted_current.txt
M wear/compose/compose-navigation/api/current.txt
M wear/compose/compose-navigation/src/androidTest/kotlin/androidx/wear/compose/navigation/SwipeDismissableNavHostTest.kt
M wear/compose/compose-navigation/api/public_plus_experimental_current.txt
M wear/compose/compose-navigation/src/main/java/androidx/wear/compose/navigation/SwipeDismissableNavHostController.kt

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

ar...@google.com <ar...@google.com> #5Feb 6, 2017 10:40AM

Hi Steve, which version of the library will this be released in?

ha...@gmail.com <ha...@gmail.com> #6Feb 6, 2017 02:29PM

Never mind, it's in alpha15, missed that. Thanks!

ar...@gmail.com <ar...@gmail.com> #7Feb 6, 2017 04:28PM

Still have same issue

phone_model: GT-I9070
android_version: 2.3.6

'com.android.support:design:25.0.1'
'com.android.support:appcompat-v7:25.0.1'
'com.android.support:cardview-v7:25.0.1'
'com.android.support:recyclerview-v7:25.0.1'

stacktrace:java.lang.RuntimeException: Unable to start activity ComponentInfo{xxx}: android.os.BadParcelableException: ClassNotFoundException when unmarshalling: android.support.design.widget.AppBarLayout$Behavior$SavedState

kv...@gmail.com <kv...@gmail.com> #8Feb 7, 2017 03:31PM

Still have this issue on Android 5,6.
At this moment we have about 256 crashes of our app because of this issue.

See crashlog in attachments

deleted

Restricted

0 B

ha...@gmail.com <ha...@gmail.com> #9Feb 7, 2017 03:41PM

#7 Is the RecyclerView in a Fragment that is embedded in a XML layout (of an Activity)?

[Deleted User] <[Deleted User]> #10Feb 7, 2017 03:51PM

#8 The RecyclerView is in xml-layout file that is inflated by multiple fragments and then added to the ViewPager in MainActivity.

ar...@google.com <ar...@google.com> #11Feb 8, 2017 10:47AM

We have passed this defect on to the development team and will update this issue with more information as it becomes available.

ch...@beyls.net <ch...@beyls.net> #12Feb 21, 2017 06:32PM

This crash is still happening on all API < 13 devices with the latest version of the design support library (25.1.1).

There is indeed a bug in CoordinatorLayout: it does not properly restore its state when the CoordinatorLayout.SavedState constructor is given a null ClassLoader (The ClassLoader argument is always null in API < 13). This can easily be fixed like this:

if (loader == null) {
loader = CoordinatorLayout.class.getClassLoader();
}

Until the bug is fixed, I created a "SafeCoordinatorLayout" which works around the bug and that I'm using as a drop-in replacement of CoordinatorLayout in my projects:

https://gist.github.com/cbeyls/683a90198c64de596ad6502de738a055

ch...@beyls.net <ch...@beyls.net> #13Feb 21, 2017 06:39PM

The bug in that "mosby" sample project is completely unrelated: When you provide a class which inherits from AbsSavedState (like "MosbySavedState"), if the superstate class is not part of the framework (like a custom class), then you need to pass the correct ClassLoader instance to AbsSavedState or it won't be able to inflate the superState.

To fix this, I recommend that "MosbySavedState" inherits from android.support.v4.view.AbsSavedState instead and make sure a non-null ClassLoader is passed to super(). I'll submit a pull request.

[Deleted User] <[Deleted User]> #14Mar 16, 2017 04:28PM

#11 your SafeCoordinatorLayout is a lifesaver for the older API levels!

ch...@beyls.net <ch...@beyls.net> #15Mar 17, 2017 07:09PM

I submitted a pull request to fix this issue one month ago, but still no reaction from Google:

https://github.com/material-components/material-components-android/pull/31

ar...@google.com <ar...@google.com> #16Jun 13, 2017 04:51AM

Can you please provide a reproduction usecase without the app's(application given in

comment #6

) additional layers of abstraction responsible for parceling state.

ar...@google.com <ar...@google.com> #17Jun 19, 2017 06:30AM

Can you please provide the information requested in

comment #16

to investigate further.

ch...@beyls.net <ch...@beyls.net> #18Jun 20, 2017 03:02PM

I created a minimal sample project as reproduction usecase:

https://github.com/cbeyls/CoordinatorLayoutStateRestoration
I also provided the fix as pull request and a workaround class for developers, I don't think I can do more than that.

ch...@google.com <ch...@google.com> #19Jun 28, 2017 09:29AM

Note that we're dropping support for <v14 in 26.0.0 so unlikely to release a fix.

Thanks for the investigation though Christophe

ch...@beyls.net <ch...@beyls.net> #20Jun 28, 2017 11:08AM

I was hoping for a final 25.x bugfix release for older devices before their support is dropped. CoordinatorLayout never worked properly on API <13 devices since it was introduced in 2015.

ar...@google.com <ar...@google.com> #21Jul 12, 2017 05:02AM

Status: Won't Fix (Infeasible)

We no longer target support library for devices less than API 14. Since this bug is only reproducible for those devices, there is nothing we can do about it.
If you can create a minimal project that reproduces it on devices with API 14 and above, we can reopen the bug and fix it.