Problem with Proguard and XmlPullParser

Question

I\'m having a bit of trouble on an Android project using Proguard with some libraries. Specifically, i\'m having an XmlPullParser collision, and no matter what i seem to do,

Answer 1

To let library classes take precedence and shut up Proguard, put this in main-rules.xml (but copy a part to build.xml first):

            -libraryjars ${android.libraryjars}(!org/xmlpull/v1/XmlPullParser.class,!org/xmlpull/v1/XmlPullParserException.class)

You'll run into other problems with XStream as well, see: Proguard and XStream with omitField() on Android

For the whole story: https://plus.google.com/112617873637231221858/posts/YxWrEJRMSo4

Answer 2

This works for me:

-dontwarn org.xmlpull.v1.**
-dontnote org.xmlpull.v1.**
-keep class org.xmlpull.** { *; }

Answer 3

XML parsing can be a real pain on Android. I recently ran into similar issues when trying to use Jackson XML data binding on Android.

I ended up using the tool Jar Jar Links to move the conflicting classes in the libraries I was trying to use to a new package name that doesn't conflict with the Android platform classes:

http://code.google.com/p/jarjar/

You can tell Jar Jar Links to find the namespaces in the XML library JAR files that we provide that conflict with Android (i.e., javax.xml.stream.*), and have JarJar rename them to something that doesn't conflict (i.e., edu.usf.cutr.javax.xml.stream.*). Android will then accept the libraries that doesn't conflict without the Conversion to Dalvik format failed with error 1.

Here's a zip file that includes files I used to do a batch conversion of the XML libraries I needed, which were:

• StAX API - JSR 173 API interface definitions. Also see Wikipedia StAX entry for more info.
• StAX2 API - Experimental expansion of the original StAX API used by Aalto
• Aalto - StAX 1 and 2 XML parser implementation
• jackson-dataformat-xml - integrates the above XML parser APIs and implementations with the core Jackson project

The generate_android_jarsv21.bat batch file is included to automate the conversion process using JarJar for multiple XML library JARs at once.

JarJar uses a series of rules to change the namespaces in the JAR files. Here's the contents of my rules.txt file that renames all occurences of javax.xml.stream.* to edu.usf.cutr.javax.xml.stream.*:

rule javax.xml.stream.** edu.usf.cutr.javax.xml.stream.@1

You should be able to follow a similar process for the XML libraries you're working with. Once the collision in packages is resolved by moving the library classes to a new package, the other down-stream issues with Proguard should resolve themselves.

I wrote a full tutorial here that includes more detail on "Modifying XML libraries for Android":

https://github.com/CUTR-at-USF/SiriRestClient/wiki/Modifying-XML-libraries-for-Android

Answer 4

Your ProGuard configuration and build process seem to be mixing up program jars and library jars.

For ProGuard, you can probably specify all the listed jars as input jars (with -injars). Their processed versions will end up in the output jar (-outjars).

You can indeed avoid warnings about duplicate xmlpull classes by filtering them out of android.jar. ProGuard will also print out warnings should there be any duplicates in the input jars. You can then filter out those duplicates as well.

You should not specify <java.home>/lib/rt.jar as a library jar, since this jar is not present as a library on Android devices either. Some of the listed jars depend on it though, so at least parts of them are not entirely compatible with the Android runtime. The cleanest solution to avoid warnings about offending classes is to filter them out of the corresponding input jars (e.g. a filter !com/thoughtworks/xstream/converters/extended/ColorConverter.class). Alternatively, you can bluntly switch off these warnings (e.g. -dontwarn com.thoughtworks.xstream.converters.extended.ColorConverter).

For the Dalvik compiler, you should only specify the processed output jar, not any of the program jars that went into it. Otherwise, you will get duplicate classes: some unprocessed copies and some partly obfuscated copies. They don't blend and lead to Error1 and NoSuchMethodErrors.