javaandroidproguardinner-classesandroid-proguard

How to keep Fields and Methods of Inner Class in Proguard (Not only the Class itself)


I've created an annotation that should assist me to mark classes that should be kept in its entirety in the obfuscation step.

Then I would use the following proguard configuration to keep everything:

-keep @com.my.project.annotations.ProguardKeepEverything class * { *; }

So the following class and its members (incl. names) will be kept:

@ProguardKeepEverything
public class APublicModel {
    private String aField;
}

But now I have inner classes like:

@ProguardKeepEverything
public class APublicModel {
    private String aField;

    public static class InnerPublicClass {
        private String innerAField; 
    }
}

so I add the following rule:

-keep @com.my.project.annotations.ProguardKeepEverything class *$* { *; }

and also tryed

-keep @com.my.project.annotations.ProguardKeepEverything class *$** { *; }

But now it ONLY keeps the inner class (and name) itself but its fields and methods are obfuscated. How do I keep the methods and fields of inner classes from being obfuscated (ie. names are intact)?

I check if the classes are obfuscated with seed.txt and apktool.


The following Questions only care about keeping the classe, not its methods:


Solution

  • From the bytecode point of view, inner classes are ordinary classes; they only have ...$... names (and InnerClasses attributes, for the sake of reflection and compilers). ProGuard doesn't treat them differently. Your additional rules would therefore only match inner classes that have the annotation. The best solution I see at this time is to specify the main rule and then annotate the inner classes as well.

    Background: the patterns in ProGuard's rules specify the elements that are matched and the elements that are kept as a result (with slight variations between -keep, -keepclassmembers, and -keepclasseswithmembers). You therefore can't specify "IF some class is matched THEN keep some other class". This is very rarely needed and rules can already be complex, but I am considering a more general extension.