Menu
It seems that Proguard doesn't make any attempt to avoid naming collisions with classes in library JARs when it renames/repackages classes. Is this correct, or have I just not configured it correctly?
I am obfuscating an Android application that uses the latest Google AdMob SDK. Previously I was using the old AdMob SDK without a problem. The new SDK JAR file contains some classes that have been obfuscated. One of these classes is a.class in the default/unnamed package. When I obfuscate my app, Proguard renames/repackages one of my classes to also be a.class in the unnamed package, despite having read in the AdMob JAR as a library JAR (so it ought to know that this will cause a collision). Predictably, my build fails when the dx tool attempts to combine these two identically named classes in a single .dex file.
As a workaround I have reconfigured Proguard so that it moves all of my classes into a named package (just a single letter) to avoid collisions with the Google classes, but I'm interested to know if there is a better solution or if this is a limitation of the current version (4.6) of Proguard?
504
By default, ProGuard obfuscates the code: it assigns new short random names to classes and class members. It removes internal attributes that are only useful for debugging, such as source files names, variable names, and line numbers.
If your code works fine without the missing classes, you can suppress the warnings with '-dontwarn' options. ( http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
In the obfuscation step, ProGuard renames classes and class members that are not entry points. In this entire process, keeping the entry points ensures that they can still be accessed by their original names. The preverification step is the only step that doesn't have to know the entry points.
From the progaurd manual,
If an input jar and a library jar contain classes in the same package, the obfuscated output jar may contain class names that overlap with class names in the library jar. This is most likely if the library jar has been obfuscated before, as it will then probably contain classes named 'a', 'b', etc. Packages should therefore never be split across input jars and library jars.
So it looks like using your own package is the recommended answer.
162
In closed libraries to prevent conflict between multiple obfuscated modules/libraries you should use
-keeppackagenames
proguard rule to prevent complete classes repackaging, otherwise you can find errors like:
Duplicate class a.a.a.a in [jetified-lib1] and a.a.a.a in [jetified-lib2]
30
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
