Question

I was using XStream for deserialization of xml in my Android app, and now I’m struggling to add Proguard (obfuscator) to the mix.

Here’s the runtime exception I run into (full: pastebin):

WARN/System.err(6209): net.lp.collectionista.util.a.g: XStream could not parse the response
WARN/System.err(6209):     at net.lp.collectionista.a.s.a(Collectionista:215)
    ...
WARN/System.err(6209): Caused by: com.thoughtworks.xstream.converters.ConversionException: id : id in loader dalvik.system.PathClassLoader[/data/app/net.lp.collectionista-2.apk] : id : id in loader dalvik.system.PathClassLoader[/data/app/net.lp.collectionista-2.apk]
WARN/System.err(6209): ---- Debugging information ----
WARN/System.err(6209): message             : id : id in loader dalvik.system.PathClassLoader[/data/app/net.lp.collectionista-2.apk]
WARN/System.err(6209): cause-exception     : com.thoughtworks.xstream.mapper.CannotResolveClassException
WARN/System.err(6209): cause-message       : id : id in loader dalvik.system.PathClassLoader[/data/app/net.lp.collectionista-2.apk]
WARN/System.err(6209): class               : net.lp.collectionista.jaxb.googlebooks.search.Feed
WARN/System.err(6209): required-type       : java.lang.Object
WARN/System.err(6209): path                : /feed/entry/id
WARN/System.err(6209): line number         : 1
WARN/System.err(6209): -------------------------------
WARN/System.err(6209):     at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(Collectionista:89)
    ...
WARN/System.err(6209):     at com.thoughtworks.xstream.XStream.fromXML(Collectionista:861)
    ...
WARN/System.err(6209): Caused by: com.thoughtworks.xstream.mapper.CannotResolveClassException: id : id in loader dalvik.system.PathClassLoader[/data/app/net.lp.collectionista-2.apk]
WARN/System.err(6209):     at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(Collectionista:68)
    ...

Needless to say this works fine without Proguard. I’m using shrinking, optimizing and obfuscating here, though I disabled it all on any XStream class, as well as any class that stands model for the xml fields:

-keep class net.lp.collectionista.jaxb.** { *; }
-keep class com.thoughtworks.xstream.** { *; }

I can confirm, from the obfuscated jar, as well as from the mapping.txt (for methods), that any classes mentioned exist and are not obfuscated, so untouched AFAICT. I also am retaining annotations.

The exception is pretty clear to me. I have:

        xstream.omitField(Feed.class, "id");

among others. It seems the omitField() call does not work anymore and it starts looking for an “id” model class, because of Proguard. This is where I am stuck, even after diving into the XStream code. The whole omitField call in the obfuscated end result seems to be intact, so what could be additionally broken here? It should also not be “Feed.class” as that one is also still there. What am I missing? What is a good next step for debugging?

EDIT: I did notice the class files of xstream classes in my obfuscated jar are slightly smaller than the original ones, even with -dontoptimize. What is still being dropped?

EDIT2: I’m starting to think it has to do with the absence of dex warnings similar to the following:

[apply] warning: Ignoring InnerClasses attribute for an anonymous inner class
[apply] (com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$1) that doesn't come with an
[apply] associated EnclosingMethod attribute. This class was probably produced by a
[apply] compiler that did not target the modern .class file format. The recommended
[apply] solution is to recompile the class from source, using an up-to-date compiler
[apply] and without specifying any "-target" type options. The consequence of ignoring
[apply] this warning is that reflective operations on this class will incorrectly
[apply] indicate that it is *not* an inner class.

… or maybe not …

EDIT3: Finally, in spite of dealing with many other bugs and problems such as the SimException bug, I’ve been able to get it working in some limited cases. That way I could pinpoint it to the obfuscation step. That is, at least, if I add “-dontobfuscate”, the problem goes away. it isn’t the first time I’m playing with that, so it must be the workarounds for the other problems, or the narrower configuration, that alleviates this problem as well. So here’s me asking again: When I’ve already safeguarded the main parts of xstream and my model classes from obfuscation using “-keep”, then what else could be creating this mess?

If you need more info, let me know.

Answer 1

As I said, the problem disappears if you -dontobfuscate but let’s suppose you don’t want that.

The solution is to keep more attributes:

-keepattributes EnclosingMethod, InnerClasses
-keepattributes *Annotation*
-keepattributes Signature

Once you get it working you can narrow down which parts of the XStream code to keep as well. I have:

-keep class com.thoughtworks.xstream.converters.extended.SubjectConverter { *; }
-keep class com.thoughtworks.xstream.converters.extended.ThrowableConverter { *; }
-keep class com.thoughtworks.xstream.converters.extended.StackTraceElementConverter { *; }
-keep class com.thoughtworks.xstream.converters.extended.CurrencyConverter { *; }
-keep class com.thoughtworks.xstream.converters.extended.RegexPatternConverter { *; }
-keep class com.thoughtworks.xstream.converters.extended.CharsetConverter { *; }

-keep class com.thoughtworks.xstream.annotations.** { *; }

You can also disable a lot of warnings related to XStream.

For more details you can find my version controlled project files here:

• proguard.cfg

• build.xml