Beruflich Dokumente
Kultur Dokumente
Note: the configuration keeps the entry point '...', but not the descriptor class '...'
Your configuration contains a -keepoption to preserve the given method (or field), but no -keepoption for
the given class that is an argument type or return type in the method's descriptor. You may then want to keep
the class too. Otherwise, ProGuard will obfuscate its name, thus changing the method's signature. The method
might then become unfindable as an entry point, e.g. if it is part of a public API. You can automatically keep such
descriptor classes with the -keepoption modifier includedescriptorclasses(-
keep,includedescriptorclasses...). You can switch off these notes by specifying the -dontnoteoption.
Note: the configuration explicitly specifies '...' to keep library class '...'
Your configuration contains a -keepoption to preserve the given library class. However, you don't need to keep
any library classes. ProGuard always leaves underlying libraries unchanged. You can switch off these notes by
specifying the -dontnoteoption.
Note: the configuration doesn't specify which class members to keep for class '...'
Your configuration contains a -keepclassmembers/-keepclasseswithmembersoption to preserve fields
or methods in the given class, but it doesn't specify which fields or methods. This way, the option simply won't
have any effect. You probably want to specify one or more fields or methods, as usual between curly braces. You
can specify all fields or methods with a wildcard "*;". You should also consider if you just need the more
common -keepoption, which preserves all specified classes and class members. The overview of all keep
options can help. You can switch off these notes by specifying the -dontnoteoption.
Note: the configuration specifies that none of the methods of class '...' have any side effects
Your configuration contains an option -assumenosideeffectsto indicate that the specified methods don't
have any side effects. However, the configuration tries to match all methods, by using a wildcard like "*;". This
includes methods from java.lang.Object, such as wait()and notify(). Removing invocations of those
methods will most likely break your application. You should list the methods without side effects more
conservatively. You can switch off these notes by specifying the -dontnoteoption.
The standard Android build process automatically specifies the input jars for you. There may not be an easy way
to filter them to remove these notes. You could remove the duplicate classes manually from your libraries. You
should never explicitly specify the input jars yourself (with -injarsor -libraryjars), since you'll then get
duplicate definitions. You should also not add libraries to your application that are already part of the Android
run-time (notably org.w3c.dom, org.xml.sax, org.xmlpull.v1, org.apache.commons.logging.Log,
org.apache.http, and org.json). They are possibly inconsistent, and the run-time libraries would get
precedence anyway.
ProGuard may terminate when it encounters parsing errors or I/O errors, or some more serious warnings:
1. If the missing class is referenced from your own code, you may have forgotten to specify an essential library.
Just like when compiling all code from scratch, you must specify all libraries that the code is referencing,
directly or indirectly. If the library should be processed and included in the output, you should specify it with
-injars, otherwise you should specify it with -libraryjars.
For example, if ProGuard complains that it can't find a java.langclass, you have to make sure that you are
specifying the run-time library of your platform. For JSE, these are typically packaged in lib/rt.jar
(vm.jarfor IBM's JVM, and classes.jarin MacOS X). Other platforms like JME and Android have their
own run-time libraries. The examples section provides more details for the various platforms.
If ProGuard still complains that it can't find a javax.cryptoclass, you probably still have to specify
jce.jar, next to the more common rt.jar.
2. If the missing class is referenced from a pre-compiled third-party library, and your original code runs fine
without it, then the missing dependency doesn't seem to hurt. The cleanest solution is to filter out the
referencing class or classes from the input, with a filter like "-libraryjars
mylibrary.jar(!somepackage/SomeUnusedReferencingClass.class)". ProGuard will then skip
this class entirely in the input, and it will not bump into the problem of its missing reference. However, you
may then have to filter out other classes that are in turn referencing the removed class. In practice, this
works best if you can filter out entire unused packages at once, with a wildcard filter like "-libraryjars
mylibrary.jar(!someunusedpackage/**)".
3. If you don't feel like filtering out the problematic classes, you can try your luck with the -ignorewarnings
option, or even the -dontwarnoption. Only use these options if you really know what you're doing though.
The standard Android build process automatically specifies the input jars for you. Unfortunately, many pre-
compiled third-party libraries refer to other libraries that are not actually used and therefore not present. This
works fine in debug builds, but in release builds, ProGuard expects all libraries, so it can perform a proper static
analysis. For example, if ProGuard complains that it can't find a java.awtclass, then some library that you are
using is referring to java.awt. This is a bit shady, since Android doesn't have this package at all, but if your
application works anyway, you can let ProGuard accept it with "-dontwarn java.awt.**", for instance.
If the missing class is an Android run-time class, you should make sure that you are building against an Android
run-time that is sufficiently recent. You may need to change the build target in your project.propertiesfile
or build.gradlefile to that recent version. You can still specify a different minSdkVersionand a different
targetSdkVersionin your AndroidManifest.xmlfile.
Error: Can't find any super classes of ... (not even immediate super class ...)
Error: Can't find common super class of ... and ...
It seems like you tried to avoid the warnings from the previous paragraph by specifying -ignorewarningsor
-dontwarn, but it didn't work out. ProGuard's optimization step and preverification step really need the
missing classes to make sense of the code. Preferably, you would solve the problem by adding the missing
library, as discussed. If you're sure the class that references the missing class isn't used either, you could also
try filtering it out from the input, by adding a filter to the corresponding -injarsoption: "-injars
myapplication.jar(!somepackage/SomeUnusedClass.class)". As a final solution, you could switch off
optimization (-dontoptimize) and preverification (-dontpreverify).
If you're developing for Android and ProGuard complains that it can't find a method that is only available in a
recent version of the Android run-time, you should change the build target in your project.propertiesfile
or build.gradlefile to that recent version. You can still specify a different minSdkVersionand a different
targetSdkVersionin your AndroidManifest.xmlfile.
Alternatively, you may get away with ignoring the inconsistency with the options -ignorewarningsor even -
dontwarn. For instance, you can specify "-dontwarn mypackage.MyInconsistentClass".
Finally, should your program classes reside in the same packages as library classes and should they refer to
their package visible class members, then you should also specify the -
dontskipnonpubliclibraryclassmembersoption.
In Android development, sloppy libraries may contain duplicates of classes that are already present in the
Android run-time (notably org.w3c.dom, org.xml.sax, org.xmlpull.v1,
org.apache.commons.logging.Log, org.apache.http, and org.json). You must remove these classes
from your libraries, since they are possibly inconsistent, and the run-time libraries would get precedence
anyway.
Error: Expecting class path separator ';' before 'Files\Java\...' (in Windows)
If the path of your run-time jar contains spaces, like in "Program Files", you have to enclose it with single or
double quotes, as explained in the section on file names. This is actually true for all file names containing special
characters, on all platforms.
Error: Can't read [.../lib/rt.jar] (No such file or directory) (in MacOS X)
In MacOS X, the run-time classes may be in a different place than on most other platforms. You'll then have to
adapt your configuration, replacing the path <java.home>/lib/rt.jarby
<java.home>/../Classes/classes.jar.
Internal problem starting the ProGuard GUI (Cannot write XdndAware property) (in Linux)
In Linux, at least with Java 6, the GUI may not start properly, due to Sun Bug #7027598. The work-around at this
time is to specify the JVM option -DsuppressSwingDropSupport=truewhen running the GUI.
OutOfMemoryError
You can try increasing the heap size of the Java virtual machine, with the usual -Xmxoption:
You can also reduce the amount of memory that ProGuard needs by removing unnecessary library jars from
your configuration, or by filtering out unused library packages and classes.
StackOverflowError
This error might occur when processing a large code base on Windows (surprisingly, not so easily on Linux). In
theory, increasing the stack size of the Java virtual machine (with the usual -Xssoption) should help too. In
practice however, the -Xsssetting doesn't have any effect on the main thread, due to Sun Bug #4362291. As a
result, this solution will only work when running ProGuard in a different thread, e.g. from its GUI.
Unexpected error
ProGuard has encountered an unexpected condition, typically in the optimization step. It may or may not
recover. You should be able to avoid it using the -dontoptimizeoption. In any case, please report the
problem, preferably with the simplest example that causes ProGuard to crash.
Otherwise...
Maybe your class files are corrupt. See if recompiling them and trying again helps. If not, please report the
problem, preferably with the simplest example that causes ProGuard to crash.
Unexpected observations after processing If ProGuard seems to run fine, but your processed code doesn't look
right, there might be a couple of reasons: Disappearing classes
If you are working on Windows and it looks like some classes have disappeared from your output, you should
make sure you're not writing your output class files to a directory (or unpacking the output jar). On platforms
with case-insensitive file systems, such as Windows, unpacking tools often let class files with similar lower-case
and upper-case names overwrite each other. If you really can't switch to a different operating system, you could
consider using ProGuard's -dontusemixedcaseclassnamesoption.
Also, you should make sure your class files are in directories that correspond to their package names. ProGuard
will read misplaced class files, but it will currently not write their processed versions. Notably, class files that are
in the WEB-INF/classesdirectory in a war should be packaged in a jar and put in the WEB-INF/lib
directory.
If you are using marker interfaces to keep other classes, the marker interfaces themselves are probably being
removed in the shrinking step. You should therefore always explicitly keep any marker interfaces, with an option
like "-keep interface MyMarkerInterface".
Similarly, if you are keeping classes based on annotations, you may have to avoid that the annotation classes
themselves are removed in the shrinking step. You should package the annotation classes as a library, or
explicitly keep them in your program code with an option like "-keep @interface *".
Problems while converting to Android Dalvik bytecode If ProGuard seems to run fine, but the dx tool in the
Android SDK subsequently fails with an error: SimException: local variable type mismatch
This error indicates that ProGuard's optimization step has not been able to maintain the correct debug
information about local variables. This can happen if some code is optimized radically. Possible work-arounds:
let the java compiler not produce debug information (-g:none), or let ProGuard's obfuscation step remove the
debug information again (by not keeping the attributes LocalVariableTableand
LocalVariableTypeTablewith -keepattributes), or otherwise just disable optimization (-
dontoptimize).
Problems while preverifying for Java Micro Edition If ProGuard seems to run fine, but the external preverifier
subsequently produces errors, it's usually for a single reason: InvalidClassException, class loading error, or
verification error
If you get any such message from the preverifier, you are probably working on a platform with a case-insensitive
file system, such as Windows. The preverifytool always unpacks the jars, so class files with similar lower-case
and upper-case names overwrite each other. You can use ProGuard's -dontusemixedcaseclassnames
option to work around this problem.
If the above doesn't help, there is probably a bug in the optimization step of ProGuard. Make sure you are using
the latest version. You should be able to work around the problem by using the -dontoptimizeoption. You
can check the bug database to see if it is a known problem (often with a fix). Otherwise, please report it,
preferably with the simplest example on which you can find ProGuard to fail.
Note that it is no longer necessary to use an external preverifier. With the -microeditionoption, ProGuard
will preverify the class files for Java Micro Edition. Problems at run-time If ProGuard runs fine, but your
processed application doesn't work, there might be several reasons: Stack traces without class names or line
numbers
If your stack traces don't contain any class names or lines numbers, even though you are keeping the proper
attributes, make sure this debugging information is present in your compiled code to start with. Notably the Ant
javac task has debugging information switched off by default.
NoClassDefFoundError
Your class path is probably incorrect. It should at least contain all library jars and, of course, your processed
program jar.
ClassNotFoundException
Your code is probably calling Class.forName, trying to create the missing class dynamically. ProGuard can
only detect constant name arguments, like Class.forName("mypackage.MyClass"). For variable name
arguments like Class.forName(someClass), you have to keep all possible classes using the appropriate -
keepoption, e.g. "-keep class mypackage.MyClass" or "-keep class * implements
mypackage.MyInterface".
NoSuchFieldException
Your code is probably calling something like myClass.getField, trying to find some field dynamically. Since
ProGuard can't always detect this automatically, you have to keep the missing field in using the appropriate -
keepoption, e.g. "-keepclassmembers class mypackage.MyClass { int myField; }".
NoSuchMethodException
Your code is probably calling something like myClass.getMethod, trying to find some method dynamically.
Since ProGuard can't always detect this automatically, you have to keep the missing method in using the
appropriate -keepoption, e.g. "-keepclassmembers class mypackage.MyClass { void
myMethod(); }".
More specifically, if the method reported as missing is valuesor valueOf, you probably have to keep some
methods related to enumerations.
MissingResourceException or NullPointerException
Your processed code may be unable to find some resource files. ProGuard simply copies resource files over
from the input jars to the output jars. Their names and contents remain unchanged, unless you specify the
options -adaptresourcefilenamesand/or -adaptresourcefilecontents.
Furthermore, directory entries in jar files aren't copied, unless you specify the option -keepdirectories.
Note that Sun advises against calling Class.getResource()for directories (Sun Bug #4761949).
Disappearing annotations
By default, the obfuscation step removes all annotations. If your application relies on annotations to function
properly, you should explicitly keep them with -keepattributes *Annotation*.
InvalidClassException, class loading error, or verification error (in Java Micro Edition)
If you get such an error in Java Micro Edition, you may have forgotten to specify the -microeditionoption, so
the processed class files are preverified properly.
Error: No Such Field or Method, Error verifying method (in a Java Micro Edition emulator)
If you get such a message in a Motorola or Sony Ericsson phone emulator, it's because these emulators don't
like packageless classes and/or overloaded fields and methods. You can work around it by not using the options
-repackageclasses ''and -overloadaggressively. If you're using the JME WTK plugin, you can adapt
the configuration proguard/wtk/default.prothat's inside the proguard.jar.
You might also try using the -dontusemixedcaseclassnamesoption. Even if the midlet has been properly
processed and then preverified on a case-sensitive file system, the device itself might not like the mixed-case
class names. Notably, the Nokia N-Gage emulator works fine, but the actual device seems to exhibit this
problem.
Disappearing loops
If your code contains empty busy-waiting loops, ProGuard's optimization step may remove them. More
specifically, this happens if a loop continuously checks the value of a non-volatile field that is changed in a
different thread. The specifications of the Java Virtual Machine require that you always mark fields that are
accessed across different threads without further synchronization as volatile. If this is not possible for some
reason, you'll have to switch off optimization using the -dontoptimizeoption.
ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy
You are probably processing annotations involving enumerations. Again, you should make sure you're
preserving the special methods of the enumeration type, as shown in the examples.
NoSuchMethodError or AbstractMethodError
You should make sure you're not writing your output class files to a directory on a platform with a case-
insensitive file system, such as Windows. Please refer to the section about disappearing classes for details.
Furthermore, you should check whether you have specified your program jars and library jars properly. Program
classes can refer to library classes, but not the other way around.
If all of this seems ok, perhaps there's a bug in ProGuard (gasp!). If so, please report it, preferably with the
simplest example on which you can find ProGuard to fail.
VerifyError
Verification errors when executing a program are almost certainly the result of a bug in the optimization step of
ProGuard. Make sure you are using the latest version. You should be able to work around the problem by using
the -dontoptimizeoption. You can check the bug database to see if it is a known problem (often with a fix).
Otherwise, please report it, preferably with the simplest example on which ProGuard fails.