Does statement order matter/is there precedence in Proguard? - proguard

In the proguard-rules.pro file, does the order of the statements matter?
For example, more broad to more specific:
# Class names are needed in reflection
-keepnames class com.amazonaws.**
-keepnames class com.amazon.**
# This is a big hammer to fix "unable to marshall response" errors.
-keep class com.amazonaws.services.cognitoidentityprovider.** { *; }
# Request handlers defined in request.handlers
-keep class com.amazonaws.services.**.*Handler
versus, more specific to more broad:
# This is a big hammer to fix "unable to marshall response" errors.
-keep class com.amazonaws.services.cognitoidentityprovider.** { *; }
# Request handlers defined in request.handlers
-keep class com.amazonaws.services.**.*Handler
# Class names are needed in reflection
-keepnames class com.amazonaws.**
-keepnames class com.amazon.**
Does the order of the -keep statements affect the way Proguard processes the file?
In addition to that, what about when two -keep* directives cover the same class? Which one takes effect, the first declared in the rules file, or the more specific rule?
For example:
-keepnames class com.amazonaws.**
-keep class com.amazonaws.services.cognitoidentityprovider.** { *; }
The second rule specifies a subset of the first rule, but the second rule is a more restrictive rule (-keep vs. -keepnames). Which of those statements will effect the subset of namespace?

Related

Proguard obfuscationdictionary not working

What I'm trying to achieve is to avoid my method paramaters having the names like String paramString or int paramInt. I am trying to use -obfuscationdictionary but it's not working (at least it's not doing what I presume it should, which is use my dictionary words instead of paramString etc)
I have the following Proguard config files in place, but my list of dictionary words are not being used. (I checked that it is finding the dictionary file by renaming the file it looks for, and it didn't compile, stating it couldn't find my dictionary).
# ==========================
# ===== GENERIC CONFIG =====
# ==========================
# Logging
-verbose
# Java Runtime
-libraryjars <java.home>/lib/rt.jar
# don't think I use this
# Preserve native methods
-keepclasseswithmembernames,includedescriptorclasses class * {
native <methods>;
}
# don't think I use this
# Preserve special enum methods
-keepclassmembers,allowoptimization enum * {
public static **[] values();
public static ** valueOf(java.lang.String);
}
# Preserve some source so it can be retraced
-renamesourcefileattribute SourceFile
-keepattributes SourceFile,LineNumberTable,!LocalVariableTable,!LocalVariableTypeTable
# Specific config
-useuniqueclassmembernames
-dontusemixedcaseclassnames # think this is only for unpacking on Windows machines, so shouldn't be applicable
-repackageclasses
#-dontshrink
#-dontoptimize
-obfuscationdictionary proguardDictionary.txt
# ==============================
# ===== APPLICATION CONFIG =====
# ==============================
# Preserve application entry point
#-keep public class MY.MAIN.CLASS.PACKAGE.MyGame {
# public static void main(java.lang.String[]);
#}
# Only obfuscate proprietary code
#-keep class !MY.GAME.PACKAGE.HERE.** { *; }
# This is a configuration file for ProGuard.
# http://proguard.sourceforge.net/index.html#manual/usage.html
#
# Starting with version 2.2 of the Android plugin for Gradle, this file is distributed together with
# the plugin and unpacked at build-time. The files in $ANDROID_HOME are no longer maintained and
# will be ignored by new version of the Android plugin for Gradle.
# Optimizations: If you don't want to optimize, use the proguard-android.txt configuration file
# instead of this one, which turns off the optimization flags.
# Adding optimization introduces certain risks, since for example not all optimizations performed by
# ProGuard works on all versions of Dalvik. The following flags turn off various optimizations
# known to have issues, but the list may not be complete or up to date. (The "arithmetic"
# optimization can be used if you are only targeting Android 2.0 or later.) Make sure you test
# thoroughly if you go this route.
-optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/*
-optimizationpasses 5
-allowaccessmodification
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-verbose
# Preserve some attributes that may be required for reflection.
-keepattributes *Annotation*,Signature,InnerClasses,EnclosingMethod
#-keep public class com.google.vending.licensing.ILicensingService
#-keep public class com.android.vending.licensing.ILicensingService
#-keep public class uk.co.russellwheeler.matcg.android.dfgcvb.ILicensingService
#-dontnote com.android.vending.licensing.ILicensingService
#-dontnote com.google.vending.licensing.ILicensingService
#-dontnote uk.co.russellwheeler.matcg.android.dfgcvb.ILicensingService
# For native methods, see http://proguard.sourceforge.net/manual/examples.html#native
-keepclasseswithmembernames class * {
native <methods>;
}
# Keep setters in Views so that animations can still work.
-keepclassmembers public class * extends android.view.View {
void set*(***);
*** get*();
}
# We want to keep methods in Activity that could be used in the XML attribute onClick.
-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}
# For enumeration classes, see http://proguard.sourceforge.net/manual/examples.html#enumerations
-keepclassmembers enum * {
public static **[] values();
public static ** valueOf(java.lang.String);
}
-keepclassmembers class * implements android.os.Parcelable {
public static final ** CREATOR;
}
-keepclassmembers class **.R$* {
public static <fields>;
}
# Preserve annotated Javascript interface methods.
-keepclassmembers class * {
#android.webkit.JavascriptInterface <methods>;
}
# The support libraries contains references to newer platform versions.
# Don't warn about those in case this app is linking against an older
# platform version. We know about them, and they are safe.
-dontnote android.support.**
-dontwarn android.support.**
# Understand the #Keep support annotation.
-keep class android.support.annotation.Keep
-keep #android.support.annotation.Keep class * {*;}
-keepclasseswithmembers class * {
#android.support.annotation.Keep <methods>;
}
-keepclasseswithmembers class * {
#android.support.annotation.Keep <fields>;
}
-keepclasseswithmembers class * {
#android.support.annotation.Keep <init>(...);
}
# =========================
# ===== LIBGDX CONFIG =====
# =========================
# Don't warn about necessary libs
-dontwarn com.badlogic.gdx.utils.GdxBuild
-dontwarn com.badlogic.gdx.physics.box2d.utils.Box2DBuild
-dontwarn com.badlogic.gdx.jnigen.BuildTarget*
-dontwarn com.badlogic.gdx.jnigen.**
-dontwarn de.matthiasmann.twlthemeeditor.fontgen.**
-dontwarn org.lwjgl.**
-dontwarn org.objectweb.asm.**
-dontwarn org.slf4j.**
-keepnames class com.badlogic.gdx.backends.android.AndroidInput*
-keepclassmembers class com.badlogic.gdx.backends.android.AndroidInput* {<init>(...);}
# LibGDX | Box2D World
#-keepclassmembers class com.badlogic.gdx.physics.box2d.World {
# boolean contactFilter(long, long);
# void beginContact(long);
# void endContact(long);
# void preSolve(long, long);
# void postSolve(long, long);
# boolean reportFixture(long);
# float reportRayFixture(long, float, float, float, float, float);
#}
-verbose
-dontwarn android.support.**
-dontwarn com.badlogic.gdx.backends.android.AndroidFragmentApplication
-dontwarn com.badlogic.gdx.utils.GdxBuild
-dontwarn com.badlogic.gdx.physics.box2d.utils.Box2DBuild
-dontwarn com.badlogic.gdx.jnigen.BuildTarget*
-keepclassmembers class com.badlogic.gdx.backends.android.AndroidInput* {
<init>(com.badlogic.gdx.Application, android.content.Context, java.lang.Object, com.badlogic.gdx.backends.android.AndroidApplicationConfiguration);
}
-keepclassmembers class uk.co.russellwheeler.matcg.android.** {
<init>(...);
}
-keepclassmembers class com.badlogic.gdx.physics.box2d.World {
boolean contactFilter(long, long);
void beginContact(long);
void endContact(long);
void preSolve(long, long);
void postSolve(long, long);
boolean reportFixture(long);
float reportRayFixture(long, float, float, float, float, float);
}
-keep class javax.activation.* { *; }
-dontwarn javax.activation.**
# Crashlytics 2.+
-keep class com.crashlytics.** { *; }
-keep class com.crashlytics.android.**
-keepattributes SourceFile, LineNumberTable, *Annotation*, !LocalVariableTable,!LocalVariableTypeTable
# If you are using custom exceptions, add this line so that custom exception types are skipped during obfuscation:
-keep public class * extends java.lang.Exception
# For Fabric to properly de-obfuscate your crash reports, you need to remove this line from your ProGuard config:
-printmapping mapping.txt
AFAIK, Proguard does not "obfuscate" parameter names in the same way as other names, it just strips them (because unlike field and class names, parameter names are stored in optional debugging symbols). "Parameter names", that you see in decompiler (paramInt, arg0 etc.), are just made up names, autogenerated by decompiler itself. There is no support for applying obfuscation dictionary to parameter names, — you can either strip them completely or keep them (provided that your binaries had them in the first place).
You can try to preserve original parameter names via -keepattribute LocalVariableTable, but that might not work unless you -keep entire class, — Proguard's handling of local variables in modern classfiles is kinda buggy. If you don't do anything, Proguard will default to removing them.
As the other answer already correctly said, ProGuard will not use the obfuscation dictionary for method parameters. Either they are removed or kept with their original names.
In order to keep them, you have to add the following:
-keepparameternames

How to exclude specific methods from a "keep" rule in ProGuard?

I'm running ProGuard on a library. To keep public methods and attributes from shrinkage and obfuscation, I'm using this rule:
-keep public class com.company.project.** {
public protected <fields>;
public protected <methods>;
}
I need to make a few exceptions to this rule - methods that I actually need to be shrinked/obfuscated regularly by ProGuard. Is that possible? What would be the syntax for that?

How to keep class with ProGuard

I'm using ProGuard and I want to keep a class with all its methods.
So what's the difference between
-keep class Foo
and
-keep class Foo {*;}
-keep class Foo makes sure the class Foo (but not necessarily its contents) remains present with that name in the output.
-keep class Foo { *; } makes sure the class Foo and all of it fields and methods remain present with their original names in the output.
See the ProGuard manual > Usage > Keep Options.

don't keep super class's public method in proguard

I have class A , and class B extends class A.
My proguard config is :
-keep public class B {
public <methods>;
}
I just want to keep the public methods in B , but proguard keep the public methods in A too.
Does anyone know how to reslove it ?
thanks ~
You'll have to enumerate the methods. Semantically, public methods of super classes are public methods in their subclasses too, so ProGuard keeps them if you use a wildcard..

Named query on abstract entity

I have 3 entities in hierarchy:
Request.java
#Entity
#Table(name="Request")
#Inheritance(strategy=InheritanceType.JOINED)
#DiscriminatorColumn(name="REQUEST_TYPE", discriminatorType=DiscriminatorType.INTEGER)
#NamedQuery(name="getRequestsById", query="select r from Request r where r.id=:id and r.status=100")
public abstract class Request implemenst Serializable {
...
}
MedicineRequest.java
#Entity
#Table(name="MED_REQUEST")
public abstract class MedicineRequest extends Request {
...
}
ExtendedMedicineRequest.java
#Entity
#Table(name="EXT_MED_REQUEST")
#DiscriminatorValue("1")
public class ExtendedMedicineRequest extends MedicineRequest {
...
}
Where I'm trying to run the above query, getRequestsById, I'm getting the following error message:
Cannot instantiate abstract class of type "Request" with object id "Request-RequestPK#c49aa166"; this may indicate that the inheritance discriminator for the class is not configured correctly.
All the entities are defined properly in persistance.xml, name of the discriminator column is correct too. What can be the matter??
No, it's ok to the entity to be abstract. But I found the reason. The query is generic, so it requests instantiation of sons of this entity. One of sons has relationship to other entity that uses enum from the utility jar. But...jpa project has this jar on the build path, wheh the EAR project doesn't include this jar in module list, so finally, the jar wasn't on the classpath in runtime. The error message was commonly irrelevant in this case.
The reason is "Cannot instantiate abstract class of type", your Request class is abstract. Why? It's an entity then it SHOULDN'T be abstract.