Markus Hintersteiner

Quoting some internal discussion around this: Yes, you can. You “just” need to adhere to using the right txn/span op names and measurements. * Every screens needs to be a...

Relevant GH issue for [adding a screens API is over here](https://github.com/getsentry/sentry-java/issues/2981).

Closing this PR as it only works for Timber 5.x and does not seem to fix the underlying root issue of ThreadLocal usages within the Timber library.

@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!

@ghasemdev Out of curiosity: Do you expect your JNI calls to still work once we make the requested changes? Looking at the ([ProGuard documentation](https://www.guardsquare.com/manual/configuration/examples#native)) and the default [Android ProGuard rules...

Let's check if DexGuard is capable of renaming Activities (and if there's a way to e.g. disable this)

https://dexprotector.com/docs is capable of renaming Activities: > Obfuscation of AndroidManifest: Applications/ActivityNames/ContentProviders/Receivers class names mangling We also shouldn't forget about Fragments, as they are even more subject to being obfuscated.

Let's rely on the hosting app to have the required permission (instead of declaring it ourselves). If the permission is missing, we simply don't provide this kind of data.

We could use our existing `ContentProvider` to populate the `CurrentActivityHolder`. Once SDK.init is called, we could fetch the "existing" activity from there. Downside: If `ContentProvider` is removed, this won't work.

Let's investigate if our DefaultUncaughtExceptionHandler can capture `REASON_EXCESSIVE_RESOURCE_USAGE` issues as well or not, as we should avoid reporting the same error twice.