Android Bundle Error: Unmarshalling unknown type code

I'm working with a fairly complex data edit activity in Android that makes use of the bundle object a lot when saving form data.

In general this works pretty well and I haven't experienced any data loss. However I have a strange intermittent bug that I can't seem to find the direct cause of.

It happens when I send an i开发者_StackOverflow社区ntent to the gallery (using startActivityForResult) to enable the user to select a profile image. A small (96x96) bitmap is returned in the bundle, and I save this data to their profile. This works flawlessly about 90% of the time, however on some occasions instead of returning with the image saved in a bundle, it will return a bundle that cannot be parsed. This occurs fairly frequently if I leave the device sitting in the gallery select mode for several minutes. (>5 minutes of idling).

When I attempt to access any functionality of the bundle at all I get the following runtime exception:

java.lang.RuntimeException: Parcel android.os.Parcel@44a06078: Unmarshalling unknown type code -8913000 at offset 392

Things of note: o When this error occurs it appears that the edit activity has been destroyed and needs to be recreated. (Before the error occurs it progresses through onCreate, onStart and onRestoreInstanceState (Where the crash originates)). o This appears to cause it to skip the "onActivityResult" section (or at least never reaches that far. o The bundle object retrieved in onRestoreInstanceState is not null, but any other access to the object (including checking if its empty) result in this crash. o By checking the bundle source code, I found that the crash seems to originate from the bundle performing an internal type check using a stored int flag. The error occurs when the int flag comes up with a type not in the list (so far it consistently has been -8913000). o I've only seen this error on froyo so far (2.2)

Has anyone encountered a similar error to this? Does anyone have a suggestion on where to look next?

In the mean time I'm going to try to put together a slimmed down version of this section of code that might be post-able, and see if that still reproduces the problem in question.