Initializing Sentry triggers a StrictMode violation

[mshafrir-stripe]

Platform:

• Android -> API 23 & 29 emulator,compileSdkVersion/targetSdkVersion are set to 30
• Java -> If yes, which Java (and sourceCompatibility/targetCompatibility) version?
• Kotlin -> If yes, which Kotlin (and jvmTarget) version?
• NDK -> If yes, which NDK/CMake version?
• React-Native -> If yes, which version?

IDE:

• Android Studio -> 4.0
• IntelliJ -> If yes, which version?
• Other -> If yes, which one?

Build system:

• Gradle -> 6.5.1
• Buck -> If yes, which version?
• Bazel -> If yes, which version?
• Other -> If yes, which one?

Android Gradle Plugin:

• Yes -> 4.0.0
• No

Sentry Android Gradle Plugin:

• Yes -> 1.7.35
• No

Proguard/R8:

• Enabled
• Disabled

sentry-android installed with:

• JCenter
• Bintray
• Maven Central
• Manually

The version of sentry-android:
2.2.0

---

I have the following issue:

Initializing Sentry triggers a StrictMode violation

Steps to reproduce:

• Enable StrictMode logging in Application subclass

   StrictMode.setThreadPolicy(
       StrictMode.ThreadPolicy.Builder()
           .detectAll()
           .penaltyLog()
           .build()
   )
   StrictMode.setVmPolicy(
       StrictMode.VmPolicy.Builder()
           .detectAll()
           .penaltyLog()
           .build()
   )
  

• Initialize Sentry automatically
• Run adb logcat -s StrictMode
• Launch application

Actual result:

07-07 11:23:32.694 16309 16317 E StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
07-07 11:23:32.694 16309 16317 E StrictMode: java.lang.Throwable: Explicit termination method 'end' not called
07-07 11:23:32.694 16309 16317 E StrictMode: 	at dalvik.system.CloseGuard.open(CloseGuard.java:180)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at java.util.zip.Inflater.<init>(Inflater.java:82)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.okio.GzipSource.<init>(GzipSource.java:62)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.http.HttpEngine.unzip(HttpEngine.java:645)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:827)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:439)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:384)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getHeaders(HttpURLConnectionImpl.java:150)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getHeaderField(HttpURLConnectionImpl.java:194)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getHeaderField(DelegatingHttpsURLConnection.java:190)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getHeaderField(HttpsURLConnectionImpl.java)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at io.sentry.core.transport.HttpTransport.updateRetryAfterLimits(HttpTransport.java:362)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at io.sentry.core.transport.HttpTransport.send(HttpTransport.java:298)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at io.sentry.core.transport.AsyncConnection$SessionSender.flush(AsyncConnection.java:373)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at io.sentry.core.transport.AsyncConnection$SessionSender.run(AsyncConnection.java:341)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at java.util.concurrent.FutureTask.run(FutureTask.java:237)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
07-07 11:23:32.694 16309 16317 E StrictMode: 	at java.lang.Thread.run(Thread.java:818)

Expected result:

• No StrictMode violation

[marandaneto]

hey @mshafrir-stripe thanks for raising this.

after the method updateRetryAfterLimits, the method closeAndDisconnect is called.

Explicit termination method 'end' not called

similar issue on OkHttp repo square/okhttp#24
not sure which OkHttp version the Android OS has builtin, maybe it's before this fix? I
I'll take a look at it.

[marandaneto]

@mshafrir-stripe I can't reproduce it using API 23 and 29, do you get this on every run?

looking at the Android CS:

https://cs.android.com/android/platform/superproject/+/master:external/okhttp/repackaged/okhttp-urlconnection/src/main/java/com/android/okhttp/internal/huc/HttpURLConnectionImpl.java;drc=83f1f55b26800dfa1e5472dd5a42f598f4e3c224;l=135

there's even a comment about that, but we use GZIPOutputStream which implements Closeable and we open it using a try-why-resources, so not sure what's happening, could you describe which emulator image are you testing it?

Could you use compileSdkVersion=29 just to try to isolate the problem? thanks

[mshafrir-stripe]

@marandaneto I'm still getting this with compileSdkVersion=29

[marandaneto]

@mshafrir-stripe do you use Sentry on-premise or Sentry.io? as you have the release health feature enabled, if it's the on-premise, you'd need to be using the latest version, and this could be the way to reproduce the issue properly.

[marandaneto]

I've tried using the same emulator and can't really reproduce it (using our sample in this repo).

would you mind setting up a sample project that showcases this? or even just clone and try our sample in this repo and see if you get it.

I only experience:

StrictMode policy violation; android.os.strictmode.DiskReadViolation

which is related to creating the caching folders

StrictMode policy violation: android.os.strictmode.UntaggedSocketViolation: Untagged socket detected; use TrafficStats.setThreadSocketTag() to track all network usage

an OkHttp issue, but only a warning: square/okhttp#3537

[marandaneto]

hey @mshafrir-stripe did you have the time to set a sample project? I could not really reproduce it, otherwise only left me to close the issue, thanks :)

[yangcheng]

I have the same issue. just need call to set tag.

[marandaneto]

We're going to evaluate again which violations the SDK does and if it's possible to avoid them.
Some of them are avoidable but not all, e.g. Creating the folders for offline caching or the OkHttp one.
We could consider adding a CI check to identify that on PRs (that could be a follow-up).