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).

[romtsn]

Since there was no activity for over 3 years from the OP, and no new reports, I'm gonna close this

[Lingviston]

As been mentioned in the linked OkHttp issue square/okhttp#3537, the issue is not really on OkHttp side. Users of OkHttp library are expected to set proper tags. Since Sentry is a user, Sentry should tag the calls it makes via OkHttp. And since Sentry is a library itself - Sentry should expose an API, which would allow its clients to tag Sentry network calls.

[romtsn]

@Lingviston opened #4340 to address, thanks for bumping this. You should be able to set you custom SocketTagger via options.setSocketTagger().

We don't use OkHttp directly, but it comes transitively through Android who swaps the implementation of HttpURLConnection with their repackaged version of OkHttp internally, so there's no easy way for us to get the actual Socket. However we also expose options.setSslSocketFactory() which can be used to provide a custom Socket implementation - hope this should be enough for any customization.

[Lingviston]

Would be nice to get a more specific API, as all I need is to add tag and keep everything else work the same. With a custom SSLSocketFactory I have to also think of overriding cipher suites methods, which I don't really know how to do properly.

[romtsn]

As mentioned, I'm not aware of a way to get the underlying socket besides reflection (which we're not going to pursue). If you know such a way please share with us and I will update the PR accordingly. Thanks!

[Lingviston]

No no, the solution in the linked issue is fine. Thanks