I was having the issue with a custom view having its own implementation of View.BaseSavedState. It turned out that the writeToParcel() method there had method calls in the wrong order.
It was annoying to find the problem and I needed to step debug the Android SDK all the way to the Bundle class, where unparcel() is called:
synchronized void unparcel() {
if (mParcelledData == null) {
return;
}
int N = mParcelledData.readInt();
if (N < 0) {
return;
}
if (mMap == null) {
mMap = new HashMap<String, Object>(N);
}
mParcelledData.readMapInternal(mMap, N, mClassLoader);
mParcelledData.recycle();
mParcelledData = null;
}
Line 223 of your log is exactly the readMapInternal() call. There the Parcel object will iterate through its items, reading the values one by one. The problem usually occurs if something was written in the wrong order. The method Parcel.readValue(ClassLoader loader) will read them in the order they were written but if you have custom views or objects, if they were written in an order different than the one you are now reading them, something wrong will happen in the NEXT item to read.
So I found the problem by identifying the last item that was read successfully. You can usually identify that (if it's a custom view or object) by checking its creator class name. Check the Parcel class' method readParcelableCreator():
public final <T extends Parcelable> Parcelable.Creator<T> readParcelableCreator(
ClassLoader loader) {
String name = readString();
if (name == null) {
return null;
}
...
}
You can inspect the name string for the class of the creator. If it's a custom one, you can immediately identify it. Then, if the next reading crashes your app, you can be almost sure that the culprit was the previous read.
Hope it helps.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
