Inspections and keep rules

Inspect an obfuscated project#

Open a project with its existing ProGuard, R8, yGuard, or Allatori configuration. Select the intended rule file in settings. Inspect warnings on manifests, service declarations, resource class names, reflection, framework annotations, and plugin.xml entry points.

For each warning, identify why the class or member must survive: some entry points need a stable name, while others only need the code retained. A broad keep-everything rule can hide the issue while preventing useful shrinking and renaming.

Apply a targeted fix#

Invoke Alt+Enter on a supported inspection and review the proposed rule or annotation. ProGuard/R8 fixes append to the configured .pro file; tool-specific configuration uses the corresponding syntax. Annotation fixes are offered only when the annotation is available.

Inspect the version-control diff. Preserve application-specific assumptions and avoid accepting a rule solely because it removes a warning.

Validate against a build#

Run the actual minified build and exercise its runtime entry points. Generate new mapping/seeds/usage outputs, then inspect the coverage view. For a kept class, navigate to the matching keep directive to explain why its name survived.

Templates such as keepclass, keepserial, and baseline configuration files can help start a rule, but still require review for the application’s runtime behavior.