地块解组未知类型code

本文介绍了地块解组未知类型code的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我们越来越在记录的Play商店中的崩溃报告这个错误。不能在我们所有的测试复制此。别人也有同样的问题或解决方案？ 事情是，我们甚至不知道该怎么做才能复制这个bug。

所有Parcelable对象有 CREATOR，writeToParcel（）和构造器确定。所有列表和复杂类型被初始化和空检查。

了java.lang.RuntimeException：无法启动活动ComponentInfo {aupany/aupany.DetailsActivity}：java.lang.RuntimeException的：包裹android.os。包裹@ 42d6e270：解组未知类型code 6881381偏移量11268 在android.app.ActivityThread.performLaunchActivity（ActivityThread.java:2247） 在android.app.ActivityThread.handleLaunchActivity（ActivityThread.java:2297） 在android.app.ActivityThread.access $ 700（ActivityThread.java:152） 在android.app.ActivityThread $ H.handleMessage（ActivityThread.java:1282） 在android.os.Handler.dispatchMessage（Handler.java:99） 在android.os.Looper.loop（Looper.java:137） 在android.app.ActivityThread.main（ActivityThread.java:5328） 在java.lang.reflect.Method.invokeNative（本机方法） 在java.lang.reflect.Method.invoke（Method.java:511） 在com.android.internal.os.ZygoteInit $ MethodAndArgsCaller.run（ZygoteInit.java:1102） 在com.android.internal.os.ZygoteInit.main（ZygoteInit.java:869） 在dalvik.system.NativeStart.main（本机方法） 致：java.lang.RuntimeException的：地块android.os.Parcel@42d6e270：解组未知类型code 6881381偏移量11268 在android.os.Parcel.readValue（Parcel.java:2032） 在android.os.Parcel.readMapInternal（Parcel.java:2225） 在android.os.Bundle.unparcel（Bundle.java:223） 在android.os.Bundle.getSparseParcelableArray（Bundle.java:1240） 在android.support.v4.app.FragmentManagerImpl.moveToState（的SourceFile：861） 在android.support.v4.app.FragmentManagerImpl.moveToState（的SourceFile：1104） 在android.support.v4.app.FragmentManagerImpl.moveToState（的SourceFile：1086） 在android.support.v4.app.FragmentManagerImpl.dispatchCreate（的SourceFile：1872） 在android.support.v4.app.FragmentActivity.onCreate（的SourceFile：215） 在android.support.v7.app.ActionBarActivity.onCreate（的SourceFile：97） 在aupany.DetailsActivity.onCreate（的SourceFile：40） 在android.app.Activity.performCreate（Activity.java:5250） 在android.app.Instrumentation.callActivityOnCreate（Instrumentation.java:1097） 在android.app.ActivityThread.performLaunchActivity（ActivityThread.java:2211） ... 11更多

解决方案

我是有这个问题有自己的执行View.BaseSavedState的自定义视图。原来，该writeToParcel（）方法存在有错误的顺序方法调用。

这是恼人找出问题，我需要一步一路调试Android SDK中的包类，其中unparcel（）被调用：

同步无效unparcel（）{     如果（mParcelledData == NULL）{         返回;     }     INT N = mParcelledData.readInt（）;     如果（N小于0）{         返回;     }     如果（MMAP == NULL）{         MMAP =新的HashMap＆LT;字符串，对象＆gt;（N）;     }     mParcelledData.readMapInternal（MMAP，N，mClassLoader）;     mParcelledData.recycle（）;     mParcelledData = NULL; }

日志223线正是readMapInternal（）调用。存在的包裹物将遍历其项目，读出的值一个接一个。通常如果事情是写在错误的顺序出现问题。该方法Parcel.readValue（类加载器加载器）会读他们在他们写的顺序，但如果有自定义视图或对象，如果他们写的不是一个不同的顺序您正在阅读它们，什么问题将在发生下一个项目阅读。

所以，我通过识别被成功读取的最后一个项目中发现的问题。您通常可以识别（如果它是一个自定义视图或对象）通过检查其创建者类名。检查包裹类的方法readParcelableCreator（）：

公共决赛＆LT;吨延伸Parcelable＆GT; Parcelable.Creator＆LT; T＆GT; readParcelableCreator（         类加载器加载器）{     字符串名称= readString（）;     如果（名称== NULL）{         返回null;     } ... }

您可以检查该名字符串类的创作者。如果它是一个自定义的，你可以立即识别它。然后，如果下一读取崩溃的应用程序，你几乎可以肯定，罪魁祸首是previous阅读。

希望它帮助。

We are getting this error in the Crash reports logged by play store. Cant replicate this in all our testing. Does anyone else have the same problem or solution ? Thing is, we dont even know what to do to replicate this bug.

All Parcelable objects have CREATOR, writeToParcel() and contructor defined. All Lists and complex types are initialised and null checked.

java.lang.RuntimeException: Unable to start activity ComponentInfo{aupany/aupany.DetailsActivity}: java.lang.RuntimeException: Parcel android.os.Parcel@42d6e270: Unmarshalling unknown type code 6881381 at offset 11268 at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2247) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2297) at android.app.ActivityThread.access$700(ActivityThread.java:152) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:5328) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869) at dalvik.system.NativeStart.main(Native Method) Caused by: java.lang.RuntimeException: Parcel android.os.Parcel@42d6e270: Unmarshalling unknown type code 6881381 at offset 11268 at android.os.Parcel.readValue(Parcel.java:2032) at android.os.Parcel.readMapInternal(Parcel.java:2225) at android.os.Bundle.unparcel(Bundle.java:223) at android.os.Bundle.getSparseParcelableArray(Bundle.java:1240) at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:861) at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:1104) at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:1086) at android.support.v4.app.FragmentManagerImpl.dispatchCreate(SourceFile:1872) at android.support.v4.app.FragmentActivity.onCreate(SourceFile:215) at android.support.v7.app.ActionBarActivity.onCreate(SourceFile:97) at aupany.DetailsActivity.onCreate(SourceFile:40) at android.app.Activity.performCreate(Activity.java:5250) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1097) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2211) ... 11 more

解决方案

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.