Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Proguard: avoiding naming collisions with pre-obfuscated library JARs

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?

like image 504
Dan Dyer Avatar asked Apr 25 '11 23:04

Dan Dyer


People also ask

Does ProGuard obfuscate package name?

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.

What is Dontwarn in ProGuard?

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)

How does ProGuard obfuscation work?

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.


2 Answers

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.

like image 162
sbridges Avatar answered Nov 08 '22 23:11

sbridges


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]

like image 30
MatPag Avatar answered Nov 09 '22 00:11

MatPag