Entry points, reflection, and precise keep rules

A manifest needs the class name too#

For an executable JAR, a manifest may contain:

Main-Class: com.example.Main

A corresponding ProGuard/R8-style rule is:

-keep class com.example.Main {
    public static void main(java.lang.String[]);
}

Keeping only the method is insufficient when the manifest still names the original class. Likewise, permitting class obfuscation can break name-based loading even if the bytecode survives.

Inspect other runtime contracts#

The plugin checks recognized entry points such as ServiceLoader resources, reflection, Android manifests, serializers, framework annotations, JNI, and IntelliJ plugin descriptors. Follow a warning back to the specific source/resource contract.

Invoke Alt+Enter and review a supported generated rule in the configured destination. An annotation fix is offered only when the corresponding annotation exists on the project’s classpath. A broad keep-everything rule can remove warnings while defeating useful shrinking/renaming.

Select the tool and module#

Open Tools → Obfuscation Pro settings and confirm ProGuard, R8 mode, yGuard, or Allatori and its correct configuration. XML-based tools do not use identical rule syntax. In a multi-module project, verify which rule file governs the affected output.

Build and explain the result#

Run the actual obfuscator build, then load its mapping/seeds/usage outputs. Inspect whether the class is kept by name, renamed, or shrunk. For a kept class, navigate to the matching rule to confirm it is the intended rule rather than an accidental broad pattern.

Finish by exercising the runtime entry point. Static rules analysis cannot validate every dynamically constructed reflection name.

Keep rules sit beside the plugin mapping and source contract they protect. Select the image to view it at full size.