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;
}
Related
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.
I use a c++ native Library in my Android project, but when Proguard is Enabled, the app crashes. My code in c++ depends on the packagename, so I need to prevent the packagename from being renamed by Proguard.
I used this rule so far, but it's not working:
-keepclasseswithmembernames class * {
native <methods>;
}
I appreciate you support.
Try this configuration to prevent specified package names from being obfuscated.
-keeppackagenames [package_filter]
A filter is a list of comma-separated names that can contain wildcards.
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 trying to obfuscate my Android app. After obfuscating, there are a few things broken, so I need to keep all classmembernames inside a special namespace.
what did't worked was
-keepclassmembers class my.namespace.to.keep** {*;}
any suggestion? It is no Problem if the whole class is kept or only its members.
You don't tell in what way it didn't work, but you may need to specify -keep instead of -keepclassmembers.
You can specify -printseeds to see which classes and class members are matched by the -keep options.
I want to generate the API for all the classes that are there in my Java 1.6 application.
It should look like regular Java 1.5 API documentation.
I don't have the source code. I have class files in a jar file.
You can’t produce Javadoc from jars of class files, not even rudimentary Javadoc. You can only generate Javadoc from source files, because that is where the Javadoc lives.
I haven't used it, but this opensource project claims to create docs from java class or jar files:
http://classdoc.sourceforge.net/
You can use the javap command on any class in your classpath. This will not produce Javadoc files, but it will allow you to see what the class provides.
Ex...
javap java.lang.String produces the following output
public final class java.lang.String implements java.io.Serializable, java.lang.Comparable<java.lang.String>, java.lang.CharSequence {
public static final java.util.Comparator<java.lang.String> CASE_INSENSITIVE_ORDER;
public java.lang.String();
public java.lang.String(java.lang.String);
public java.lang.String(char[]);
public java.lang.String(char[], int, int);
...and after a bunch of constructors there are other methods...
public int length();
public boolean isEmpty();
public char charAt(int);
public int codePointAt(int);
And you can have it show you other things too, but this is probably the most helpful.
Not exactly what you are looking for, but if you just have a jar with a bunch of classes this might be your best option.
Who is changing my question ? I don't have the source code. I have class files in a jar file. Purushotham 47 mins ago
You don't have any source files? Well then you're probably out of luck. There might be some obscure plugin buried in Eclipse's huge database that can do it from class files, but even then you're only going to get method signatures, not any comments.
However, if this is your project that you have written then you can generate JavaDoc in your IDE. For Eclipse do Project > Generate JavaDoc. In NetBeans, right click your project and select Generate JavaDoc.
If you're wanting to include your dependencies, then that's a very bad idea. Always link to your dependencies' JavaDocs, never include it in yours. If not for losing your sanity at seeing a massive wall of classes from Large Overly Framework X, it's just to keep them separate. If I want to read the JavaDoc on your project, I want to read it only on your project, not on slf4j.