Posted by: Rotem Matityahu

The shrinker obfuscates the members’ names to short and meaningless names, in the same order as the class declares them. This process happens in each build.
In the first app version, the obfuscated Settings structure looks like this:
{“a”: Int, “b”: String, “c”: Float, “d”: Boolean}
Now let’s take a look at 2 scenarios:

• In the updated version the first field was deleted: The shrinker will assign the fields in the same order they’re written in the object and the Settings structure will look like this: {“a”: String, “b”: Float, “c”: Boolean}.
• In the updated version the first and second fields were swapped:The shrinker will change the structure to be : {“a”: String, “b”: Int, “c”: Float, “d”: Boolean}.

In both scenarios, there’s a fields’ types mismatch between the first and the updated versions. Therefore, the persisted object in the first version’s scheme will be failed to be parsed in the updated version’s scheme.

In my case, it was the fontSize removal.
Got it! To fix the issue I just need to add fontSize again to the Settingsobject (in the same order as it was before) and the parsing will succeed because all the original members exist in the Settings class.

But did that really solve my issue? Not so fast.
I added the missing member, so why is the Settings object still not being parsed?

Then it finally hit me — I didn’t use the member; even invoking the member’s getter would have been enough.
The code shrinker will discard members that aren’t used (and on the way almost made me go to a shrink). This is what it does! It is equivalent to removing the members by yourself.

Getting it right

As responsible developers, we always test our code during development, but we do it using a debug build (because who has time to wait for Proguard in every build?). Eventually, these types of issues fall between the cracks.

Ok, so how can we prevent and resolve persistent data migration issues in Android, similar to the one I’ve encountered?

Prevention

First and foremost, think carefully about which data persistence API is better for your use case when dealing with objects:

1. Collections of objects: Prefer using a database. There’s a migration process to implement in order to add or remove members from DB objects.
2. Single objects: Forget about SharedPreferences and go take a look at Proto DataStore. It offers compile-time safety and supports migration from version to version, using a predefined scheme.

If you still insist on using SharedPreferences and JSON, always provide a name to serialized members.
Depending on the JSON parsing library you’re using, there are several options. With Gson, for example, you can use @SerializeName and in Moshi you have the @Json annotation (most serialization libraries will have a similar feature).
This way, you are decoupling the members’ names and how they are being saved, which protects you from any future change in the stored object structure.
Take notice though, this solution might expose your business logic through the member names.

For a more generic solution, you can create a custom annotation, annotate the persisted object and add a Progaurd rule: keepnames.
Usage: -keepnames @com.your.annotation.package.PersistedObject public class * { *; }
By using this rule, the shrinker will keep the members’ names and won’t discard unused members. When storing an object this way, its members’ names will be saved as they are (without any obfuscation).
For that reason, beware of changing the members’ names after the object has been saved since the parse will fail.

Recovery

There’s actually just one solution, and you probably knew it was coming: Migration. Parse the Object in the old format, map it to the new format and save it again.
Jetpack DataStore offers a simple and straightforward migration API from SharedPreferences.