If ProGuard notes that it can't find the classes that are accessed with Class.forName, they must be missing from the input. You can use "gradle -d assembleRelease" to see which directories and jars ProGuard is reading. "-keep class **" really keeps all classes with their original names. You can check build/outputs/mapping/release/mapping.txt to verify that. You can try "gradle clean" to make sure the build process is not reusing any cached files.
ProGuard 6.0 probably won't support multiple class versions (yet). ProGuard's internal data structures represent a single consistent application on which the algorithms operate. This mechanism allows to input interweaved but potentially completely different versions of the code. I'll think about workarounds.
Proguard should not introspect class files contained in META-INF
Thanks for the report. ProGuard 6.0 will support Java 9 class files, although the current implementation doesn't support multiple class file versions (the prefix META-INF/versions). ProGuard currently reads class files in such unexpected locations, but doesn't write them to the output. As a workaround, you can filter out these class files: -injars log4j-api-2.9.0.jar(!META-INF/versions/**.class) This is assuming that you specify the -injars explicitly in your configuration file, not through some...
Methods in library classes (e.g. the JVM runtime classes) are never inlined, since their implementations could indeed vary. Maybe the call has been optimized away for different reasons?
There's no such option at this time. DexGuard has "-keep,includecode", but even then it's tricky, since optimizing code elsewhere, e.g. enumeration types, may affect a given method. I actually prefer to get the error reports and then solve them, although I realize that this is a slow process.
The choice of obfuscation dictionaries is largely irrelevant for performance and for obfuscation. Mixed-case class names and reserved keywords may be slightly annoying for basic reverse engineering and tampering. Eric
ProGuard overloads field type even if it was mentioned in AtomicReferenceFieldUpdater.newUpdater expression