730 lines
38 KiB
HTML
730 lines
38 KiB
HTML
|
<!doctype html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
||
|
|
<meta http-equiv="content-style-type" content="text/css">
|
||
|
|
<link rel="stylesheet" type="text/css" href="style.css">
|
||
|
|
<title>ProGuard Troubleshooting</title>
|
||
|
|
<script type="text/javascript" language="JavaScript">
|
||
|
|
<!--
|
||
|
|
if (window.self==window.top)
|
||
|
|
window.top.location.replace("../index.html#"+window.location.pathname+window.location.hash);
|
||
|
|
else {
|
||
|
|
var hash="#"+window.location.pathname.replace(window.top.location.pathname.replace("index.html", ""), "");
|
||
|
|
if (window.top.location.hash!=hash)
|
||
|
|
window.top.location.hash=hash;
|
||
|
|
}
|
||
|
|
//-->
|
||
|
|
</script>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<h2>Troubleshooting</h2>
|
||
|
|
|
||
|
|
While preparing a configuration for processing your code, you may bump into a
|
||
|
|
few problems. The following sections discuss some common issues and solutions:
|
||
|
|
|
||
|
|
<h3><a href="#processing">Problems while processing</a></h3>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#dynamicalclass">Note: can't find dynamically referenced class</a></li>
|
||
|
|
<li><a href="#dynamicalclasscast">Note: ... calls '(...)Class.forName(variable).newInstance()'</a></li>
|
||
|
|
<li><a href="#dynamicalclassmember">Note: ... accesses a field/method '...' dynamically</a></li>
|
||
|
|
<li><a href="#descriptorclass">Note: the configuration keeps the entry point '...', but not the descriptor class '...'</a></li>
|
||
|
|
<li><a href="#classmembers">Note: the configuration doesn't specify which class members to keep for class '...'</a></li>
|
||
|
|
<li><a href="#duplicateclass">Note: duplicate definition of program/library class</a></li>
|
||
|
|
<li><a href="#duplicatezipentry">Warning: can't write resource ... Duplicate zip entry</a></li>
|
||
|
|
<li><a href="#unresolvedclass">Warning: can't find superclass or interface</a></li>
|
||
|
|
<li><a href="#unresolvedclass">Warning: can't find referenced class</a></li>
|
||
|
|
<li><a href="#superclass">Error: Can't find any super classes of ... (not even immediate super class ...)</a></li>
|
||
|
|
<li><a href="#superclass">Error: Can't find common super class of ... and ...</a></li>
|
||
|
|
<li><a href="#unresolvedclassmember">Warning: can't find referenced field/method</a></li>
|
||
|
|
<li><a href="#unresolvedenclosingmethod">Warning: can't find enclosing class/method</a></li>
|
||
|
|
<li><a href="#dependency">Warning: library class ... depends on program class ...</a></li>
|
||
|
|
<li><a href="#unexpectedclass">Warning: class file ... unexpectedly contains class ...</a></li>
|
||
|
|
<li><a href="#mappingconflict1">Warning: ... is not being kept as ..., but remapped to ...</a></li>
|
||
|
|
<li><a href="#mappingconflict2">Warning: field/method ... can't be mapped to ...</a></li>
|
||
|
|
<li><a href="#unsupportedclassversion">Error: Unsupported class version number</a></li>
|
||
|
|
<li><a href="#keep">Error: You have to specify '-keep' options</a></li>
|
||
|
|
<li><a href="#filename">Error: Expecting class path separator ';' before 'Files\Java\...' (in Windows)</a></li>
|
||
|
|
<li><a href="#macosx">Error: Can't read [.../lib/rt.jar] (No such file or directory) (in MacOS X)</a></li>
|
||
|
|
<li><a href="#startinggui">Internal problem starting the ProGuard GUI (Cannot write XdndAware property) (in Linux)</a></li>
|
||
|
|
<li><a href="#outofmemoryerror">OutOfMemoryError</a></li>
|
||
|
|
<li><a href="#stackoverflowerror">StackOverflowError</a></li>
|
||
|
|
<li><a href="#unexpectederror">Unexpected error</a></li>
|
||
|
|
<li><a href="#otherwise">Otherwise...</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3><a href="#afterprocessing">Unexpected observations after processing</a></h3>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#disappearingclasses">Disappearing classes</a></li>
|
||
|
|
<li><a href="#notkept">Classes or class members not being kept</a></li>
|
||
|
|
<li><a href="#notobfuscated">Variable names not being obfuscated</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3><a href="#dalvik">Problems while converting to Android Dalvik bytecode</a></h3>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#simexception">SimException: local variable type mismatch</a></li>
|
||
|
|
<li><a href="#conversionerror">Conversion to Dalvik format failed with error 1</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3><a href="#preverifying">Problems while preverifying for Java Micro Edition</a></h3>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#invalidclassexception1">InvalidClassException, class loading error, or verification error</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3><a href="#runtime">Problems at run-time</a></h3>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#stacktraces">Stack traces without class names or line numbers</a></li>
|
||
|
|
<li><a href="#noclassdeffounderror">NoClassDefFoundError</a></li>
|
||
|
|
<li><a href="#classnotfoundexception">ClassNotFoundException</a></li>
|
||
|
|
<li><a href="#nosuchmethodexception">NoSuchMethodException</a></li>
|
||
|
|
<li><a href="#missingresourceexception">MissingResourceException or NullPointerException</a></li>
|
||
|
|
<li><a href="#disappearingannotations">Disappearing annotations</a></li>
|
||
|
|
<li><a href="#invalidjarfile">Invalid or corrupt jarfile</a></li>
|
||
|
|
<li><a href="#invalidjarindexexception">InvalidJarIndexException: Invalid index</a></li>
|
||
|
|
<li><a href="#invalidclassexception2">InvalidClassException, class loading error, or verification error (in Java Micro Edition)</a></li>
|
||
|
|
<li><a href="#nosuchfieldormethod">Error: No Such Field or Method, Error verifying method (in a Java Micro Edition emulator)</a></li>
|
||
|
|
<li><a href="#failingmidlets">Failing midlets (on a Java Micro Edition device)</a></li>
|
||
|
|
<li><a href="#disappearingloops">Disappearing loops</a></li>
|
||
|
|
<li><a href="#securityexception">SecurityException: SHA1 digest error</a></li>
|
||
|
|
<li><a href="#classcastexception">ClassCastException: class not an enum</a></li><li><a href="#classcastexception">IllegalArgumentException: class not an enum type</a></li>
|
||
|
|
<li><a href="#arraystoreexception">ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</a></li>
|
||
|
|
<li><a href="#compilererror">CompilerError: duplicate addition</a></li>
|
||
|
|
<li><a href="#classformaterror1">ClassFormatError: repetitive field name/signature</a></li>
|
||
|
|
<li><a href="#classformaterror2">ClassFormatError: Invalid index in LocalVariableTable in class file</a></li>
|
||
|
|
<li><a href="#nosuchmethoderror">NoSuchMethodError or AbstractMethodError</a></li>
|
||
|
|
<li><a href="#verifyerror">VerifyError</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<h2><a name="processing">Problems while processing</a></h2>
|
||
|
|
|
||
|
|
ProGuard may print out some notes and non-fatal warnings:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="dynamicalclass"><b>Note: can't find dynamically referenced class</b></a></dt>
|
||
|
|
|
||
|
|
<dd>ProGuard can't find a class or interface that your code is accessing by
|
||
|
|
means of introspection. You should check if you want to add the jar that
|
||
|
|
contains this class.</dd>
|
||
|
|
|
||
|
|
<dt><a name="dynamicalclasscast"><b>Note: ... calls '(...)Class.forName(variable).newInstance()'</b></a></dt>
|
||
|
|
|
||
|
|
<dd>ProGuard lists all class casts of dynamically created class instances,
|
||
|
|
like "<code>(MyClass)Class.forName(variable).newInstance()</code>".
|
||
|
|
Depending on your application, you may need to keep the mentioned classes
|
||
|
|
with an option like "<code>-keep class MyClass</code>", or their
|
||
|
|
implementations with an option like "<code>-keep class * implements
|
||
|
|
MyClass</code>". You can switch off these notes by specifying the
|
||
|
|
<a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="dynamicalclassmember"><b>Note: ... accesses a field/method '...' dynamically</b></a></dt>
|
||
|
|
|
||
|
|
<dd>ProGuard lists a number of constructs like
|
||
|
|
"<code>.getField("myField")</code>". Depending on your application, you
|
||
|
|
may need to figure out where the mentioned class members are defined and
|
||
|
|
keep them with an option like "<code>-keep class MyClass { MyFieldType
|
||
|
|
myField; }</code>". Otherwise, ProGuard might remove or obfuscate the
|
||
|
|
class members, since it can't know which ones they are exactly. It does
|
||
|
|
list possible candidates, for your information. You can switch off these
|
||
|
|
notes by specifying the <a
|
||
|
|
href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="descriptorclass"><b>Note: the configuration keeps the entry point '...', but not the descriptor class '...'</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your configuration contains a <code>-keep</code> option to preserve the
|
||
|
|
given method (or field), but no <code>-keep</code> option 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 switch off these notes by specifying the <a
|
||
|
|
href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="classmembers"><b>Note: the configuration doesn't specify which class members to keep for class '...'</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your configuration contains
|
||
|
|
a <code>-keepclassmembers/-keepclasseswithmembers</code> option 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 "<code>*;</code>". You can switch off these notes by specifying
|
||
|
|
the <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="duplicateclass"><b>Note: duplicate definition of program/library class</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your program jars or library jars contain multiple definitions of the
|
||
|
|
listed classes. ProGuard continues processing as usual, only considering
|
||
|
|
the first definitions. The warning may be an indication of some problem
|
||
|
|
though, so it's advisable to remove the duplicates. A convenient way to do
|
||
|
|
so is by specifying filters on the input jars or library jars. You can
|
||
|
|
switch off these notes by specifying the <a
|
||
|
|
href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="duplicatezipentry"><b>Warning: can't write resource ... Duplicate zip entry</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your input jars contain multiple resource files with the same name.
|
||
|
|
ProGuard continues copying the resource files as usual, skipping any files
|
||
|
|
with previously used names. Once more, the warning may be an indication of
|
||
|
|
some problem though, so it's advisable to remove the duplicates. A
|
||
|
|
convenient way to do so is by specifying filters on the input jars. There
|
||
|
|
is no option to switch off these warnings.</dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
<p>
|
||
|
|
|
||
|
|
ProGuard may terminate when it encounters parsing errors or I/O errors, or
|
||
|
|
some more serious warnings:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="unresolvedclass"><b>Warning: can't find superclass or interface</b><br/><b>Warning: can't find referenced class</b></a></dt>
|
||
|
|
|
||
|
|
<dd>If there are unresolved references to classes or interfaces, you most
|
||
|
|
likely forgot to specify an essential library. For proper processing, all
|
||
|
|
libraries that are referenced by your code must be specified, including
|
||
|
|
the Java run-time library. For specifying libraries, use
|
||
|
|
the <a href="usage.html#libraryjars"><code>-libraryjars</code></a> option.
|
||
|
|
<p>
|
||
|
|
For example, if ProGuard complains that it can't find a
|
||
|
|
<code>javax.crypto</code> class, you probably still have to specify
|
||
|
|
<code>jce.jar</code>, next to the more common <code>rt.jar</code>.
|
||
|
|
<p>
|
||
|
|
If you're missing a library and you're absolutely sure it isn't used
|
||
|
|
anyway, you can try your luck with the <a
|
||
|
|
href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
|
||
|
|
or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
|
||
|
|
option. Only use these options if you really know what you're doing
|
||
|
|
though.
|
||
|
|
<p>
|
||
|
|
For example, if you're developing for Android, and ProGuard complains that
|
||
|
|
it can't find a <code>java.awt</code> class, then some library that you
|
||
|
|
are using is referring to <code>java.awt</code>. 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 "<code>-dontwarn
|
||
|
|
java.awt.**</code>".</dd>
|
||
|
|
|
||
|
|
<dt><a name="superclass"><b>Error: Can't find any super classes of ... (not even immediate super class ...)</b><br/><b>Error: Can't find common super class of ... and ...</b></a></dt>
|
||
|
|
|
||
|
|
<dd>It seems like you tried to avoid the warnings from the previous paragraph
|
||
|
|
by specifying
|
||
|
|
<a href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a>
|
||
|
|
or <a href="usage.html#dontwarn"><code>-dontwarn</code></a>, 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 <a href="usage.html#injars"><code>-injars</code></a> option:
|
||
|
|
"<code>-injars
|
||
|
|
myapplication.jar(!somepackage/SomeUnusedClass.class)</code>". Hopefully,
|
||
|
|
you can access the configuration of your build process for such a
|
||
|
|
modification. As a final solution, you could switch off optimization
|
||
|
|
(<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>) and
|
||
|
|
preverification
|
||
|
|
(<a href="usage.html#dontpreverify"><code>-dontpreverify</code></a>).</dd>
|
||
|
|
|
||
|
|
<dt><a name="unresolvedclassmember"><b>Warning: can't find referenced field/method</b></a></dt>
|
||
|
|
|
||
|
|
<dd>If there are unresolved references to class members in input classes, your
|
||
|
|
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 class files, recompiling them,
|
||
|
|
zipping them up, and running ProGuard again.
|
||
|
|
<p>
|
||
|
|
If your program classes reside in the same packages as library classes,
|
||
|
|
and refer to their package visible class members, then you should also
|
||
|
|
specify the
|
||
|
|
<a href="usage.html#dontskipnonpubliclibraryclassmembers"><code>-dontskipnonpubliclibraryclassmembers</code></a>
|
||
|
|
option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="unresolvedenclosingmethod"><b>Warning: can't find enclosing class/method</b></a></dt>
|
||
|
|
|
||
|
|
<dd>If there are unresolved references to classes that are defined inside
|
||
|
|
methods in your input, once more, your 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 class files, recompiling them, zipping them up, and running
|
||
|
|
ProGuard again.</dd>
|
||
|
|
|
||
|
|
<dt><a name="dependency"><b>Warning: library class ... depends on program class ...</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="usage.html#injars"><code>-injars</code></a>) and library code
|
||
|
|
(specified with <a
|
||
|
|
href="usage.html#libraryjars"><code>-libraryjars</code></a>), and try
|
||
|
|
again.</dd>
|
||
|
|
|
||
|
|
<dt><a name="unexpectedclass"><b>Warning: class file ... unexpectedly contains class ...</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <code>WEB-INF/classes</code> directory in a war should be packaged
|
||
|
|
in a jar and put in the <code>WEB-INF/lib</code> directory. If you don't
|
||
|
|
mind these classes not being written to the output, you can specify the <a
|
||
|
|
href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
|
||
|
|
or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
|
||
|
|
option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="mappingconflict1"><b>Warning: ... is not being kept as ..., but remapped to ...</b></a></dt>
|
||
|
|
|
||
|
|
<dd>There is a conflict between a <code>-keep</code> 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 <a
|
||
|
|
href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
|
||
|
|
or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
|
||
|
|
option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="mappingconflict2"><b>Warning: field/method ... can't be mapped to ...</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
|
||
|
|
or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
|
||
|
|
option. Note that you should always use the <a
|
||
|
|
href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>
|
||
|
|
option in the initial obfuscation step, in order to reduce the risk of
|
||
|
|
conflicts.</dd>
|
||
|
|
|
||
|
|
<dt><a name="unsupportedclassversion"><b>Error: Unsupported class version number</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 if
|
||
|
|
there is a more recent release
|
||
|
|
<a href="http://proguard.sourceforge.net/downloads.html">on-line</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a name="keep"><b>Error: You have to specify '-keep' options</b></a></dt>
|
||
|
|
|
||
|
|
<dd>You either forgot to specify <a
|
||
|
|
href="usage.html#keep"><code>-keep</code></a> 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.</dd>
|
||
|
|
|
||
|
|
<dt><a name="filename"><b>Error: Expecting class path separator ';' before 'Files\Java\</b>...<b>'</b> (in Windows)</a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a href="usage.html#filename">file names</a>. This is actually
|
||
|
|
true for all file names containing special characters, on all
|
||
|
|
platforms.</dd>
|
||
|
|
|
||
|
|
<dt><a name="macosx"><b>Error: Can't read [</b>...<b>/lib/rt.jar] (No such file or directory)</b> (in MacOS X)</a></dt>
|
||
|
|
|
||
|
|
<dd>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 <code><java.home>/lib/rt.jar</code> by
|
||
|
|
<code><java.home>/../Classes/classes.jar</code>.</dd>
|
||
|
|
|
||
|
|
<dt><a name="startinggui"><b>Internal problem starting the ProGuard GUI (Cannot write XdndAware property)</b> (in Linux)</a></dt>
|
||
|
|
|
||
|
|
<dd>In Linux, at least with Java 6, the GUI may not start properly, due to
|
||
|
|
<a href="http://bugs.sun.com/view_bug.do?bug_id=7027598">Sun
|
||
|
|
Bug #7027598</a>. The work-around at this time is to specify the JVM
|
||
|
|
option <code>-DsuppressSwingDropSupport=true</code> when running the
|
||
|
|
GUI.</dd>
|
||
|
|
|
||
|
|
<dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
<p>
|
||
|
|
|
||
|
|
Should ProGuard crash while processing your application:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="outofmemoryerror"><b>OutOfMemoryError</b></a></dt>
|
||
|
|
|
||
|
|
<dd>You can try increasing the heap size of the Java virtual machine (with the
|
||
|
|
usual <code>-Xms</code> and <code>-Xmx</code> options). 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. Remember that only classes or interfaces that are
|
||
|
|
extended or implemented by classes in your input jars are required.</dd>
|
||
|
|
|
||
|
|
<dt><a name="stackoverflowerror"><b>StackOverflowError</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <code>-Xss</code> option)
|
||
|
|
should help too. In practice however, the <code>-Xss</code> setting
|
||
|
|
doesn't have any effect on the main thread, due to <a
|
||
|
|
href="http://bugs.sun.com/view_bug.do?bug_id=4362291">Sun Bug
|
||
|
|
#4362291</a>. As a result, this solution will only work when running
|
||
|
|
ProGuard in a different thread, e.g. from its GUI.</dd>
|
||
|
|
|
||
|
|
<dt><a name="unexpectederror"><b>Unexpected error</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. In
|
||
|
|
any case, please report the problem, preferably with the simplest example
|
||
|
|
that causes ProGuard to crash.</dd>
|
||
|
|
|
||
|
|
<dt><a name="otherwise"><b>Otherwise...</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<h2><a name="afterprocessing">Unexpected observations after processing</a></h2>
|
||
|
|
|
||
|
|
If ProGuard seems to run fine, but your processed code doesn't look right,
|
||
|
|
there might be a couple of reasons:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="disappearingclasses"><b>Disappearing classes</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
|
||
|
|
option.
|
||
|
|
<p>
|
||
|
|
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 <code>WEB-INF/classes</code> directory in a
|
||
|
|
war should be packaged in a jar and put in the <code>WEB-INF/lib</code>
|
||
|
|
directory.</dd>
|
||
|
|
|
||
|
|
<dt><a name="notkept"><b>Classes or class members not being kept</b></a></dt>
|
||
|
|
|
||
|
|
<dd>If ProGuard is not keeping the right classes or class members, make sure
|
||
|
|
you are using fully qualified class names. If the package name of some
|
||
|
|
class is missing, ProGuard won't match the elements that you might be
|
||
|
|
expecting. It may help to double-check for typos too. You can use the <a
|
||
|
|
href="usage.html#printseeds"><code>-printseeds</code></a> option to see
|
||
|
|
which elements are being kept exactly.
|
||
|
|
<p>
|
||
|
|
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 "<code>-keep interface MyMarkerInterface</code>".
|
||
|
|
<p>
|
||
|
|
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 can explicitly keep all annotation classes in your program code
|
||
|
|
with an option like "<code>-keep @interface *</code>".<dd>
|
||
|
|
|
||
|
|
<dt><a name="notobfuscated"><b>Variable names not being obfuscated</b></a></dt>
|
||
|
|
|
||
|
|
<dd>If the names of the local variables and parameters in your obfuscated code
|
||
|
|
don't look obfuscated, because they suspiciously resemble the names of
|
||
|
|
their types, it's probably because the decompiler that you are using is
|
||
|
|
coming up with those names. ProGuard's obfuscation step does remove the
|
||
|
|
original names entirely, unless you explicitly keep the
|
||
|
|
<code>LocalVariableTable</code> or <code>LocalVariableTypeTable</code>
|
||
|
|
attributes.</dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<h2><a name="dalvik">Problems while converting to Android Dalvik bytecode</a></h2>
|
||
|
|
|
||
|
|
If ProGuard seems to run fine, but the dx tool in the Android SDK subsequently
|
||
|
|
fails with an error:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="simexception"><b>SimException: local variable type mismatch</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 (<code>-g:none</code>), or let
|
||
|
|
ProGuard's obfuscation step remove the debug information again
|
||
|
|
(by <i>not</i> keeping the attributes <code>LocalVariableTable</code>
|
||
|
|
and <code>LocalVariableTypeTable</code>
|
||
|
|
with <a href="usage.html#keepattributes"><code>-keepattributes</code></a>),
|
||
|
|
or otherwise just disable optimization
|
||
|
|
(<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>).</dd>
|
||
|
|
|
||
|
|
<dt><a name="conversionerror"><b>Conversion to Dalvik format failed with error 1</b></a></dt>
|
||
|
|
|
||
|
|
<dd>This error may have various causes, but if dx is tripping over some code
|
||
|
|
processed by ProGuard, you should make sure that you are using the latest
|
||
|
|
version of ProGuard. You can just copy the ProGuard jars
|
||
|
|
to <code>android-sdk/tools/proguard/lib</code>. If that doesn't help,
|
||
|
|
please report the problem, preferably with the simplest example that still
|
||
|
|
brings out the error.</dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<h2><a name="preverifying">Problems while preverifying for Java Micro Edition</a></h2>
|
||
|
|
|
||
|
|
If ProGuard seems to run fine, but the external preverifier subsequently
|
||
|
|
produces errors, it's usually for a single reason:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="invalidclassexception1"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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
|
||
|
|
<code>preverify</code> tool always unpacks the jars, so class files with
|
||
|
|
similar lower-case and upper-case names overwrite each other. You can use
|
||
|
|
ProGuard's <a
|
||
|
|
href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
|
||
|
|
option to work around this problem.
|
||
|
|
<p>
|
||
|
|
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 <a
|
||
|
|
href="usage.html#dontoptimize"><code>-dontoptimize</code></a> 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 you can find ProGuard to fail.</dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
Note that it is no longer necessary to use an external preverifier. With the
|
||
|
|
<a href="usage.html#microedition"><code>-microedition</code></a> option,
|
||
|
|
ProGuard will preverify the class files for Java Micro Edition.
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<h2><a name="runtime">Problems at run-time</a></h2>
|
||
|
|
|
||
|
|
If ProGuard runs fine, but your processed application doesn't work, there
|
||
|
|
might be several reasons:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="stacktraces"><b>Stack traces without class names or line numbers</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
|
||
|
|
<dt><a name="noclassdeffounderror"><b>NoClassDefFoundError</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your class path is probably incorrect. It should at least contain all
|
||
|
|
library jars and, of course, your processed program jar.</dd>
|
||
|
|
|
||
|
|
<dt><a name="classnotfoundexception"><b>ClassNotFoundException</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your code is probably calling <code>Class.forName</code>, trying to create
|
||
|
|
the missing class dynamically. ProGuard can only detect constant name
|
||
|
|
arguments, like <code>Class.forName("mypackage.MyClass")</code>. For
|
||
|
|
variable name arguments like <code>Class.forName(someClass)</code>, you
|
||
|
|
have to keep all possible classes using the appropriate <a
|
||
|
|
href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep
|
||
|
|
class mypackage.MyClass</code>" or "<code>-keep class * implements
|
||
|
|
mypackage.MyInterface</code>".</dd>
|
||
|
|
|
||
|
|
<dt><a name="nosuchmethodexception"><b>NoSuchMethodException</b></a></dt>
|
||
|
|
|
||
|
|
<dd>Your code is probably calling something like
|
||
|
|
<code>myClass.getMethod</code>, 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 <a
|
||
|
|
href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep
|
||
|
|
class mypackage.MyClass { void myMethod(); }</code>".
|
||
|
|
<p>
|
||
|
|
More specifically, if the method reported as missing is
|
||
|
|
<code>values</code> or <code>valueOf</code>, you probably have to keep
|
||
|
|
some methods related to <a
|
||
|
|
href="examples.html#enumerations">enumerations</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a name="missingresourceexception"><b>MissingResourceException</b> or <b>NullPointerException</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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
|
||
|
|
<a
|
||
|
|
href="usage.html#adaptresourcefilenames"><code>-adaptresourcefilenames</code></a>
|
||
|
|
and/or <a
|
||
|
|
href="usage.html#adaptresourcefilecontents"><code>-adaptresourcefilecontents</code></a>.
|
||
|
|
<p>
|
||
|
|
Furthermore, directory entries in jar files aren't copied, unless you
|
||
|
|
specify the option <a
|
||
|
|
href="usage.html#keepdirectories"><code>-keepdirectories</code></a>.
|
||
|
|
Note that Sun advises against calling <code>Class.getResource()</code> for
|
||
|
|
directories (<a href="http://bugs.sun.com/view_bug.do?bug_id=4761949">Sun
|
||
|
|
Bug #4761949</a>).</dd>
|
||
|
|
|
||
|
|
<dt><a name="disappearingannotations"><b>Disappearing annotations</b></a></dt>
|
||
|
|
|
||
|
|
<dd>By default, the obfuscation step removes all annotations. If your
|
||
|
|
application relies on annotations to function properly, you should
|
||
|
|
explicitly keep them with
|
||
|
|
<code><a href="usage.html#keepattributes">-keepattributes</a>
|
||
|
|
*Annotation*</code>.</dd>
|
||
|
|
|
||
|
|
<dt><a name="invalidjarfile"><b>Invalid or corrupt jarfile</b></a></dt>
|
||
|
|
|
||
|
|
<dd>You are probably starting your application with the java option
|
||
|
|
<code>-jar</code> instead of the option <code>-classpath</code>. The java
|
||
|
|
virtual machine returns with this error message if your jar doesn't
|
||
|
|
contain a manifest file (<code>META-INF/MANIFEST.MF</code>), if the
|
||
|
|
manifest file doesn't specify a main class (<code>Main-Class:</code> ...),
|
||
|
|
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,</dd>
|
||
|
|
|
||
|
|
<dt><a name="invalidjarindexexception"><b>InvalidJarIndexException: Invalid index</b></a></dt>
|
||
|
|
|
||
|
|
<dd>At least one of your processed jar files contains an index file
|
||
|
|
<code>META-INF/INDEX.LIST</code>, 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
|
||
|
|
(<code>-injars in.jar(!META-INF/INDEX.LIST)</code>) or update the file
|
||
|
|
after having applied ProGuard (<code>jar -i out.jar</code>).
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a name="invalidclassexception2"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b> (in Java Micro Edition)</a></dt>
|
||
|
|
|
||
|
|
<dd>If you get such an error in Java Micro Edition, you may have forgotten to
|
||
|
|
specify the <a
|
||
|
|
href="usage.html#microedition"><code>-microedition</code></a> option, so
|
||
|
|
the processed class files are preverified properly.</dd>
|
||
|
|
|
||
|
|
<dt><a name="nosuchfieldormethod"><b>Error: No Such Field or Method</b>, <b>Error verifying method</b> (in a Java Micro Edition emulator)</a></dt>
|
||
|
|
|
||
|
|
<dd>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 <code><a href="usage.html#repackageclasses">-repackageclasses</a>
|
||
|
|
''</code> and <a
|
||
|
|
href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>.
|
||
|
|
If you're using the JME WTK plugin, you can adapt the configuration
|
||
|
|
<code>proguard/wtk/default.pro</code> that's inside the
|
||
|
|
<code>proguard.jar</code>.</dd>
|
||
|
|
|
||
|
|
<dt><a name="failingmidlets"><b>Failing midlets</b> (on a Java Micro Edition device)</a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>
|
||
|
|
option. It avoids overloading class member names, which triggers a bug in
|
||
|
|
their java virtual machine.
|
||
|
|
<p>
|
||
|
|
You might also try using the <a
|
||
|
|
href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
|
||
|
|
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.</dd>
|
||
|
|
|
||
|
|
<dt><a name="disappearingloops"><b>Disappearing loops</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <code>volatile</code>. If this is not
|
||
|
|
possible for some reason, you'll have to switch off optimization using the
|
||
|
|
<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>
|
||
|
|
option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="securityexception"><b>SecurityException: SHA1 digest error</b></a></dt>
|
||
|
|
|
||
|
|
<dd>You may have forgotten to sign your program jar <i>after</i> having
|
||
|
|
processed it with ProGuard.</dd>
|
||
|
|
|
||
|
|
<dt><a name="classcastexception"><b>ClassCastException: class not an enum</b>, or <br /><b>IllegalArgumentException: class not an enum type</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="examples.html#enumerations">examples</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a name="arraystoreexception"><b>ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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.</dd>
|
||
|
|
|
||
|
|
<dt><a name="compilererror"><b>CompilerError: duplicate addition</b></a></dt>
|
||
|
|
|
||
|
|
<dd>You are probably compiling or running some code that has been obfuscated
|
||
|
|
with the <a
|
||
|
|
href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>
|
||
|
|
option. This option triggers a bug in
|
||
|
|
<code>sun.tools.java.MethodSet.add</code> in Sun's JDK 1.2.2, which is
|
||
|
|
used for (dynamic) compilation. You should then avoid this option.</dd>
|
||
|
|
|
||
|
|
<dt><a name="classformaterror1"><b>ClassFormatError: repetitive field name/signature</b></a></dt>
|
||
|
|
|
||
|
|
<dd>You are probably processing some code that has been obfuscated before with
|
||
|
|
the <a
|
||
|
|
href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>
|
||
|
|
option. You should then use the same option again in the second processing
|
||
|
|
round.</dd>
|
||
|
|
|
||
|
|
<dt><a name="classformaterror2"><b>ClassFormatError: Invalid index in LocalVariableTable in class file</b></a></dt>
|
||
|
|
|
||
|
|
<dd>If you are keeping the <code>LocalVariableTable</code> or
|
||
|
|
<code>LocalVariableTypeTable</code> 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.</dd>
|
||
|
|
|
||
|
|
<dt><a name="nosuchmethoderror"><b>NoSuchMethodError</b> or <b>AbstractMethodError</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a
|
||
|
|
href="#disappearingclasses">disappearing classes</a> for details.
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
<p>
|
||
|
|
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.</dd>
|
||
|
|
|
||
|
|
<dt><a name="verifyerror"><b>VerifyError</b></a></dt>
|
||
|
|
|
||
|
|
<dd>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 <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>
|
||
|
|
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.</dd>
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<hr />
|
||
|
|
<noscript><div><a target="_top" href="../index.html" class="button">Show menu</a></div></noscript>
|
||
|
|
<address>
|
||
|
|
Copyright © 2002-2011
|
||
|
|
<a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>.
|
||
|
|
</address>
|
||
|
|
</body>
|
||
|
|
</html>
|