1 <!doctype html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 2 <html> 3 <head> 4 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> 5 <meta http-equiv="content-style-type" content="text/css"> 6 <link rel="stylesheet" type="text/css" href="style.css"> 7 <title>ProGuard Troubleshooting</title> 8 <script type="text/javascript" language="JavaScript"> 9 <!-- 10 if (window.self==window.top) 11 window.top.location.replace("../index.html#"+window.location.pathname+window.location.hash); 12 else { 13 var hash="#"+window.location.pathname.replace(window.top.location.pathname.replace("index.html", ""), ""); 14 if (window.top.location.hash!=hash) 15 window.top.location.hash=hash; 16 } 17 //--> 18 </script> 19 </head> 20 <body> 21 22 <h2>Troubleshooting</h2> 23 24 While preparing a configuration for processing your code, you may bump into a 25 few problems. The following sections discuss some common issues and solutions: 26 27 <h3><a href="#processing">Problems while processing</a></h3> 28 <ul> 29 <li><a href="#dynamicalclass">Note: can't find dynamically referenced class ...</a></li> 30 <li><a href="#dynamicalclasscast">Note: ... calls '(...)Class.forName(variable).newInstance()'</a></li> 31 <li><a href="#dynamicalclassmember">Note: ... accesses a field/method '...' dynamically</a></li> 32 <li><a href="#unknownclass">Note: the configuration refers to the unknown class '...'</a></li> 33 <li><a href="#descriptorclass">Note: the configuration keeps the entry point '...', but not the descriptor class '...'</a></li> 34 <li><a href="#classmembers">Note: the configuration doesn't specify which class members to keep for class '...'</a></li> 35 <li><a href="#duplicateclass">Note: duplicate definition of program/library class</a></li> 36 <li><a href="#duplicatezipentry">Warning: can't write resource ... Duplicate zip entry</a></li> 37 <li><a href="#unresolvedclass">Warning: can't find superclass or interface</a></li> 38 <li><a href="#unresolvedclass">Warning: can't find referenced class</a></li> 39 <li><a href="#superclass">Error: Can't find any super classes of ... (not even immediate super class ...)</a></li> 40 <li><a href="#superclass">Error: Can't find common super class of ... and ...</a></li> 41 <li><a href="#unresolvedprogramclassmember">Warning: can't find referenced field/method '...' in program class ...</a></li> 42 <li><a href="#unresolvedlibraryclassmember">Warning: can't find referenced field/method '...' in library class ...</a></li> 43 <li><a href="#unresolvedenclosingmethod">Warning: can't find enclosing class/method</a></li> 44 <li><a href="#dependency">Warning: library class ... depends on program class ...</a></li> 45 <li><a href="#unexpectedclass">Warning: class file ... unexpectedly contains class ...</a></li> 46 <li><a href="#mappingconflict1">Warning: ... is not being kept as ..., but remapped to ...</a></li> 47 <li><a href="#mappingconflict2">Warning: field/method ... can't be mapped to ...</a></li> 48 <li><a href="#unsupportedclassversion">Error: Unsupported class version number</a></li> 49 <li><a href="#keep">Error: You have to specify '-keep' options</a></li> 50 <li><a href="#filename">Error: Expecting class path separator ';' before 'Files\Java\...' (in Windows)</a></li> 51 <li><a href="#macosx">Error: Can't read [.../lib/rt.jar] (No such file or directory) (in MacOS X)</a></li> 52 <li><a href="#cantread">Error: Can't read ...</a></li> 53 <li><a href="#cantwrite">Error: Can't write ...</a></li> 54 <li><a href="#startinggui">Internal problem starting the ProGuard GUI (Cannot write XdndAware property) (in Linux)</a></li> 55 <li><a href="#outofmemoryerror">OutOfMemoryError</a></li> 56 <li><a href="#stackoverflowerror">StackOverflowError</a></li> 57 <li><a href="#unexpectederror">Unexpected error</a></li> 58 <li><a href="#otherwise">Otherwise...</a></li> 59 </ul> 60 61 <h3><a href="#afterprocessing">Unexpected observations after processing</a></h3> 62 <ul> 63 <li><a href="#disappearingclasses">Disappearing classes</a></li> 64 <li><a href="#notkept">Classes or class members not being kept</a></li> 65 <li><a href="#notobfuscated">Variable names not being obfuscated</a></li> 66 </ul> 67 68 <h3><a href="#dalvik">Problems while converting to Android Dalvik bytecode</a></h3> 69 70 <ul> 71 <li><a href="#simexception">SimException: local variable type mismatch</a></li> 72 <li><a href="#conversionerror">Conversion to Dalvik format failed with error 1</a></li> 73 </ul> 74 75 <h3><a href="#preverifying">Problems while preverifying for Java Micro Edition</a></h3> 76 77 <ul> 78 <li><a href="#invalidclassexception1">InvalidClassException, class loading error, or verification error</a></li> 79 </ul> 80 81 <h3><a href="#runtime">Problems at run-time</a></h3> 82 <ul> 83 <li><a href="#stacktraces">Stack traces without class names or line numbers</a></li> 84 <li><a href="#noclassdeffounderror">NoClassDefFoundError</a></li> 85 <li><a href="#classnotfoundexception">ClassNotFoundException</a></li> 86 <li><a href="#nosuchfieldexception">NoSuchFieldException</a></li> 87 <li><a href="#nosuchmethodexception">NoSuchMethodException</a></li> 88 <li><a href="#missingresourceexception">MissingResourceException or NullPointerException</a></li> 89 <li><a href="#disappearingannotations">Disappearing annotations</a></li> 90 <li><a href="#invalidjarfile">Invalid or corrupt jarfile</a></li> 91 <li><a href="#invalidjarindexexception">InvalidJarIndexException: Invalid index</a></li> 92 <li><a href="#invalidclassexception2">InvalidClassException, class loading error, or verification error (in Java Micro Edition)</a></li> 93 <li><a href="#nosuchfieldormethod">Error: No Such Field or Method, Error verifying method (in a Java Micro Edition emulator)</a></li> 94 <li><a href="#failingmidlets">Failing midlets (on a Java Micro Edition device)</a></li> 95 <li><a href="#disappearingloops">Disappearing loops</a></li> 96 <li><a href="#securityexception">SecurityException: SHA1 digest error</a></li> 97 <li><a href="#classcastexception">ClassCastException: class not an enum</a></li><li><a href="#classcastexception">IllegalArgumentException: class not an enum type</a></li> 98 <li><a href="#arraystoreexception">ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</a></li> 99 <li><a href="#compilererror">CompilerError: duplicate addition</a></li> 100 <li><a href="#classformaterror1">ClassFormatError: repetitive field name/signature</a></li> 101 <li><a href="#classformaterror2">ClassFormatError: Invalid index in LocalVariableTable in class file</a></li> 102 <li><a href="#nosuchmethoderror">NoSuchMethodError or AbstractMethodError</a></li> 103 <li><a href="#verifyerror">VerifyError</a></li> 104 </ul> 105 106 107 <h2><a name="processing">Problems while processing</a></h2> 108 109 ProGuard may print out some notes and non-fatal warnings: 110 111 <dl> 112 <dt><a name="dynamicalclass"><b>Note: can't find dynamically referenced class ...</b></a></dt> 113 114 <dd>ProGuard can't find a class or interface that your code is accessing by 115 means of introspection. You should consider adding the jar that contains 116 this class.</dd> 117 118 <dt><a name="dynamicalclasscast"><b>Note: ... calls '(...)Class.forName(variable).newInstance()'</b></a></dt> 119 120 <dd>ProGuard lists all class casts of dynamically created class instances, 121 like "<code>(MyClass)Class.forName(variable).newInstance()</code>". 122 Depending on your application, you may need to keep the mentioned classes 123 with an option like "<code>-keep class MyClass</code>", or their 124 implementations with an option like "<code>-keep class * implements 125 MyClass</code>". You can switch off these notes by specifying the 126 <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 127 128 <dt><a name="dynamicalclassmember"><b>Note: ... accesses a field/method '...' dynamically</b></a></dt> 129 130 <dd>ProGuard lists a number of constructs like 131 "<code>.getField("myField")</code>". Depending on your application, you 132 may need to figure out where the mentioned class members are defined and 133 keep them with an option like "<code>-keep class MyClass { MyFieldType 134 myField; }</code>". Otherwise, ProGuard might remove or obfuscate the 135 class members, since it can't know which ones they are exactly. It does 136 list possible candidates, for your information. You can switch off these 137 notes by specifying the <a 138 href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 139 140 <dt><a name="unknownclass"><b>Note: the configuration refers to the unknown class '...'</b></a></dt> 141 142 <dd>Your configuration refers to the name of a class that is not present in 143 the program jars or library jars. You should check whether the name is 144 correct. Notably, you should make sure that you always specify 145 fully-qualified names, not forgetting the package names.</dd> 146 147 <dt><a name="descriptorclass"><b>Note: the configuration keeps the entry point '...', but not the descriptor class '...'</b></a></dt> 148 149 <dd>Your configuration contains a <code>-keep</code> option to preserve the 150 given method (or field), but no <code>-keep</code> option for the given 151 class that is an argument type or return type in the method's descriptor. 152 You may then want to keep the class too. Otherwise, ProGuard will 153 obfuscate its name, thus changing the method's signature. The method might 154 then become unfindable as an entry point, e.g. if it is part of a public 155 API. You can switch off these notes by specifying the <a 156 href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 157 158 <dt><a name="classmembers"><b>Note: the configuration doesn't specify which class members to keep for class '...'</b></a></dt> 159 160 <dd>Your configuration contains 161 a <a href="usage.html#keepclassmembers"><code>-keepclassmembers</code></a>/<a href="usage.html#keepclasseswithmembers">-keepclasseswithmembers</code></a> 162 option to preserve fields or methods in the given class, but it doesn't 163 specify which fields or methods. This way, the option simply won't have 164 any effect. You probably want to specify one or more fields or methods, as 165 usual between curly braces. You can specify all fields or methods with a 166 wildcard "<code>*;</code>". You should also consider if you just need the 167 more common <a href="usage.html#keep"><code>-keep</code></a> option, which 168 preserves all specified classes <i>and</i> class members. 169 The <a href="usage.html#keepoverview">overview of all <code>keep</code> 170 options</a> can help. You can switch off these notes by specifying 171 the <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd> 172 173 <dt><a name="duplicateclass"><b>Note: duplicate definition of program/library class</b></a></dt> 174 175 <dd>Your program jars or library jars contain multiple definitions of the 176 listed classes. ProGuard continues processing as usual, only considering 177 the first definitions. The warning may be an indication of some problem 178 though, so it's advisable to remove the duplicates. A convenient way to do 179 so is by specifying filters on the input jars or library jars. You can 180 switch off these notes by specifying the <a 181 href="usage.html#dontnote"><code>-dontnote</code></a> option. 182 <p> 183 <img class="float" src="android_small.png" width="32" height="32" 184 alt="android" /> The standard Android build process automatically 185 specifies the input jars for you. There may not be an easy way to filter 186 them to remove these notes. You could remove the duplicate classes 187 manually from your libraries. You should never explicitly specify the 188 input jars yourself (with <code>-injars</code> or 189 <code>-libraryjars</code>), since you'll then get duplicate definitions. 190 You should also not add libraries to your application that are already 191 part of the Android run-time (notably <code>org.w3c.dom</code>, 192 <code>org.xml.sax</code>, <code>org.xmlpull.v1</code>, 193 <code>org.apache.commons.logging.Log</code>, <code>org.apache.http</code>, 194 and <code>org.json</code>). They are possibly inconsistent, and the 195 run-time libraries would get precedence anyway.</dd> 196 197 <dt><a name="duplicatezipentry"><b>Warning: can't write resource ... Duplicate zip entry</b></a></dt> 198 199 <dd>Your input jars contain multiple resource files with the same name. 200 ProGuard continues copying the resource files as usual, skipping any files 201 with previously used names. Once more, the warning may be an indication of 202 some problem though, so it's advisable to remove the duplicates. A 203 convenient way to do so is by specifying filters on the input jars. There 204 is no option to switch off these warnings. 205 <p> 206 <img class="float" src="android_small.png" width="32" height="32" 207 alt="android" /> The standard Android build process automatically 208 specifies the input jars for you. There may not be an easy way to filter 209 them to remove these warnings. You could remove the duplicate resource files 210 manually from the input and the libraries.</dd> 211 212 </dl> 213 <p> 214 215 ProGuard may terminate when it encounters parsing errors or I/O errors, or 216 some more serious warnings: 217 218 <dl> 219 <dt><a name="unresolvedclass"><b>Warning: can't find superclass or interface</b><br/><b>Warning: can't find referenced class</b></a></dt> 220 221 <dd>A class in one of your program jars or library jars is referring to a 222 class or interface that is missing from the input. The warning lists both 223 the referencing class(es) and the missing referenced class(es). There can 224 be a few reasons, with their own solutions: 225 <p> 226 <ol> 227 <li>If the missing class is referenced from your own code, you may have 228 forgotten to specify an essential library. Just like when compiling 229 all code from scratch, you must specify all libraries that the code is 230 referencing, directly or indirectly. If the library should be 231 processed and included in the output, you should specify it with 232 <a href="usage.html#injars"><code>-injars</code></a>, otherwise you 233 should specify it with 234 <a href="usage.html#libraryjars"><code>-libraryjars</code></a>. 235 <p> 236 For example, if ProGuard complains that it can't find a 237 <code>java.lang</code> class, you have to make sure that you are 238 specifying the run-time library of your platform. For JSE, these are 239 typically packaged in <code>lib/rt.jar</code> (<code>vm.jar</code> for 240 IBM's JVM, and <code>classes.jar</code> in MacOS X). Other platforms 241 like JME and Android have their own run-time libraries. 242 The <a href="examples.html">examples section</a> provides more details 243 for the various platforms. 244 <p> 245 If ProGuard still complains that it can't find a 246 <code>javax.crypto</code> class, you probably still have to specify 247 <code>jce.jar</code>, next to the more common <code>rt.jar</code>.</li> 248 <li>If the missing class is referenced from a pre-compiled third-party 249 library, and your original code runs fine without it, then the missing 250 dependency doesn't seem to hurt. The cleanest solution is to 251 <a href="usage.html#filters">filter out</a> the <i>referencing</i> 252 class or classes from the input, with a filter like "<code>-libraryjars 253 mylibrary.jar(!somepackage/SomeUnusedReferencingClass.class)</code>". 254 ProGuard will then skip this class entirely in the input, and it will 255 not bump into the problem of its missing reference. However, you may 256 then have to filter out other classes that are in turn referencing the 257 removed class. In practice, this works best if you can filter out 258 entire unused packages at once, with a wildcard filter like 259 "<code>-libraryjars 260 mylibrary.jar(!someunusedpackage/**)</code>".<p></li> 261 <li>If you don't feel like filtering out the problematic classes, you can 262 try your luck with the <a 263 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> 264 option, or even 265 the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> option. 266 Only use these options if you really know what you're doing though.</li> 267 </ol> 268 <p> 269 <img class="float" src="android_small.png" width="32" height="32" 270 alt="android" /> The standard Android build process automatically 271 specifies the input jars for you. Unfortunately, many pre-compiled 272 third-party libraries refer to other libraries that are not actually used 273 and therefore not present. This works fine in debug builds, but in release 274 builds, ProGuard expects all libraries, so it can perform a proper static 275 analysis. For example, if ProGuard complains that it can't find 276 a <code>java.awt</code> class, then some library that you are using is 277 referring to <code>java.awt</code>. This is a bit shady, since Android 278 doesn't have this package at all, but if your application works anyway, 279 you can let ProGuard accept it with "<code>-dontwarn java.awt.**</code>", 280 for instance.</dd> 281 282 <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> 283 284 <dd>It seems like you tried to avoid the warnings from the previous paragraph 285 by specifying 286 <a href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> 287 or <a href="usage.html#dontwarn"><code>-dontwarn</code></a>, but it didn't 288 work out. ProGuard's optimization step and preverification step really 289 need the missing classes to make sense of the code. Preferably, you would 290 solve the problem by adding the missing library, as discussed. If you're 291 sure the class that references the missing class isn't used either, you 292 could also try filtering it out from the input, by adding a filter to the 293 corresponding <a href="usage.html#injars"><code>-injars</code></a> option: 294 "<code>-injars 295 myapplication.jar(!somepackage/SomeUnusedClass.class)</code>". As a final 296 solution, you could switch off optimization 297 (<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>) and 298 preverification 299 (<a href="usage.html#dontpreverify"><code>-dontpreverify</code></a>).</dd> 300 301 <dt><a name="unresolvedprogramclassmember"><b>Warning: can't find referenced field/method '...' in program class ...</b></a></dt> 302 303 <dd>A program class is referring to a field or a method that is missing from 304 another program class. The warning lists both the referencing class and 305 the missing referenced class member. Your compiled class files are most 306 likely inconsistent. Possibly, some class file didn't get recompiled 307 properly, or some class file was left behind after its source file was 308 removed. Try removing all compiled class files and rebuilding your 309 project.</dd> 310 311 <dt><a name="unresolvedlibraryclassmember"><b>Warning: can't find referenced field/method '...' in library class ...</b></a></dt> 312 313 <dd>A program class is referring to a field or a method that is missing from a 314 library class. The warning lists both the referencing class and the 315 missing referenced class member. Your compiled class files are 316 inconsistent with the libraries. You may need to recompile the class 317 files, or otherwise upgrade the libraries to consistent versions. 318 <p> 319 <img class="float" src="android_small.png" width="32" height="32" 320 alt="android" /> If you're developing for Android and ProGuard complains 321 that it can't find a method that is only available in a recent version of 322 the Android run-time, you should change the build target in your 323 <code>project.properties</code> file or <code>build.gradle</code> file to 324 that recent version. You can still specify a different 325 <code>minSdkVersion</code> and a different <code>targetSdkVersion</code> 326 in your <code>AndroidManifest.xml</code> file. 327 <p> 328 Alternatively, you may get away with ignoring the inconsistency with the 329 options 330 <a href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> or 331 even 332 <a href="usage.html#dontwarn"><code>-dontwarn</code></a>. For instance, you 333 can specify "<code>-dontwarn mypackage.MyInconsistentClass</code>". 334 <p> 335 Finally, should your program classes reside in the same packages as 336 library classes and should they refer to their package visible class 337 members, then you should also specify the 338 <a href="usage.html#dontskipnonpubliclibraryclassmembers"><code>-dontskipnonpubliclibraryclassmembers</code></a> 339 option.</dd> 340 341 <dt><a name="unresolvedenclosingmethod"><b>Warning: can't find enclosing class/method</b></a></dt> 342 343 <dd>If there are unresolved references to classes that are defined inside 344 methods in your input, once more, your compiled class files are most likely 345 inconsistent. Possibly, some class file didn't get recompiled properly, or 346 some class file was left behind after its source file was removed. Try 347 removing all compiled class files and rebuilding your project.</dd> 348 349 <dt><a name="dependency"><b>Warning: library class ... depends on program class ...</b></a></dt> 350 351 <dd>If any of your library classes depend on your program classes, by 352 extending, implementing or just referencing them, your processed code will 353 generally be unusable. Program classes can depend on library classes, but 354 not the other way around. Program classes are processed, while library 355 classes always remain unchanged. It is therefore impossible to adapt 356 references from library classes to program classes, for instance if the 357 program classes are renamed. You should define a clean separation between 358 program code (specified with <a 359 href="usage.html#injars"><code>-injars</code></a>) and library code 360 (specified with <a 361 href="usage.html#libraryjars"><code>-libraryjars</code></a>), and try 362 again. 363 <p> 364 <img class="float" src="android_small.png" width="32" height="32" 365 alt="android" /> In Android development, sloppy libraries may contain 366 duplicates of classes that are already present in the Android run-time 367 (notably <code>org.w3c.dom</code>, <code>org.xml.sax</code>, 368 <code>org.xmlpull.v1</code>, <code>org.apache.commons.logging.Log</code>, 369 <code>org.apache.http</code>, and <code>org.json</code>). You must remove 370 these classes from your libraries, since they are possibly inconsistent, 371 and the run-time libraries would get precedence anyway.</dd> 372 373 <dt><a name="unexpectedclass"><b>Warning: class file ... unexpectedly contains class ...</b></a></dt> 374 375 <dd>The given class file contains a definition for the given class, but the 376 directory name of the file doesn't correspond to the package name of the 377 class. ProGuard will accept the class definition, but the current 378 implementation will not write out the processed version. Please make sure 379 your input classes are packaged correctly. Notably, class files that are 380 in the <code>WEB-INF/classes</code> directory in a war should be packaged 381 in a jar and put in the <code>WEB-INF/lib</code> directory. If you don't 382 mind these classes not being written to the output, you can specify the <a 383 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 384 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 385 option.</dd> 386 387 <dt><a name="mappingconflict1"><b>Warning: ... is not being kept as ..., but remapped to ...</b></a></dt> 388 389 <dd>There is a conflict between a <code>-keep</code> option in the 390 configuration, and the mapping file, in the obfuscation step. The given 391 class name or class member name can't be kept by its original name, as 392 specified in the configuration, but it has to be mapped to the other given 393 name, as specified in the mapping file. You should adapt your 394 configuration or your mapping file to remove the conflict. Alternatively, 395 if you're sure the renaming won't hurt, you can specify the <a 396 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 397 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 398 option.</dd> 399 400 <dt><a name="mappingconflict2"><b>Warning: field/method ... can't be mapped to ...</b></a></dt> 401 402 <dd>There is a conflict between some new program code and the mapping file, in 403 the obfuscation step. The given class member can't be mapped to the given 404 name, because it would conflict with another class member that is already 405 being mapped to the same name. This can happen if you are performing 406 incremental obfuscation, applying an obfuscation mapping file from an 407 initial obfuscation step. For instance, some new class may have been added 408 that extends two existing classes, introducing a conflict in the name 409 space of its class members. If you're sure the class member receiving 410 another name than the one specified won't hurt, you can specify the <a 411 href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option, 412 or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a> 413 option. Note that you should always use the <a 414 href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a> 415 option in the initial obfuscation step, in order to reduce the risk of 416 conflicts.</dd> 417 418 <dt><a name="unsupportedclassversion"><b>Error: Unsupported class version number</b></a></dt> 419 420 <dd>You are trying to process class files compiled for a recent version of 421 Java that your copy of ProGuard doesn't support yet. You 422 should <a href="http://proguard.sourceforge.net/downloads.html">check 423 on-line</a> if there is a more recent release.</dd> 424 425 <dt><a name="keep"><b>Error: You have to specify '-keep' options</b></a></dt> 426 427 <dd>You either forgot to specify <a 428 href="usage.html#keep"><code>-keep</code></a> options, or you mistyped the 429 class names. ProGuard has to know exactly what you want to keep: an 430 application, an applet, a servlet, a midlet,..., or any combination of 431 these. Without the proper seed specifications, ProGuard would shrink, 432 optimize, or obfuscate all class files away.</dd> 433 434 <dt><a name="filename"><b>Error: Expecting class path separator ';' before 'Files\Java\</b>...<b>'</b> (in Windows)</a></dt> 435 436 <dd>If the path of your run-time jar contains spaces, like in "Program Files", 437 you have to enclose it with single or double quotes, as explained in the 438 section on <a href="usage.html#filename">file names</a>. This is actually 439 true for all file names containing special characters, on all 440 platforms.</dd> 441 442 <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> 443 444 <dd>In MacOS X, the run-time classes may be in a different place than on most 445 other platforms. You'll then have to adapt your configuration, replacing 446 the path <code><java.home>/lib/rt.jar</code> by 447 <code><java.home>/../Classes/classes.jar</code>.</dd> 448 449 <dt><a name="cantread"><b>Error: Can't read ...</b></a></dt> 450 451 <dd>ProGuard can't read the specified file or directory. Double-check that the 452 name is correct in your configuration, that the file is readable, and that 453 it is not corrupt. An additional message "Unexpected end of ZLIB input 454 stream" suggests that the file is truncated. You should then make sure 455 that the file is complete on disk when ProGuard starts (asynchronous 456 copying? unflushed buffer or cache?), and that it is not somehow 457 overwritten by ProGuard's own output.</dd> 458 459 <dt><a name="cantwrite"><b>Error: Can't write ...</b></a></dt> 460 461 <dd>ProGuard can't write the specified file or directory. Double-check that 462 the name is correct in your configuration and that the file is 463 writable.</dd> 464 465 <dt><a name="startinggui"><b>Internal problem starting the ProGuard GUI (Cannot write XdndAware property)</b> (in Linux)</a></dt> 466 467 <dd>In Linux, at least with Java 6, the GUI may not start properly, due to 468 <a href="http://bugs.sun.com/view_bug.do?bug_id=7027598">Sun 469 Bug #7027598</a>. The work-around at this time is to specify the JVM 470 option <code>-DsuppressSwingDropSupport=true</code> when running the 471 GUI.</dd> 472 473 </dl> 474 <p> 475 476 Should ProGuard crash while processing your application: 477 478 <dl> 479 <dt><a name="outofmemoryerror"><b>OutOfMemoryError</b></a></dt> 480 481 <dd>You can try increasing the heap size of the Java virtual machine (with the 482 usual <code>-Xms</code> and <code>-Xmx</code> options). You can also 483 reduce the amount of memory that ProGuard needs by removing unnecessary 484 library jars from your configuration, or by filtering out unused library 485 packages and classes. Remember that only classes or interfaces that are 486 extended or implemented by classes in your input jars are required.</dd> 487 488 <dt><a name="stackoverflowerror"><b>StackOverflowError</b></a></dt> 489 490 <dd>This error might occur when processing a large code base on Windows 491 (surprisingly, not so easily on Linux). In theory, increasing the stack 492 size of the Java virtual machine (with the usual <code>-Xss</code> option) 493 should help too. In practice however, the <code>-Xss</code> setting 494 doesn't have any effect on the main thread, due to <a 495 href="http://bugs.sun.com/view_bug.do?bug_id=4362291">Sun Bug 496 #4362291</a>. As a result, this solution will only work when running 497 ProGuard in a different thread, e.g. from its GUI.</dd> 498 499 <dt><a name="unexpectederror"><b>Unexpected error</b></a></dt> 500 501 <dd>ProGuard has encountered an unexpected condition, typically in the 502 optimization step. It may or may not recover. You should be able to avoid 503 it using the <a 504 href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. In 505 any case, please report the problem, preferably with the simplest example 506 that causes ProGuard to crash.</dd> 507 508 <dt><a name="otherwise"><b>Otherwise...</b></a></dt> 509 510 <dd>Maybe your class files are corrupt. See if recompiling them and trying 511 again helps. If not, please report the problem, preferably with the 512 simplest example that causes ProGuard to crash.</dd> 513 514 </dl> 515 <p> 516 517 <h2><a name="afterprocessing">Unexpected observations after processing</a></h2> 518 519 If ProGuard seems to run fine, but your processed code doesn't look right, 520 there might be a couple of reasons: 521 522 <dl> 523 <dt><a name="disappearingclasses"><b>Disappearing classes</b></a></dt> 524 525 <dd>If you are working on Windows and it looks like some classes have 526 disappeared from your output, you should make sure you're not writing your 527 output class files to a directory (or unpacking the output jar). On 528 platforms with case-insensitive file systems, such as Windows, unpacking 529 tools often let class files with similar lower-case and upper-case names 530 overwrite each other. If you really can't switch to a different operating 531 system, you could consider using ProGuard's <a 532 href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a> 533 option. 534 <p> 535 Also, you should make sure your class files are in directories that 536 correspond to their package names. ProGuard will read misplaced class 537 files, but it will currently not write their processed versions. Notably, 538 class files that are in the <code>WEB-INF/classes</code> directory in a 539 war should be packaged in a jar and put in the <code>WEB-INF/lib</code> 540 directory.</dd> 541 542 <dt><a name="notkept"><b>Classes or class members not being kept</b></a></dt> 543 544 <dd>If ProGuard is not keeping the right classes or class members, make sure 545 you are using fully qualified class names. If the package name of some 546 class is missing, ProGuard won't match the elements that you might be 547 expecting. It may help to double-check for typos too. You can use the <a 548 href="usage.html#printseeds"><code>-printseeds</code></a> option to see 549 which elements are being kept exactly. 550 <p> 551 If you are using marker interfaces to keep other classes, the marker 552 interfaces themselves are probably being removed in the shrinking step. 553 You should therefore always explicitly keep any marker interfaces, with 554 an option like "<code>-keep interface MyMarkerInterface</code>". 555 <p> 556 Similarly, if you are keeping classes based on annotations, you may have 557 to avoid that the annotation classes themselves are removed in the 558 shrinking step. You should package the annotation classes as a library, or 559 explicitly keep them in your program code with an option like "<code>-keep 560 @interface *</code>".</dd> 561 562 <dt><a name="notobfuscated"><b>Variable names not being obfuscated</b></a></dt> 563 564 <dd>If the names of the local variables and parameters in your obfuscated code 565 don't look obfuscated, because they suspiciously resemble the names of 566 their types, it's probably because the decompiler that you are using is 567 coming up with those names. ProGuard's obfuscation step does remove the 568 original names entirely, unless you explicitly keep the 569 <code>LocalVariableTable</code> or <code>LocalVariableTypeTable</code> 570 attributes.</dd> 571 572 </dl> 573 574 <h2><a name="dalvik">Problems while converting to Android Dalvik bytecode</a></h2> 575 576 If ProGuard seems to run fine, but the dx tool in the Android SDK subsequently 577 fails with an error: 578 579 <dl> 580 <dt><a name="simexception"><b>SimException: local variable type mismatch</b></a></dt> 581 582 <dd>This error indicates that ProGuard's optimization step has not been able 583 to maintain the correct debug information about local variables. This can 584 happen if some code is optimized radically. Possible work-arounds: let the 585 java compiler not produce debug information (<code>-g:none</code>), or let 586 ProGuard's obfuscation step remove the debug information again 587 (by <i>not</i> keeping the attributes <code>LocalVariableTable</code> 588 and <code>LocalVariableTypeTable</code> 589 with <a href="usage.html#keepattributes"><code>-keepattributes</code></a>), 590 or otherwise just disable optimization 591 (<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>).</dd> 592 593 <dt><a name="conversionerror"><b>Conversion to Dalvik format failed with error 1</b></a></dt> 594 595 <dd>This error may have various causes, but if dx is tripping over some code 596 processed by ProGuard, you should make sure that you are using the latest 597 version of ProGuard. You can just copy the ProGuard jars 598 to <code>android-sdk/tools/proguard/lib</code>. If that doesn't help, 599 please report the problem, preferably with the simplest example that still 600 brings out the error.</dd> 601 602 </dl> 603 604 <h2><a name="preverifying">Problems while preverifying for Java Micro Edition</a></h2> 605 606 If ProGuard seems to run fine, but the external preverifier subsequently 607 produces errors, it's usually for a single reason: 608 609 <dl> 610 <dt><a name="invalidclassexception1"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b></a></dt> 611 612 <dd>If you get any such message from the preverifier, you are probably working 613 on a platform with a case-insensitive file system, such as Windows. The 614 <code>preverify</code> tool always unpacks the jars, so class files with 615 similar lower-case and upper-case names overwrite each other. You can use 616 ProGuard's <a 617 href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a> 618 option to work around this problem. 619 <p> 620 If the above doesn't help, there is probably a bug in the optimization 621 step of ProGuard. Make sure you are using the latest version. You should 622 be able to work around the problem by using the <a 623 href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. You 624 can check the bug database to see if it is a known problem (often with a 625 fix). Otherwise, please report it, preferably with the simplest example on 626 which you can find ProGuard to fail.</dd> 627 628 </dl> 629 630 Note that it is no longer necessary to use an external preverifier. With the 631 <a href="usage.html#microedition"><code>-microedition</code></a> option, 632 ProGuard will preverify the class files for Java Micro Edition. 633 <p> 634 635 <h2><a name="runtime">Problems at run-time</a></h2> 636 637 If ProGuard runs fine, but your processed application doesn't work, there 638 might be several reasons: 639 640 <dl> 641 <dt><a name="stacktraces"><b>Stack traces without class names or line numbers</b></a></dt> 642 643 <dd>If your stack traces don't contain any class names or lines numbers, 644 even though you are keeping the proper attributes, make sure this debugging 645 information is present in your compiled code to start with. Notably the Ant 646 javac task has debugging information switched off by default.</dd> 647 648 <dt><a name="noclassdeffounderror"><b>NoClassDefFoundError</b></a></dt> 649 650 <dd>Your class path is probably incorrect. It should at least contain all 651 library jars and, of course, your processed program jar.</dd> 652 653 <dt><a name="classnotfoundexception"><b>ClassNotFoundException</b></a></dt> 654 655 <dd>Your code is probably calling <code>Class.forName</code>, trying to create 656 the missing class dynamically. ProGuard can only detect constant name 657 arguments, like <code>Class.forName("mypackage.MyClass")</code>. For 658 variable name arguments like <code>Class.forName(someClass)</code>, you 659 have to keep all possible classes using the appropriate <a 660 href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep 661 class mypackage.MyClass</code>" or "<code>-keep class * implements 662 mypackage.MyInterface</code>".</dd> 663 664 <dt><a name="nosuchfieldexception"><b>NoSuchFieldException</b></a></dt> 665 666 <dd>Your code is probably calling something like 667 <code>myClass.getField</code>, trying to find some field dynamically. 668 Since ProGuard can't always detect this automatically, you have to keep 669 the missing field in using the 670 appropriate <a href="usage.html#keep"><code>-keep</code></a> option, e.g. 671 "<code>-keepclassmembers class mypackage.MyClass { int myField; 672 }</code>".</dd> 673 674 <dt><a name="nosuchmethodexception"><b>NoSuchMethodException</b></a></dt> 675 676 <dd>Your code is probably calling something like 677 <code>myClass.getMethod</code>, trying to find some method dynamically. 678 Since ProGuard can't always detect this automatically, you have to keep 679 the missing method in using the 680 appropriate <a href="usage.html#keep"><code>-keep</code></a> option, e.g. 681 "<code>-keepclassmembers class mypackage.MyClass { void myMethod(); 682 }</code>". 683 <p> 684 More specifically, if the method reported as missing is 685 <code>values</code> or <code>valueOf</code>, you probably have to keep 686 some methods related to <a 687 href="examples.html#enumerations">enumerations</a>.</dd> 688 689 <dt><a name="missingresourceexception"><b>MissingResourceException</b> or <b>NullPointerException</b></a></dt> 690 691 <dd>Your processed code may be unable to find some resource files. ProGuard 692 simply copies resource files over from the input jars to the output jars. 693 Their names and contents remain unchanged, unless you specify the options 694 <a 695 href="usage.html#adaptresourcefilenames"><code>-adaptresourcefilenames</code></a> 696 and/or <a 697 href="usage.html#adaptresourcefilecontents"><code>-adaptresourcefilecontents</code></a>. 698 <p> 699 Furthermore, directory entries in jar files aren't copied, unless you 700 specify the option <a 701 href="usage.html#keepdirectories"><code>-keepdirectories</code></a>. 702 Note that Sun advises against calling <code>Class.getResource()</code> for 703 directories (<a href="http://bugs.sun.com/view_bug.do?bug_id=4761949">Sun 704 Bug #4761949</a>).</dd> 705 706 <dt><a name="disappearingannotations"><b>Disappearing annotations</b></a></dt> 707 708 <dd>By default, the obfuscation step removes all annotations. If your 709 application relies on annotations to function properly, you should 710 explicitly keep them with 711 <code><a href="usage.html#keepattributes">-keepattributes</a> 712 *Annotation*</code>.</dd> 713 714 <dt><a name="invalidjarfile"><b>Invalid or corrupt jarfile</b></a></dt> 715 716 <dd>You are probably starting your application with the java option 717 <code>-jar</code> instead of the option <code>-classpath</code>. The java 718 virtual machine returns with this error message if your jar doesn't 719 contain a manifest file (<code>META-INF/MANIFEST.MF</code>), if the 720 manifest file doesn't specify a main class (<code>Main-Class:</code> ...), 721 or if the jar doesn't contain this main class. You should then make sure 722 that the input jar contains a valid manifest file to start with, that this 723 manifest file is the one that is copied (the first manifest file that is 724 encountered), and that the main class is kept in your configuration,</dd> 725 726 <dt><a name="invalidjarindexexception"><b>InvalidJarIndexException: Invalid index</b></a></dt> 727 728 <dd>At least one of your processed jar files contains an index file 729 <code>META-INF/INDEX.LIST</code>, listing all class files in the jar. 730 ProGuard by default copies files like these unchanged. ProGuard may however 731 remove or rename classes, thus invalidating the file. You should filter the 732 index file out of the input 733 (<code>-injars in.jar(!META-INF/INDEX.LIST)</code>) or update the file 734 after having applied ProGuard (<code>jar -i out.jar</code>). 735 </dd> 736 737 <dt><a name="invalidclassexception2"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b> (in Java Micro Edition)</a></dt> 738 739 <dd>If you get such an error in Java Micro Edition, you may have forgotten to 740 specify the <a 741 href="usage.html#microedition"><code>-microedition</code></a> option, so 742 the processed class files are preverified properly.</dd> 743 744 <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> 745 746 <dd>If you get such a message in a Motorola or Sony Ericsson phone emulator, 747 it's because these emulators don't like packageless classes and/or 748 overloaded fields and methods. You can work around it by not using the 749 options <code><a href="usage.html#repackageclasses">-repackageclasses</a> 750 ''</code> and <a 751 href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>. 752 If you're using the JME WTK plugin, you can adapt the configuration 753 <code>proguard/wtk/default.pro</code> that's inside the 754 <code>proguard.jar</code>.</dd> 755 756 <dt><a name="failingmidlets"><b>Failing midlets</b> (on a Java Micro Edition device)</a></dt> 757 758 <dd>If your midlet runs in an emulator and on some devices, but not on some 759 other devices, this is probably due to a bug in the latter devices. For 760 some older Motorola and Nokia phones, you might try specifying the <a 761 href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a> 762 option. It avoids overloading class member names, which triggers a bug in 763 their java virtual machine. 764 <p> 765 You might also try using the <a 766 href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a> 767 option. Even if the midlet has been properly processed and then 768 preverified on a case-sensitive file system, the device itself might not 769 like the mixed-case class names. Notably, the Nokia N-Gage emulator works 770 fine, but the actual device seems to exhibit this problem.</dd> 771 772 <dt><a name="disappearingloops"><b>Disappearing loops</b></a></dt> 773 774 <dd>If your code contains empty busy-waiting loops, ProGuard's optimization 775 step may remove them. More specifically, this happens if a loop 776 continuously checks the value of a non-volatile field that is changed in a 777 different thread. The specifications of the Java Virtual Machine require 778 that you always mark fields that are accessed across different threads 779 without further synchronization as <code>volatile</code>. If this is not 780 possible for some reason, you'll have to switch off optimization using the 781 <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a> 782 option.</dd> 783 784 <dt><a name="securityexception"><b>SecurityException: SHA1 digest error</b></a></dt> 785 786 <dd>You may have forgotten to sign your program jar <i>after</i> having 787 processed it with ProGuard.</dd> 788 789 <dt><a name="classcastexception"><b>ClassCastException: class not an enum</b>, or <br /><b>IllegalArgumentException: class not an enum type</b></a></dt> 790 791 <dd>You should make sure you're preserving the special methods of enumeration 792 types, which the run-time environment calls by introspection. The required 793 options are shown in the <a 794 href="examples.html#enumerations">examples</a>.</dd> 795 796 <dt><a name="arraystoreexception"><b>ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</b></a></dt> 797 798 <dd>You are probably processing annotations involving enumerations. Again, you 799 should make sure you're preserving the special methods of the enumeration 800 type, as shown in the examples.</dd> 801 802 <dt><a name="compilererror"><b>CompilerError: duplicate addition</b></a></dt> 803 804 <dd>You are probably compiling or running some code that has been obfuscated 805 with the <a 806 href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a> 807 option. This option triggers a bug in 808 <code>sun.tools.java.MethodSet.add</code> in Sun's JDK 1.2.2, which is 809 used for (dynamic) compilation. You should then avoid this option.</dd> 810 811 <dt><a name="classformaterror1"><b>ClassFormatError: repetitive field name/signature</b></a></dt> 812 813 <dd>You are probably processing some code that has been obfuscated before with 814 the <a 815 href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a> 816 option. You should then use the same option again in the second processing 817 round.</dd> 818 819 <dt><a name="classformaterror2"><b>ClassFormatError: Invalid index in LocalVariableTable in class file</b></a></dt> 820 821 <dd>If you are keeping the <code>LocalVariableTable</code> or 822 <code>LocalVariableTypeTable</code> attributes, ProGuard's optimizing step 823 is sometimes unable to update them consistently. You should then let the 824 obfuscation step remove these attributes or disable the optimization 825 step.</dd> 826 827 <dt><a name="nosuchmethoderror"><b>NoSuchMethodError</b> or <b>AbstractMethodError</b></a></dt> 828 829 <dd>You should make sure you're not writing your output class files to a 830 directory on a platform with a case-insensitive file system, such as 831 Windows. Please refer to the section about <a 832 href="#disappearingclasses">disappearing classes</a> for details. 833 <p> 834 Furthermore, you should check whether you have specified your program jars 835 and library jars properly. Program classes can refer to library classes, 836 but not the other way around. 837 <p> 838 If all of this seems ok, perhaps there's a bug in ProGuard (gasp!). If so, 839 please report it, preferably with the simplest example on which you can 840 find ProGuard to fail.</dd> 841 842 <dt><a name="verifyerror"><b>VerifyError</b></a></dt> 843 844 <dd>Verification errors when executing a program are almost certainly the 845 result of a bug in the optimization step of ProGuard. Make sure you are 846 using the latest version. You should be able to work around the problem by 847 using the <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a> 848 option. You can check the bug database to see if it is a known problem 849 (often with a fix). Otherwise, please report it, preferably with the 850 simplest example on which ProGuard fails.</dd> 851 852 </dl> 853 854 <hr /> 855 <noscript><div><a target="_top" href="../index.html" class="button">Show menu</a></div></noscript> 856 <address> 857 Copyright © 2002-2013 858 <a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>. 859 </address> 860 </body> 861 </html> 862