sentry-android-ndk proguard rule keeps all native class

[ghasemdev]

trafficstars

Integration

sentry-android-ndk

Build System

Gradle

AGP Version

8.9.2

Proguard

Enabled

Version

7.22.5

Steps to Reproduce

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.

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 Result

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.

Actual Result

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

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

[markushi]

@ghasemdev thanks for opening this up! This is indeed an issue on our end, seems like it's always been this way, but we should definitely fix this!

[romtsn]

@markushi I guess we could actually remove this proguard-rules.pro file altogether since we consume the ndk artifact from sentry-native now, right? And make the actual fix there.

[supervacuus]

And make the actual fix there.

apropos: https://github.com/getsentry/sentry-native/pull/1250

[markushi]

@ghasemdev Out of curiosity: Do you expect your JNI calls to still work once we make the requested changes? Looking at the (ProGuard documentation) and the default Android ProGuard rules here, is seems to be required to exclude any native methods.

We'll still incorporate and merge the open PRs, but I'm curious if you expect obfuscated JNI methods to work.

[ghasemdev]

@ghasemdev Out of curiosity: Do you expect your JNI calls to still work once we make the requested changes? Looking at the (ProGuard documentation) and the default Android ProGuard rules here, is seems to be required to exclude any native methods.

We'll still incorporate and merge the open PRs, but I'm curious if you expect obfuscated JNI methods to work.

Thanks for the question!

Yes, I do expect Sentry’s native methods to remain kept in order for Sentry to continue working properly — those are marked and handled accordingly.

However, for my own project's native bridge functions, I'm intentionally using dynamic loading and I actually want those methods to be obfuscated. I'm handling the obfuscation via C++ macro headers that are generated during the build process. This allows me to properly register the Kotlin methods in C++ after obfuscation, so that I won’t run into any ClassNotFoundException or NoSuchMethodError at runtime.

This setup gives me flexibility and security while still keeping the JNI bridge functional.

[stefanosiano]

@ghasemdev This is interesting @markushi I guess we'll have to dig deeper in the proguard rules then 😅