PROGUARD what can go wrong!

Overview

I updated my app, and things started to go wrong, everyone was crashing, I had no idea why, my own installs weren’t, it took several iterations and some additional debug information to figure out what went wrong.

I use proguard, it is an obfuscater of Java code, so it is harder to reverse engineer all android developers should be using this. One of the things proguard does is change the Java class and package names to something that is not too recognizable..

What I did wrong!

My app, the NZ Phone Account Widget, can get data from different sources, all of these need different processing to suit, so to match the “provider” as i call them to the account, I was saving the class name of the provider as a setting in the database, this is where proguard tripped me up. For quite a long while proguard must have kept the same obtuse names for the provider classes, then it changed.. So when the setting was read out of the database and used to find the class, it couldn’t find the class and returned a null..

Why did I not see it.

My tablet runs a debug version, which the class names are not obtuse, so the non obtuse names are saved in the database. My Phones database is rather old and stores an index id from an earlier database conversion (which is valid), and when I add new account for testing (I add/remove skinny for this), the new obtuse name was saved..

What specifically were the changes..

On the left, is the raw name, on the right is the obtuse name, see it change in the version..

mapping.2.262.789.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderTwoDegrees -> nz.org.winters.android.nzmobileaccountwidget.providers.a.g:
mapping.2.263.803.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderTwoDegrees -> nz.org.winters.android.nzmobileaccountwidget.b.a.g:
mapping.2.262.789.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderTelecomXT -> nz.org.winters.android.nzmobileaccountwidget.providers.a.f:
mapping.2.263.803.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderTelecomXT -> nz.org.winters.android.nzmobileaccountwidget.b.a.f:
mapping.2.262.789.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderSkinny -> nz.org.winters.android.nzmobileaccountwidget.providers.a.e:
mapping.2.263.803.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderSkinny -> nz.org.winters.android.nzmobileaccountwidget.b.a.e:
mapping.2.262.789.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderVodafone -> nz.org.winters.android.nzmobileaccountwidget.providers.a.h:
mapping.2.263.803.txt:nz.org.winters.android.nzmobileaccountwidget.providers.base.ProviderVodafone -> nz.org.winters.android.nzmobileaccountwidget.b.a.h:

How fixed/ worked around..

Basically, had to create 2 new methods on the provider interface, one to return a known text name eg “2DEGREES” this is now used as the setting for new accounts created. The other method takes the string from the setting and compares it against, the new text name, and the above obtuse names (both of them), this will get around all changes.

Morel of the story!

Don’t use class names to save as a setting when using proguard!

Leave a Reply

Your email address will not be published. Required fields are marked *