ProGuard may terminate when it encounters parsing errors or I/O errors, or
some more serious warnings:
- Warning: can't find superclass or interface
Warning: can't find referenced class
- A class in one of your program jars or library jars is referring to a
class or interface that is missing from the input. The warning lists both
the referencing class(es) and the missing referenced class(es). There can
be a few reasons, with their own solutions:
- 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.lang class, 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.jar for
IBM's JVM, and classes.jar in 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.crypto class, you probably still have to specify
jce.jar, next to the more common rt.jar.
- 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/**)".
- If you don't feel like filtering out the problematic classes, you can
try your luck with the
-ignorewarnings
option, or even
the -dontwarn option.
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.awt class, 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.properties file or build.gradle file to
that recent version. You can still specify a different
minSdkVersion and a different targetSdkVersion
in your AndroidManifest.xml file.
- 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
-ignorewarnings
or -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 -injars option:
"-injars
myapplication.jar(!somepackage/SomeUnusedClass.class)". As a final
solution, you could switch off optimization
(-dontoptimize) and
preverification
(-dontpreverify).
- Warning: can't find referenced field/method '...' in program class ...
- A program class is referring to a field or a method that is missing from
another program class. The warning lists both the referencing class and
the missing referenced class member. Your compiled class files are most
likely inconsistent. Possibly, some class file didn't get recompiled
properly, or some class file was left behind after its source file was
removed. Try removing all compiled class files and rebuilding your
project.
- Warning: can't find referenced field/method '...' in library class ...
- A program class is referring to a field or a method that is missing from a
library class. The warning lists both the referencing class and the
missing referenced class member. Your compiled class files are
inconsistent with the libraries. You may need to recompile the class
files, or otherwise upgrade the libraries to consistent versions.
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.properties file or build.gradle file to
that recent version. You can still specify a different
minSdkVersion and a different targetSdkVersion
in your AndroidManifest.xml file.
Alternatively, you may get away with ignoring the inconsistency with the
options
-ignorewarnings or
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
-dontskipnonpubliclibraryclassmembers
option.
- Warning: can't find enclosing class/method
- If there are unresolved references to classes that are defined inside
methods in your input, once more, your compiled class files are most likely
inconsistent. Possibly, some class file didn't get recompiled properly, or
some class file was left behind after its source file was removed. Try
removing all compiled class files and rebuilding your project.
- Warning: library class ... depends on program class ...
- If any of your library classes depend on your program classes, by
extending, implementing or just referencing them, your processed code will
generally be unusable. Program classes can depend on library classes, but
not the other way around. Program classes are processed, while library
classes always remain unchanged. It is therefore impossible to adapt
references from library classes to program classes, for instance if the
program classes are renamed. You should define a clean separation between
program code (specified with
-injars) and library code
(specified with -libraryjars), and try
again.
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.
- Warning: class file ... unexpectedly contains class ...
- The given class file contains a definition for the given class, but the
directory name of the file doesn't correspond to the package name of the
class. ProGuard will accept the class definition, but the current
implementation will not write out the processed version. Please make sure
your input classes are packaged correctly. Notably, class files that are
in the
WEB-INF/classes directory in a war should be packaged
in a jar and put in the WEB-INF/lib directory. If you don't
mind these classes not being written to the output, you can specify the -ignorewarnings option,
or even the -dontwarn
option.
- Warning: ... is not being kept as ..., but remapped to ...
- There is a conflict between a
-keep option in the
configuration, and the mapping file, in the obfuscation step. The given
class name or class member name can't be kept by its original name, as
specified in the configuration, but it has to be mapped to the other given
name, as specified in the mapping file. You should adapt your
configuration or your mapping file to remove the conflict. Alternatively,
if you're sure the renaming won't hurt, you can specify the -ignorewarnings option,
or even the -dontwarn
option.
- Warning: field/method ... can't be mapped to ...
- There is a conflict between some new program code and the mapping file, in
the obfuscation step. The given class member can't be mapped to the given
name, because it would conflict with another class member that is already
being mapped to the same name. This can happen if you are performing
incremental obfuscation, applying an obfuscation mapping file from an
initial obfuscation step. For instance, some new class may have been added
that extends two existing classes, introducing a conflict in the name
space of its class members. If you're sure the class member receiving
another name than the one specified won't hurt, you can specify the
-ignorewarnings option,
or even the -dontwarn
option. Note that you should always use the -useuniqueclassmembernames
option in the initial obfuscation step, in order to reduce the risk of
conflicts.
- Error: Unsupported class version number
- You are trying to process class files compiled for a recent version of
Java that your copy of ProGuard doesn't support yet. You
should check
on-line if there is a more recent release.
- Error: You have to specify '-keep' options
- You either forgot to specify
-keep options, or you mistyped the
class names. ProGuard has to know exactly what you want to keep: an
application, an applet, a servlet, a midlet,..., or any combination of
these. Without the proper seed specifications, ProGuard would shrink,
optimize, or obfuscate all class files away.
- 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.jar by
<java.home>/../Classes/classes.jar.
- Error: Can't read ...
- ProGuard can't read the specified file or directory. Double-check that the
name is correct in your configuration, that the file is readable, and that
it is not corrupt. An additional message "Unexpected end of ZLIB input
stream" suggests that the file is truncated. You should then make sure
that the file is complete on disk when ProGuard starts (asynchronous
copying? unflushed buffer or cache?), and that it is not somehow
overwritten by ProGuard's own output.
- Error: Can't write ...
- ProGuard can't write the specified file or directory. Double-check that
the name is correct in your configuration and that the file is
writable.
- 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=true when running the
GUI.
- 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 -keep option, 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 -keep option, 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 -keep option, e.g.
"-keepclassmembers class mypackage.MyClass { void myMethod();
}".
More specifically, if the method reported as missing is
values or 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
-adaptresourcefilenames
and/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*.
- Invalid or corrupt jarfile
- You are probably starting your application with the java option
-jar instead of the option -classpath. The java
virtual machine returns with this error message if your jar doesn't
contain a manifest file (META-INF/MANIFEST.MF), if the
manifest file doesn't specify a main class (Main-Class: ...),
or if the jar doesn't contain this main class. You should then make sure
that the input jar contains a valid manifest file to start with, that this
manifest file is the one that is copied (the first manifest file that is
encountered), and that the main class is kept in your configuration,
- InvalidJarIndexException: Invalid index
- At least one of your processed jar files contains an index file
META-INF/INDEX.LIST, listing all class files in the jar.
ProGuard by default copies files like these unchanged. ProGuard may however
remove or rename classes, thus invalidating the file. You should filter the
index file out of the input
(-injars in.jar(!META-INF/INDEX.LIST)) or update the file
after having applied ProGuard (jar -i out.jar).
- 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
-microedition option, 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.pro that's inside the
proguard.jar.
- Failing midlets (on a Java Micro Edition device)
- If your midlet runs in an emulator and on some devices, but not on some
other devices, this is probably due to a bug in the latter devices. For
some older Motorola and Nokia phones, you might try specifying the
-useuniqueclassmembernames
option. It avoids overloading class member names, which triggers a bug in
their java virtual machine.
You might also try using the -dontusemixedcaseclassnames
option. 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
-dontoptimize
option.
- SecurityException: SHA1 digest error
- You may have forgotten to sign your program jar after having
processed it with ProGuard.
- ClassCastException: class not an enum, or
IllegalArgumentException: class not an enum type
- You should make sure you're preserving the special methods of enumeration
types, which the run-time environment calls by introspection. The required
options are shown in the examples.
- 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.
- IllegalArgumentException: methods with same signature but incompatible return types
- You are probably running some code that has been obfuscated
with the
-overloadaggressively
option. The class java.lang.reflect.Proxy can't handle
classes that contain methods with the same names and signatures, but
different return types. Its method newProxyInstance then
throws this exception. You can avoid the problem by not using the
option.
- CompilerError: duplicate addition
- You are probably compiling or running some code that has been obfuscated
with the
-overloadaggressively
option. This option triggers a bug in
sun.tools.java.MethodSet.add in Sun's JDK 1.2.2, which is
used for (dynamic) compilation. You should then avoid this option.
- ClassFormatError: repetitive field name/signature
- You are probably processing some code that has been obfuscated before with
the
-overloadaggressively
option. You should then use the same option again in the second processing
round.
- ClassFormatError: Invalid index in LocalVariableTable in class file
- If you are keeping the
LocalVariableTable or
LocalVariableTypeTable attributes, ProGuard's optimizing step
is sometimes unable to update them consistently. You should then let the
obfuscation step remove these attributes or disable the optimization
step.
- 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
-dontoptimize
option. 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.