IssueTracker

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

  The following changes were cherrypicked through Coastguard (https://android-build.googleplex.com/coastguard/)
  Release Track: (https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
  Created: 2019-10-14 17:23:42.610596+00:00
  Changes: aosp/1123258
 

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

Please provide the information requested in comment #3 to investigate further.

Hi,
the sample project compiles on my machine.

Just clone : https://github.com/sockeqwe/mosby.git  (master branch)

Then open it in android studio and run sample-mvi or compile it from command line
./gradlew :sample-mvi:assembleDebug

Copy the APK on your device. start the app with "don't keep activity" option. Click on a item on the list to start another Activity, then wait a few seconds to ensure that the previous activity has been destroyed, and then press the back button to come back to the previous Activity which will recreate the Activity and it's fragments and Views. While restoring a this error occurs:

 Caused by: android.os.BadParcelableException: ClassNotFoundException when unmarshalling: android.support.v7.widget.Toolbar$SavedState
                                                                                        at android.os.Parcel.readParcelableCreator(Parcel.java:2411)
                                                                                        at android.os.Parcel.readParcelable(Parcel.java:2337)
                                                                                        at android.view.AbsSavedState.<init>(AbsSavedState.java:57)
                                                                                        at android.view.View$BaseSavedState.<init>(View.java:21451)
                                                                                        at com.hannesdorfmann.mosby3.MosbySavedState.<init>(MosbySavedState.java:50)
                                                                                        at com.hannesdorfmann.mosby3.MosbySavedState$1.createFromParcel(MosbySavedState.java:34)
                                                                                        at com.hannesdorfmann.mosby3.MosbySavedState$1.createFromParcel(MosbySavedState.java:32)
                                                                                        at android.os.Parcel.readParcelable(Parcel.java:2346)
                                                                                        at android.os.Parcel.readValue(Parcel.java:2243)
                                                                                        at android.os.Parcel.readSparseArrayInternal(Parcel.java:2653)
                                                                                        at android.os.Parcel.readSparseArray(Parcel.java:1946)
                                                                                        at android.os.Parcel.readValue(Parcel.java:2300)
                                                                                        at android.os.Parcel.readArrayMapInternal(Parcel.java:2592)
                                                                                        at android.os.BaseBundle.unparcel(BaseBundle.java:221)
                                                                                        at android.os.Bundle.getSparseParcelableArray(Bundle.java:856)
                                                                                        at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1207)
                                                                                        at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1467)
                                                                                        at android.support.v4.app.FragmentManagerImpl.onCreateView(FragmentManager.java:3384)
                                                                                        at android.support.v4.app.FragmentController.onCreateView(FragmentController.java:120)
                                                                                        at android.support.v4.app.FragmentActivity.dispatchFragmentsOnCreateView(FragmentActivity.java:378)
                                                                                        at android.support.v4.app.BaseFragmentActivityHoneycomb.onCreateView(BaseFragmentActivityHo


From my prospective it seems that this is caused by a View which is part of Fragment which is included in XML's layout. It seems that the Fragment doesn't set a ClassLoader internally and therfore it's not able to restore my view's state.

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

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

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

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

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

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

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.

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

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

Can you please provide a reproduction usecase without the app's(application given in comment #6) additional layers of abstraction responsible for parceling state.

Can you please provide the information requested in comment #16 to investigate further.

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.

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

Thanks for the investigation though Christophe

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.

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.