_Platform:_
_IDE:_
_Build system:_
_Sentry Android Gradle Plugin:_
_Proguard/R8:_
The version of the SDK:
3.1.0
I have the following issue:
After upgrading from 2.3.2 to 3.1.0 ANR reports do not include any thread informations.
Steps to reproduce:
if (true) {
int a = 0;
while (true) {
a++;
}
}
Result:

3.1.0
thanks for raising this, would you mind to try again but enabling SentryOptions.attachThreads? thanks
this should have done the job: https://github.com/getsentry/sentry-java/blob/5ebd49cbfd17eb66175e9247db6d27e4df84a56b/sentry-android-core/src/main/java/io/sentry/android/core/ApplicationNotResponding.java#L24
I mean it does, but it doesn't look like having the whole stack traces or it's reporting the capturing thread but not the UI one.
SentryOptions.attachThreads does not seem to make a difference.
Still no threads attached on ANR.
but im unsure it is correct how it is enabled?

@ItsReddi this config is not available on the manifest config.
you need to: https://docs.sentry.io/platforms/android/usage/advanced-usage/#manual-instrumentation
and do options.setAttachThreads(true)
I can confirm it works with setAttachThreads(true)
thanks, @ItsReddi we'll be looking into it, this flag should not have interfered in the ANR threads/stack traces if I am guessing it right.
you could use the setAttachThreads workaround for now :)
Allright, but it would now add the thread info to any Event, also Exceptions, custom errors if i understand the SentryOptions Docs correct?
Any way to enable that only for ANR?
true, this was enabled by default on sentry-android v2 anyway, so it's not really a problem to send all the threads info, the thing is, most of them are not useful for you to debug the issue.
unfortunately, it's not possible to enable only for ANR, this would be the bugfix, what you can do is, to use the beforeSend callback and filter them out based on the exception type (if not ANR).
just tested it out, https://github.com/getsentry/sentry-java/releases/tag/4.0.0-alpha.2 should give you stack traces of the main thread ootb, no need for setAttachThreads unless you want to see stack traces of all the running threads.
Thanks for reporting :)
Most helpful comment
thanks, @ItsReddi we'll be looking into it, this flag should not have interfered in the ANR threads/stack traces if I am guessing it right.
you could use the
setAttachThreadsworkaround for now :)