Obfuscating package names myapplication. MyMain is the main application class that is kept by the configuration. All other class names can be obfuscated. Note that not all levels of obfuscation of package names may be acceptable for all code.
-keepclassmembernames. This is the most permissive keep directive; it lets ProGuard do almost all of its work. Unused classes are removed, the remaining classes are renamed, unused members of those classes are removed, but then the remaining members keep their original names.
ProGuard is a command-line tool that reduces app size by shrinking bytecode and obfuscates the names of classes, fields and methods. It's an ideal fit for developers working with Java or Kotlin who are primarily interested in an Android optimizer.
You don't specify in what way it doesn't work. Your configuration keeps the names of all public classes in the specified package:
-keep public class com.myapp.customcomponents.*
The following configuration keeps the names of all public classes in the specified package and its subpackages:
-keep public class com.myapp.customcomponents.**
The following configuration keeps the names of all public/protected classes/fields/methods in the specified package and its subpackages:
-keep public class com.myapp.customcomponents.** {
public protected *;
}
Add the following line at the bottom of your ProGuard configuration:
-keep class com.facebook.** { *; }
Replace package name accordingly, here the package com.facebook
will be excluded from ProGuard.
What worked for me using Android Studio 4.0 is:
-keepclassmembers class com.myapp.customcomponents.* {
<fields>;
<init>();
<methods>;
}
Double asterisks (**) in other answers did not work for me. I also tried the above configuration with R8, works fine.
Lots of people seem to recommend -keep class com.myapp.customcomponents.** { *; }
as a way to exclude a path from being processed. See here:
The problem with this solution is that there is still some level of obfuscation happening, which can break your code. You can see the mapping in the mapping print out:
java.lang.String toString() -> toString
int getMemoizedSerializedSize() -> getMemoizedSerializedSize
void setMemoizedSerializedSize(int) -> setMemoizedSerializedSize
int getSerializedSize() -> getSerializedSize
boolean equals(java.lang.Object) -> equals
int hashCode() -> hashCode
The solution I have opted for is a two step process. First, use injars
with a filter to select the package path I would like to process. It is possible to add the other package pathes as libraries.
-injars artifacts/in.jar(org/toprocess/**.class)
-outjars out/processed.jar
-libraryjars artifacts/in.jar(org/skipped/**.class)
-libraryjars artifacts/in.jar(org/moreskipped/**.class)
Second, merge the processed jar with the original jar, but only those paths that were skipped.
-injars out/processed.jar
-injars artifacts/in.jar(org/skipped/**.class)
-injars artifacts/in.jar(org/moreskipped/**.class)
-outjars out/merged.jar
-dontshrink
-dontoptimize
-dontobfuscate
The result is a merged jar that is the combination of the processed package path and the skipped paths. This exercise is invalid, if someone can provide a way to skip processing of certain paths completely (which I haven't found).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With