I have build a .jar Library file. I can import it normally in my project but after Proguard Obfuscation, I could not call the class/function from that library anymore. My package and classes have been converted to a.class, b.class, c.class as shown in the picture below.
ProGuard renames classes. When distributing a library, you need to configure ProGuard to not rename the API you need to be exposed.
You can add a rule like:
-keep public class * {
public protected *;
}
This will stop renaming of all public & protected methods in all public classes.
Related
In my application I want use this library : https://github.com/xmuSistone/AndroidPileLayout
And I want use proguard in my project, when proguard my project show me may bugs.
For fix proguard, the library developer say:
proguard works wrong when you are using java.lang.reflect api, please
check your own code.
How can I fix it and keep java.lang.reflect?
Please help me
Reflection will need to have absolute path the the classes and its respective methods. So, you need to tell proguard to leave the stuff you need alone. You can describe this in your proguard-rules.pro file.
Example:
-keep public class fully_qualified_classname
-keepclassmembers public class fully_qualified_classname {
# will ignore all methods
public <methods>;
public static final String static_instance_variable_if_any;
}
I'm using xtext 2.13/java8 to create a DSL with IDE as described in "Implementing Domain-Specific Languages with Xtext and XTend 2nd edition".
The IDE includes a new project wizard, and the DSL includes a code generator that produces java code. The generated java code depends on some helper classes in another support plugin that is provided as part of the DSL project.
I can export the update site and install into a fresh eclipse.
There, I can create a new DSL project that compiles the DSL file into java.
I would like to extend the new project wizard so that I can automatically add the dependency on my support plugin to the generated MANIFEST file in the new project. I can add it manually after the project is created (the plugin is present in the installed feature), but I don't want users to have to do that.
org.eclipse.xtext.ui.wizard.AbstractPluginProjectCreator has code that adds the dependencies on logging packages, but I don't see any way to extend or override that logic using any extension points. Is there a way to do this?
This turned out to be not too hard, though it took a half-day of experimenting to find it.
The xtext project defines a generated MyDSLProjectCreator class in the *.ui plugin under src-gen in the .ui.wizard package that defines the method we need to override:
#Override
protected List<String> getRequiredBundles() {
return Lists.newArrayList(DSL_PROJECT_NAME);
}
By default, this adds just the DSL project bundle to the dependencies of the new project. I need to add also the support plugins. I can't edit this generated file, but I can extend it, so I defined MyExtendedProjectCreator class in the src folder of the same .ui.wizard package that extends this class (java source):
public class MyExtendedProjectCreator extends MyDslProjectCreator {
#Override
protected List<String> getRequiredBundles() {
return Lists.newArrayList(DSL_PROJECT_NAME,
"my.plugin.id");
}
}
To invoke that project creator instead of the default, I had to override another method in the MyDslUiModule class. This can be found in the .ui package under src (xtend file):
#FinalFieldsConstructor
class MyDslUiModule extends AbstractMyDslUiModule {
public def override Class<? extends IProjectCreator> bindIProjectCreator() {
MyExtendedProjectCreator;
}
}
When I use proguard in android studio, I notice that there are -keep class mypakageName.**{*;} to keep the class in my package and -keep interface mypackageName.**{*;} to keep the interface in my package etc... but I find it is fussy, can't I keep all the files in my package in just one sentence? Or is there a method can do that?
Using -keep class will keep any java type, including classes, interfaces, enums.
I've been trying to use ProGuard to obfuscate an application of mine. I have disabled every option exception for obfuscate. Loader is my main class.
The screenshot below is the result when I try to run my obfuscated jar.
No errors were given while obfuscating either.
My config
-injars 'C:\Users\Corsair\Desktop\obfuscate\Example.jar'
-outjars 'C:\Users\Corsair\Desktop\obfuscate\ExampleOut.jar'
-libraryjars 'C:\Program Files\Java\jre1.8.0_91\lib\rt.jar'
-dontskipnonpubliclibraryclassmembers
-dontshrink
-dontoptimize
-dontusemixedcaseclassnames
-dontpreverify
-dontnote
-dontwarn
-verbose
-keep class Loader
If this is the only configuration that you are using, also native methods will get obfuscated. As a result, their name will not match the ones in the native library anymore, and thus you will see an error like this when trying to load the library using System.loadLibrary.
You need to add at least a rule like this:
-keepclasseswithmembernames,includedescriptorclasses class * {
native <methods>;
}
This will instruct ProGuard to keep all native methods in any class it processes.
Edit:
Additional rules that are needed to get it working:
Remove -dontpreverify, preverify is needed for Java 7+
Keep the main method
This will keep the main method:
-keep class Loader {
public static void main(...);
}
You have to exclude certain classes from obfuscating like bean classes, callback classes and native classes. In the official examples the following is mentioned:
Processing native methods
If your application, applet, servlet, library, etc., contains native methods, you'll want to preserve their names and their classes' names, so they can still be linked to the native library.
-keepclasseswithmembernames,includedescriptorclasses class * {
native <methods>;
}
Note: We don't want to preserve all classes or all native methods; we just want to keep the relevant names from being obfuscated.
Processing callback methods
If your application, applet, servlet, library, etc., contains callback methods, which are called from external code (native code, scripts,...), you'll want to preserve them, and probably their classes too. They are just entry points to your code, much like, say, the main method of an application.
-keep class mypackage.MyCallbackClass {
void myCallbackMethod(java.lang.String);
}
Processing bean classes
If your application, applet, servlet, library, etc., makes extensive use of introspection on bean classes to find bean editor classes, or getter and setter methods, then configuration may become painful. There's not much else you can do than making sure the bean class names, or the getter and setter names don't change
Helpful: to use wildcards in class names and method signatures
-keep class mybeans.** {
void set*(***);
void set*(int, ***);
boolean is*();
boolean is*(int);
*** get*();
*** get*(int);
}
Also some other scenarios (Ressources, Serialization classes) can lead to problems. Please refer to the whole guide for these
ProGuard Official: Examples
I'm using Proguard to shrink my code. My strategy is to enable it and then follow the warnings to keep anything it complains about. If there are outside libraries, I try to follow the Proguard instructions the authors make available. Many instructions include a -dontwarn flag. If I disable the -dontwarn flag, I will get warnings. If we are keeping most classes via -keep flag, why do warnings still come up?
Example:
-keep class javax.** { *; }
# for butterknife
-keep class butterknife.** { *; }
-dontwarn butterknife.internal.**
-keep class **$$ViewBinder { *; }
-keepclasseswithmembernames class * {
#butterknife.* <fields>;
}
-keepclasseswithmembernames class * {
#butterknife.* <methods>;
}
Warning:butterknife.internal.ButterKnifeProcessor: can't find referenced class javax.annotation.processing.AbstractProcessor
Warning:butterknife.internal.ButterKnifeProcessor: can't find referenced class javax.annotation.processing.ProcessingEnvironment
Warning:butterknife.internal.ButterKnifeProcessor: can't find referenced class javax.lang.model.element.TypeElement
Warning:butterknife.internal.ButterKnifeProcessor: can't find referenced class javax.lang.model.element.Element
Warning:butterknife.internal.ButterKnifeProcessor: can't find referenced class javax.annotation.processing.Filer
Warning:butterknife.internal.ButterKnifeProcessor: can't find referenced class javax.tools.JavaFileObject
...
There are many warnings in ProGuard meaning different things. This particular one:
Warning:A: can't find referenced class B
Means that while ProGuard was processing class A it encountered reference to class B. But class B wasn't included as a source (-injars class_path) or as a library (-libraryjars class_path).
First note that for this particular warning in case of standard Android build chain adding -keep rules will not help. ProGuard transitively keeps referenced code.
This warning can happen for several reasons. Often a library X can contain code that uses another library Y. And X uses Y optionally - only when Y is present on the classpath, X doesn't enforce presence of Y. This way ProGuard is unable to find classes from Y.
To get rid of the warnings you have to either add Y as a dependency or ignore the relevant warnings.
In case of ButterKnife the situation is slightly different. Butterknife uses annotation processing. And it contains both the library and annotation processor in one dependency (latest version 7.0.1). So class butterknife.internal.ButterKnifeProcessor is still present in the compiled classes (even though it's work is already finished - used during java compilation). And ProGuard tries to process it. ProGuard fails to find the missing classes because they were used only during annotation processing and are not present for ProGuard processing.
In this case it's really necessary to ignore the warnings.