Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Sentry Proguard/R8 rules when migrating from Crashlytics #2844

Answered by romtsn
G00fY2 asked this question in Q&A
Discussion options

Hi everyone,

I know that Sentry ships it's own Android Proguard/R8 rules. Most of them are defined in the sentry-android-core/proguard-rules.pro.

Previously we added the rules recommended by Google: Required configuration when using R8, ProGuard, and DexGuard

I see that Sentry already includes the first rule (so we can remove it in our own proguard rules file):
-keepattributes LineNumberTable,SourceFile

But I am wondering if we should keep the following rule recommended by Google: -keep public class * extends java.lang.Exception

I found out that this line was present in the old Sentry Gradle Plugin: https://github.com/getsentry/sentry-java/pull/790/files

Any opinion or explanation why this rule is not present anymore?

Thanks

You must be logged in to vote

I guess this rule is necessary, because there's no server-side deobfuscation of the exception titles on Firebase. This is mostly relevant if you have custom exception types that you'd like to keep from being obfuscated (all default types like IllegalArgumentException are part of Android/JDK already). Sentry tries to deobfuscate this server-side but there are some rough edges, so sometimes we also have to provide rules like this ourselves:

-keepnames class io.sentry.android.core.ApplicationNotResponding

-keepnames should be enough in this case as we only are interested in the name of the class.

Replies: 1 comment 2 replies

Comment options

I guess this rule is necessary, because there's no server-side deobfuscation of the exception titles on Firebase. This is mostly relevant if you have custom exception types that you'd like to keep from being obfuscated (all default types like IllegalArgumentException are part of Android/JDK already). Sentry tries to deobfuscate this server-side but there are some rough edges, so sometimes we also have to provide rules like this ourselves:

-keepnames class io.sentry.android.core.ApplicationNotResponding

-keepnames should be enough in this case as we only are interested in the name of the class.

You must be logged in to vote
2 replies
Comment options

Thanks for this answer!

Does this mean, that #711 is not relevant anymore and that Sentry backend should be able to reliably deobfuscate the class names of exceptions (also for custom exceptions)? Was this the reason to drop this rule in the current Gradle plugin and Android libs (it was previously also present there)?

Since we can not know or control in which degree other libraries make use of custom exceptions, we like to make sure to not add noise to our reports with obfuscated exception names. So is it advisable to add the -keepnames public class * extends java.lang.Exception rule or is it usually not required?

Comment options

Yes, the backend should be doing that getsentry/sentry#15795. If it's not happening you could file a bug report and add the aforementioned rule just to be safe, I don't expect that this rule will increase the apk size significantly.

Answer selected by G00fY2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
2 participants

AltStyle によって変換されたページ (->オリジナル) /