Open GoogleCodeExporter opened 8 years ago
Is this the entire stack trace? Based on my experience with a similar bug, I
would expect there to be more if it happened during a return to the Activity -
maybe seeing the top of the stack where the Activity is starting up. If so,
please post it along with the revision number for the Support Library V4.
Regardless, the core issue is probably that when
FragmentManagerImpl.moveToState() is unpacking the saved state bundle for the
fragment that holds HtmlView$SavedState, an appropriate ClassLoader has not
been passed during Parcel.readParcelable(). In this case it is strange for this
to happen, because the ClassLoader for the Activity should have been attached
to the Bundle and should know about the libs-for-android library class HtmlView.
The added complication here may be that you're using the support library
versions of ViewPager and Fragment. I've found a similar discussion regarding
the same areas. There is a solution at the end of these comments although it
requires a layout modification. Maybe it will shed some light on your issue.
https://plus.google.com/104721081678050774375/posts/CTtjwVPBKsE
Upon studying the stack trace you posted and looking at the source for
HtmlView, my solution for the bug I encountered does not apply. In that
scenario, FragmentManagerImpl.moveToState() was unpacking the saved state
Bundle with a valid ClassLoader. The problem was that due to the nested nature
of saved states (each saved state retains a variable with the super saved
state) and that I had a custom saved state with a custom super saved state.
Upon unpacking, the custom saved state class was found with the ClassLoader but
the subsequent unpacking of the custom super saved state occurred without the
ClassLoader - because it wasn't passed on. After much digging, I was able to
resolve it by altering the constructor involved in unpacking my custom saved
state to explicitly pass the ClassLoader to Parcel.readParcelable() for the
super saved state class. I also had to store the returned unpacked super saved
state in a local variable because it would no longer be stored in
AbsSavedState.mSuperState. Finally, in onRestoreInstanceState() I retrieved the
super saved state using the local variable because SavedState.getSuperState()
did not return the actual super state. Again, this doesn't directly apply to
the posted bug but maybe it will help find a solution.
Original comment by mindriot...@gmail.com
on 28 Oct 2012 at 7:18
Here is another potential solution:
http://code.google.com/p/android/issues/detail?id=37484
Original comment by mindriot...@gmail.com
on 28 Oct 2012 at 7:20
Original issue reported on code.google.com by
davidwu...@gmail.com
on 24 May 2012 at 5:33