Limitations |
---|
When using ProGuard, you should be aware of a few minor issues, all of which are easily avoided or resolved:
ExternalClass$InternalClass
, for instance (cfr. The Java Language Specification, Second Edition, Section 13.1). This should not present a problem in practice, since
the rule is mainly intended for transformations at the source code level.
Internal-external class relationships are still represented correctly
inside the binary class files. Decompilers or others tools that rely on
the naming rule may have problems processing obfuscated jars.
Class.forName
and
.class
constructs with constant classes. There is one caveat,
however, when processing libraries that are to be used as such after
obfuscation. The javac compiler compiles .class
to a static
method, class$(String)
. This method calls
Class.forName
and returns a Class
object,
catching some exceptions along the way. ProGuard detects occurrences of
the method. However, if you're using an obfuscated library, the
class$
method may have received a different name, thus
escaping ProGuard's attention. The simple solution is to preserve the name
of this method when obfuscating libraries, as illustrated in this example.
-dontskipnonpubliclibraryclasses
option.
-keep class * implements MyKeepInterface
", and
MyKeepInterface
is not used in your code, the specified
classes are kept, but they are obfuscated. Technically, the interface is
removed in the shrinking phase, making the directive void in the
obfuscation phase. This behavior may be fixed in the future. For now, you
can get around it by explicitly keeping the interface as well:
"-keep class MyKeepInterface
". In any case, creating a proper
configuration file seems a cleaner solution than using such an obfuscation
marker interface.