DefaultAndroidEventProcessor causes ANR

[bruno-garcia]

Came from a customer: https://getsentry.atlassian.net/browse/MOBILE-257

Only happens on some devices. Probably just some low end devices.

#00  pc 000000000007550c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
  #00  pc 00000000001af800  /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+148)
  #00  pc 0000000000669f3c  /apex/com.android.art/lib64/libart.so (art::GoToRunnable(art::Thread*)+460)
  #00  pc 0000000000669d2c  /apex/com.android.art/lib64/libart.so (art::JniMethodEnd(unsigned int, art::Thread*)+28)
  at android.os.BinderProxy.transactNative (Native method)
  at android.os.BinderProxy.transact (BinderProxy.java:568)
  at android.net.IConnectivityManager$Stub$Proxy.getActiveNetwork (IConnectivityManager.java:2435)
  at android.net.ConnectivityManager.getActiveNetwork (ConnectivityManager.java:1033)
  at io.sentry.android.core.internal.util.ConnectivityChecker.getConnectionType (ConnectivityChecker.java:101)
  at io.sentry.android.core.DefaultAndroidEventProcessor.setDeviceIO (DefaultAndroidEventProcessor.java:375)
  at io.sentry.android.core.DefaultAndroidEventProcessor.getDevice (DefaultAndroidEventProcessor.java:285)
  at io.sentry.android.core.DefaultAndroidEventProcessor.setDevice (DefaultAndroidEventProcessor.java:173)
  at io.sentry.android.core.DefaultAndroidEventProcessor.setCommons (DefaultAndroidEventProcessor.java:140)
  at io.sentry.android.core.DefaultAndroidEventProcessor.process (DefaultAndroidEventProcessor.java:130)
  at io.sentry.SentryClient.processEvent (SentryClient.java:206)
  at io.sentry.SentryClient.captureEvent (SentryClient.java:88)
  at io.sentry.Hub.captureEvent (Hub.java:89)
  at io.sentry.Sentry.captureEvent (Sentry.java:262)
  at io.sentry.HubAdapter.captureEvent (HubAdapter.java:29)
  at io.sentry.IHub.captureEvent (IHub.java:39)
  at io.sentry.IHub$-CC.$default$captureEvent (IHub.java)
  at io.sentry.HubAdapter.captureEvent (HubAdapter.java:29)

And:

#00  pc 0000000000086f8c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
  #00  pc 00000000001b27a4  /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+148)
  #00  pc 000000000067e9d0  /apex/com.android.art/lib64/libart.so (art::GoToRunnable(art::Thread*)+480)
  #00  pc 000000000067e7ac  /apex/com.android.art/lib64/libart.so (art::JniMethodEnd(unsigned int, art::Thread*)+28)
  at android.os.BinderProxy.transactNative (Native method)
  at android.os.BinderProxy.transact (BinderProxy.java:605)
  at android.app.IActivityManager$Stub$Proxy.registerReceiverWithFeature (IActivityManager.java:6380)
  at android.app.ContextImpl.registerReceiverInternal (ContextImpl.java:1696)
  at android.app.ContextImpl.registerReceiver (ContextImpl.java:1650)
  at android.app.ContextImpl.registerReceiver (ContextImpl.java:1638)
  at android.content.ContextWrapper.registerReceiver (ContextWrapper.java:686)
  at io.sentry.android.core.DefaultAndroidEventProcessor.getBatteryIntent (DefaultAndroidEventProcessor.java:434)
  at io.sentry.android.core.DefaultAndroidEventProcessor.setDeviceIO (DefaultAndroidEventProcessor.java:326)
  at io.sentry.android.core.DefaultAndroidEventProcessor.getDevice (DefaultAndroidEventProcessor.java:285)
  at io.sentry.android.core.DefaultAndroidEventProcessor.setDevice (DefaultAndroidEventProcessor.java:173)
  at io.sentry.android.core.DefaultAndroidEventProcessor.setCommons (DefaultAndroidEventProcessor.java:140)
  at io.sentry.android.core.DefaultAndroidEventProcessor.process (DefaultAndroidEventProcessor.java:130)
  at io.sentry.SentryClient.processEvent (SentryClient.java:206)
  at io.sentry.SentryClient.captureEvent (SentryClient.java:88)
  at io.sentry.Hub.captureEvent (Hub.java:89)
  at io.sentry.Sentry.captureEvent (Sentry.java:262)
  at io.sentry.HubAdapter.captureEvent (HubAdapter.java:29)

Problem seems to be that we call some APIs that can be rather slow.
Potentially we could gracefully degrade by detecting if the device is low end. Or disabling the known possibly slow APIs to become opt-in.

[marandaneto]

It's not slow, it's in a deadlock state.

Similar issues https://issuetracker.google.com/issues/230950647
https://issuetracker.google.com/issues/218444754
https://issuetracker.google.com/issues/204481907
https://stackoverflow.com/questions/60867936/app-process-blocked-at-artconditionvariablewaitholdinglocks-how-to-find-the

I could not find a way to avoid the deadlock since we don't know if we should skip it or not the IPC APIs.

[bruno-garcia]

Resolved on 6.1.1 and troubleshooting page added: getsentry/sentry-docs#5170

It's not slow, it's in a deadlock state.

Should we opt-in to that by default?

[marandaneto]

Resolved on 6.1.1 and troubleshooting page added: getsentry/sentry-docs#5170

It's not slow, it's in a deadlock state.

Should we opt-in to that by default?

I don't think so, this is an edge case and we've not gotten from anyone else so far.