Warm tip: This article is reproduced from stackoverflow.com, please click
java obfuscation proguard

Proguard: avoiding naming collisions with pre-obfuscated library JARs

发布于 2020-05-21 16:00:28

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?

Questioner
Dan Dyer
Viewed
13
sbridges 2011-04-26 09:07

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.