Proguard obfuscation breaks down a Serializable class after adding the serialVersionUID field

we have two versions of a .aar, say it version A and B, with a class MySerializableClass implementing the Serializable Interface.
In the version A, MySerializableClass does not have the serialVersionUID field defined, in the version B it is defined.
The .aar is integrated into an Android Application. When the App is not Proguard obfuscated, the serialization is done correctly, thus, after upgrading from App A (with .aar version A) to App B (with .aar version B) the new MySerializableClass correctly deserializes the old version class.
If the Android App is obfuscated by Proguard, the serialization doesn’t work.
I tried to put the known keep rules:
-keepnames class * implements

-keepclassmembers class * implements {
    static final long serialVersionUID;
    private static final[] serialPersistentFields;
    !static !transient <fields>;
    !private <fields>;
    !private <methods>;
    private void writeObject(;
    private void readObject(;
    java.lang.Object writeReplace();
    java.lang.Object readResolve();

but with no success.

I suppose that the problem is that in the A version the serialVersionUID is missing, so it is computed at runtime. As such, it will be different by the serialVersionUID defined in the B version.

Do you have any hints about solving this issue? Thanks a lot in advance


Dear @claudio.maraniello

First of all, thanks for posting your question and welcome to our community!

I am not sure if I understand the question correctly so let me rephrase it below:

Do you mean that you are making 2 apps, containing exactly the same code base except for .aar you are producing?
Do you mean that when you try to install the obfuscated version of App A, serialization works. But, once you deleted that app and installed the obfuscated version of App B, the serialization does not work anymore ? And you suspect that this happens because .aar version B has a new field which is obfuscated by ProGuard at the moment, but shouldn’t be ?

If this is an accurate representation of the problem, I would encourage you to take a look at the source code you currently have written to narrow down the keep rule you currently used a bit.

It would be a good idea to define a specific keep rule to keep this field which resides in a certain class MySerializableClass.

You can also try to use -addconfigurationdebugging (Add it as an extra line in your configuration file) to find the keep rule necessary to fix the problem:

This option specifies to instrument the processed code with debugging statements that print out suggestions for missing ProGuard configuration. This can be very useful to get practical hints at run-time , if your processed code crashes because it still lacks some configuration for reflection. For example, the code may be serializing classes with the GSON library and you may need some configuration for it. You can generally just copy/paste the suggestions from the console into your configuration file. Counter-indication: do not use this option in release versions, as it adds obfuscation information to the processed code.

Kind regards,