Android storing persistent serializable object with proguard

Question

So in my android app, I have a custom class, that is pretty complex, it contains several other custom classes, all of which are serializable.

So every one of the objects has

private static final long serialVersionUID = 0L;

And I have not used any writeObject methods, all data are mostly strings, ints, boolean and arraylist of strings.

The issue is, it randomly doesn't work after updating the app, I get an InvalidClassException from ObjectInputStream saying wrong serialVersionUID, found some long random number but expected 0L. I have declared 0L; in all classes being serialized.

It works perfectly during testing. Changes in these updates may include changing some code in the objects methods, or sometimes not touching the class at all. But i've never changed any fields or anything mention in the Oracle docs about incompatible changes to serialized objects.

I am building the app with proguard enabled, and I suspect this has something to do with it? I read about rules you can add to configure proguard to support serialization better but doing this now would not help me recover persistent data from previous versions? or would it?

I have adopted a different method for the next version of my app, to avoid serialization where I will manually convert my objects to strings to be stored persistently.

Is there anyway I can recover serialized persistent data from previous versions?

I tried extending ObjectInputStream and ignoring the serialVersionUID comparison as described in the answer to this question: Make Java runtime ignore serialVersionUIDs?

But I get ClassCastException attempting to convert one of my custom objects to a string.. which leaves me confused.

So I want to know, is there any way I can recover the previously serialized persistent data?

Answer 1

Sorry for the late response, I'm hoping maybe someone else who stumbles in here will benefit from it.

I see what you're writing about proguard but the fact that you're seeing a long number you're not expecting makes it sound like somehow there's been a mistake with the ID, and the long number you see is the system creating an ID from hashing your class. If that is the case, chances are that it did the same thing before your update.

I found a succinct post on the topic: http://c2.com/ppr/wiki/JavaIdioms/AlwaysDeclareSerialVersionUid.html

As it says in the linked document, you can access your old data by finding the hashed serialVersionUID used before your update. Assuming of course, the ID is actually the issue.