xunice / libs-for-android

Automatically exported from code.google.com/p/libs-for-android
Apache License 2.0
0 stars 0 forks source link

Class not found when unmarshalling HtmlView$SavedState #16

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
This is not always reproduceable.
1. Open up an Activity that has an HtmlView in its layout.  The HtmlView should 
load up a page that has links.
2. Click on a link within the html page that opens up the Android browser.
3. Perform an orientation change of the device.
4. While still with a changed orientation, press back to exit the browser and 
return to the original Activity.  The error may sometimes appear.

What is the expected output? What do you see instead?
The original Activity should reappear.  Instead I see a force close.

What version of the product are you using? On what operating system?
Android ICS

Please provide any additional information below.
Here is the stack trace:

05-25 01:26:43.200: E/Parcel(6947): Class not found when unmarshalling: 
com.google.android.htmlwidget.HtmlView$SavedState, e: 
java.lang.ClassNotFoundException: 
com.google.android.htmlwidget.HtmlView$SavedState
05-25 01:26:43.200: D/AndroidRuntime(6947): Shutting down VM
05-25 01:26:43.200: W/dalvikvm(6947): threadid=1: thread exiting with uncaught 
exception (group=0x40a59228)
05-25 01:26:43.210: E/AndroidRuntime(6947): FATAL EXCEPTION: main
05-25 01:26:43.210: E/AndroidRuntime(6947): android.os.BadParcelableException: 
ClassNotFoundException when unmarshalling: 
com.google.android.htmlwidget.HtmlView$SavedState
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Parcel.readParcelable(Parcel.java:1971)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Parcel.readValue(Parcel.java:1859)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Parcel.readSparseArrayInternal(Parcel.java:2128)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Parcel.readSparseArray(Parcel.java:1581)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Parcel.readValue(Parcel.java:1916)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Parcel.readMapInternal(Parcel.java:2099)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Bundle.unparcel(Bundle.java:223)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.os.Bundle.getSparseParcelableArray(Bundle.java:1225)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:805)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1080
)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.app.BackStackRecord.run(BackStackRecord.java:622)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.ja
va:1416)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.app.FragmentManagerImpl.executePendingTransactions(FragmentMa
nager.java:431)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.app.FragmentStatePagerAdapter.finishUpdate(FragmentStatePager
Adapter.java:160)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.view.ViewPager.populate(ViewPager.java:804)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.view.ViewPager.dataSetChanged(ViewPager.java:714)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.support.v4.view.ViewPager$PagerObserver.onChanged(ViewPager.java:2060)
05-25 01:26:43.210: E/AndroidRuntime(6947):     at 
android.database.DataSetObservable.notifyChanged(DataSetObservable.java:35)

Original issue reported on code.google.com by davidwu...@gmail.com on 24 May 2012 at 5:33

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago
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