Description

Some third-party libraries include the following ProGuard rule:

-keepclasseswithmembernames,includedescriptorclasses class * {
    native <methods>;
}

This rule is too broad and prevents class name obfuscation for all classes with native methods — not just those from the library itself.
This impacts security and maintainability in downstream projects, especially in cases where native methods contain security-sensitive logic and developers want to obscure their names.

When does the problem happen

• During build
• During run-time

Steps To Reproduce

1. Include a library that contains the following rule in its ProGuard file:

   -keepclasseswithmembernames,includedescriptorclasses class * {
       native <methods>;
   }
   

2. Add your own class with a native method:

   public class SecureNative {
       public native void signTransaction(byte[] input);
   }

3. Build with R8 enabled.

4. Inspect the mapping file or APK — the class and method names will not be obfuscated.

Log output

No error, but the obfuscation is blocked unexpectedly.

📌 Expected behavior

Third-party libraries should scope ProGuard rules only to their own package, for example:

-keepclasseswithmembernames,includedescriptorclasses class io.sentry.** {
    native <methods>;
}

🔐 Security concern

In our project, we use native methods for security-critical operations (e.g., cryptographic signing, hardware access). These method names should be obfuscated to prevent easy reverse engineering.
However, the use of overly broad ProGuard rules from dependencies prevents that, and we are forced to manually clean the merged configuration.txt before release — which is fragile and error-prone.

✅ Suggested resolution

Update the ProGuard rule to scope it only to your own package:

-keepclasseswithmembernames,includedescriptorclasses class io.sentry.** {
    native <methods>;
}