Develop Reference

Meaning of -if in Proguard

For the following Proguard rule(take Kotlin Serialization)
-if #kotlinx.serialization.Serializable class **
-keepclassmembers class <1> {
static <1>$Companion Companion;
}
Here what is the meaning of -if in context with the above rule? I tried looking into official proguard documentation but couldn't find easy to any info around that

I wrote those ProGuard rules. :) The pull request discussion about these changes may provide relevant background.
I understand your confusion, the ProGuard rules documentation is quite sparse.
-if class_specification
Specifies classes and class members that must be present to activate the subsequent keep option (-keep,
-keepclassmembers,...). The condition and the subsequent keep option can share wildcards and references to wildcards. For example, you can
keep classes on the condition that classes with related names exist in
your project, with frameworks like Dagger and Butterknife.
As written in the comments of the rules you copied this from:
# Keep `Companion` object fields of serializable classes.
# This avoids serializer lookup through `getDeclaredClasses` as done for named companion objects.
-if #kotlinx.serialization.Serializable class **
...
So, -if #kotlinx.serialization.Serializable class ** should be read as: for all classes which have the #Serializable annotation applied (i.e., "serializable classes"). The <1> in -keepmembers subsequently refers to the ** wildcard, i.e., the fully-qualified class name.

Why some package-private classes are not obfuscated by Proguard?

Working with an Android project in Android Studio 3.2, having enabled Proguard and some specific rules, I'm not able to figure out the following:
a specific package (and its subpackages) in a library module, used by client code, is preserved through the rule:
-keep public class com.mylib.mypackage.** {
public protected *;
}
Now, within this package there are also a number of package-private classes, which should not be picked by that rule. Some of those classes are effectively obfuscated, both in their own names and their member names, which is fine.
Instead there are some classes, implementing public interfaces, whose class names are not obfuscated, while I'd expect they should. For completeness, their member names, when not part of interface, are effectively obfuscated.
Example:
/* package */ class InternalComponent implements ExternalInterface {
// ExternalInterface is kept: Ok
// InternalComponent is kept: don't like, I'd like it renamed
#Override
public void ExternalMethod() {
// this is kept: Ok
}
public void InternalMethod() {
// this is renamed: Ok
}
}
I'd like to highlight that InternalComponent is created within some other (kept) class and only returned to client code through the ExternalInterface.
How can I also obfuscate their class names as well, if possible?
Edit #1
After #emandt answer on Proguard output files, I double checked and com.mylib.mypackage.InternalComponent is listed in seeds.txt, which according to this blog post lists all items matched by keep rules. So, for some reason, the rule above also picks package-private classes, which still seems wrong to me.
Edit #2
In the meantime, I ended up doing exactly the same approach proposed by #shizhen. For completeness, in order to extend the exclusion to any package named internal, I modified my proguard rule as:
-keep public class !com.mylib.mypackage.**.internal.*, com.mylib.mypackage.** {
public protected *;
}
(note the first part before the comma, prefixed by !)
I'll mark #shizhen answer, though I'd like to be curious as to why the original rule is also picking package-private components.

Are you working on an Android Library project? Probably YES.
In order to achieve your purpose, I am afraid that you need to re-organise your packages into something like below:
Public interfaces
com.my.package.apiforusers
Private/Internal implementations
com.my.package.apiforusers.internal
Then for your obfuscation rules, you can have it like below:
-keep public class com.my.package.apiforusers.** { public *; }
So that only the public classes/interfaces are kept and all those ones inside com.my.package.apiforusers.internal will be obfuscated.
Please note the double-asterisk at the end so that public classes/interface are also kept for the sub-packages.

In "/build/outputs/mapping/release/" folder there are few files ("usage.txt", "seeds.txt", etc..) that contain the REASONS of why and which classes/variables/methods/etc.. are not-processed/not-shrinked/ot-obfuscated via ProGuard utilities.

Android Data Binding: Wrong BR class generated for obfuscated AAR

I'd like to provide an obfuscated AAR library which makes use of Android data binding. When I use the library from a test app, everything works fine as long as the library isn't minified by ProGuard. However, after enabling ProGuard the test app doesn't compile any more since BR fields in the generated data binding classes can't be found.
Since I couldn't find any official documentation on this "specific" subject, I tried to understand the magic behind Android data binding. The mechanism seem to be like this (please correct me, if I'm wrong):
In order to use data binding within an AAR lib, the embedding app must enable data binding, too.
This is because the the layout resources that contain data binding instructions are included without modification in the AAR.
It's therefore the embedding app's responsibility to generate the corresponding data binding classes for the layouts in the lib. (That's why the lib's view model classes must not be obfuscated, BTW.)
The challenge for the Android data binding generator is to tell the package names apart from both library and embedding app: The BR class for the library must be generated in the library's package (e. g. com.example.lib.databinding), since this class is accessed from the library's view model classes. On the other hand, the BR class of the embedding app should normally be generated within the app's package (com.example.app.databinding).
And this is exactly where my problems begin. I don't know Android exactly rises to this challenge, I only know that in my case, it works with an unobfuscated lib, and it doesn't with an obfuscated one. When I look into the generated source of the embedding app, I see:
When using the unobfuscated lib, both the BR and all *Binding.java classes are generated within the library's package, and the app compiles.
When using the obfuscated lib, both the BR and all *Binding.java classes are generated within the apps's package. Even worse, the BR only contains constants for the model variable names in the XML resource, not for the properties in the view model classes. Consequently, the app doesn't compile.
I tried to set the package of the data binding classes explicitely to the lib's package in the XML declaration, but this doesn't solve the problem with the incomplete BR class.
I have no clue where these differences come from and I' already fearing that the only solution could be removing all my nice data binding stuff from the lib ... Does anybody made similar experiences and could give me a hint, please?
These are the ProGuard exceptions I've already added to my lib:
-keep public class **.BR { public *; }
-keep public class **.BR$* { public *; }
-keepclassmembers class **.BR$* {
public static <fields>;
}
-keepclassmembers class **.R$* {
public static <fields>;
}
-keep class android.databinding.** { *; }
-keep class * extends android.databinding.** { *; }
-keep class com.example.lib.databinding.** { *; }

I managed to make it run in the meantime, but the "solution" is so weird that I really don't want to take it over to a productive version ...
When comparing the AAR files of the obfuscated and unobfuscated lib, I noticed that the classes.jar of the unobfuscated one contained these three files:
/com/example/lib/com.example.lib-br.bin
/com/example/lib/com.example.lib-layoutinfo.bin
/com/example/lib/com.example.lib-setter_store.bin
These binary files contain some of my data binding class names and are apparently important for the code generation process. I just tried to copy these files into the corresponding place of my obfuscated AAR and ... it worked!!!
But this cannot be the final solution. At least it would be more reliable than coping if I can convince ProGuard to simply keep these non-class-files within the classes.jar. Any ideas how to do this?
Much more I would appreciate to get some information on the backgrounds of this mechanism and whether it is possible to avoid such ugly low-level operations for solving a problem that actually should be standard.
Thanks in advance for any answer!

Apparently Google has resolved the issue with Gradle plugin 2.3.0, see https://code.google.com/p/android/issues/detail?id=229684.

Proguard: How to avoid shrinking (and obfuscating) an entire package to avoid removing (and obfuscating) "unused methods"?

I'm currently using an Android library that uses a lot of reflection.
As soon as I enable proguard, and run it... it crashes.
Why? It uses a lot of reflection and the methods are only invoked via reflection, so they are detected by proguard as unused and removed during the shrinking process, so a a NoSuchMethodError is thrown.
Why this happens? That is easy to figure out they are removed during the shrinking process as proguard considers they are unused and therefore removes that pieces of code (all the methods)
So, how can I configure proguard to avoid shrinking or obfuscating an entire package? (the library)
Note: I don't want to use the -dontshrink option, as it's all or nothing and I just want to avoid a specific package.
More info:
The runtime error is the following:
E/AndroidRuntime: FATAL EXCEPTION: main Process: com.my.app.debug, PID: 3771
java.lang.NoSuchMethodError: observeValueForKeyPath [class java.lang.String, class java.lang.Object, class com.my.lib.util.Dictionary, class java.lang.Object]
at com.my.lib.util.Observable$ObservationManager$Observer.<init>(SourceFile:47)
at com.my.lib.util.Observable$ObservationManager$Observer.<init>(SourceFile:26)
at com.my.lib.util.Observable$ObservationManager.addObserver(SourceFile:159)
...
Take note that the problem is one an inner inner class...
My current configuration has something like:
-keep,includedescriptorclasses class com.my.** { *; }
-keepclassmembers class com.my.lib** { *; }
-keep,includedescriptorclasses class com.my.lib.util.Observable$* { *; }
-keep,includedescriptorclasses class com.my.lib.util.Observable$*$* { *; }
But this apparently only avoids obfuscating the methods not removed during the shrinking process... I need to avoid removing methods during shrinking.

According to the documentation -keep should work even when shrinking, while -keepclassmembers only works "if [the] classes are preserved as well".

-keep class com.library.** { *; }

For the sake of people in the future with similar problems, I'll explain what really was happening:
The -keep class my.app.package was really avoiding methods to be removed by shrinking and obfuscated (#F43nd1r's answer made me realize that by really pointing that the docs said that it avoid also shrinking), so the problem was elsewhere
After decompiling the lib's code and passing some time reading it, I found that it received as a parameter an instance of another class (not from that lib) and a string with a method name that it used for reflection. That was the problem, I needed to also avoid obfuscating that class.

I use the option -dontshrink to prevent shrinking.
Source: link

How to make Proguard keep the class method names and attribute names as it is?

As above.
My ProGuard config is
-keepclassmembers public class myApp.interfaces.**
-keepclasseswithmembernames public class myApp.interfaces.**
-keepattributes Signature
-keepparameternames
Really new to this and no real idea what I'm doing.
What I'm trying to achieve is to make Proguard not change the method and variable names of all Classes inside myApp.interfaces.*. If they want to rearrange some algo stuff to optimise it or whatever, it's fine. As long as the names are not changed.
This must be done because of the Serializable issue between server and client.

Simply use:
-keep class myApp.interfaces.** { *; }
It will not touch the class or its members. If you get errors / warnings, Rebuild the project.