StrictMode policy violation when closing Connection

[ninniuz]

Describe the bug
After enabling closable objects detection with

StrictMode.setVmPolicy(
    StrictMode.VmPolicy.Builder()
        .detectLeakedClosableObjects()
        .penaltyLog()
        .build()
)

in my application, I can see strict mode violations coming from Segment

StrictMode policy violation: android.os.strictmode.LeakedClosableViolation: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
	at android.os.StrictMode$AndroidCloseGuardReporter.report(StrictMode.java:1987)
	at dalvik.system.CloseGuard.warnIfOpen(CloseGuard.java:336)
	at java.util.zip.Inflater.finalize(Inflater.java:407)
	at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:339)
	at java.lang.Daemons$FinalizerDaemon.processReference(Daemons.java:324)
	at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:300)
	at java.lang.Daemons$Daemon.run(Daemons.java:145)
	at java.lang.Thread.run(Thread.java:1012)
Caused by: java.lang.Throwable: Explicit termination method 'end' not called
	at dalvik.system.CloseGuard.openWithCallSite(CloseGuard.java:288)
	at dalvik.system.CloseGuard.open(CloseGuard.java:257)
	at java.util.zip.Inflater.<init>(Inflater.java:122)
	at com.android.okhttp.okio.GzipSource.<init>(GzipSource.java:64)
	at com.android.okhttp.internal.http.HttpEngine.unzip(HttpEngine.java:484)
	at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:661)
	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:475)
	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:411)
	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:542)
	at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:106)
	at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:30)
	at com.segment.analytics.kotlin.core.HTTPClientKt$createPostConnection$1.close(HTTPClient.kt:93)
	at com.segment.analytics.kotlin.core.platform.EventPipeline$upload$1.invokeSuspend(EventPipeline.kt:149)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
	at java.lang.Thread.run(Thread.java:1012)

To Reproduce
Steps to reproduce the behavior:

1. Enable detectLeakedClosableObjects
2. Track an event an wait for it to be sent
3. Check logcat

Expected behavior
Resources should be closed correctly.

Platform:

• Library Version in use: 1.13.4
• Platform being tested: Android
• Integrations in use: none

[wenxi-zeng]

hey @ninniuz thanks for reporting this issue. we're investigating it.

[wenxi-zeng]

@ninniuz we tried the setup you suggested, but was not able to observe the issue. are you using okhttp via a custom RequestFactory? I saw the exception is raised from okhttp, but our default implementation uses java.net. if you are using okhttp, try bump it up to the latest version. this issue should be fixed by okhttp already (see their pr here)

[ninniuz]

@wenxi-zeng thanks for your response!
We use a custom RequestFactory that simply sanitize our apiHost URL, nothing more than that.

com.android.okhttp.internal.huc.HttpURLConnectionImpl is the Android implementation for java.net.HttpURLConnection starting from Android 4.4, so it does not depend on our usage of OkHttp in our app.

I am getting this violation log on an emulator.

[wenxi-zeng]

@ninniuz thanks for the additional information. unfortunately, we can't do anything to address it. it depends on the underlaying library HttpURLConnection. all we can do in our library is to make sure we always close the connection after using it. in your case, connection.responseCode opens the connection, and we have a finally block that makes sure the connection gets closed (see this line). and the finally block calls this line, which calls disconnect to close the resource. if the concrete HttpURLConnection does not implement the disconnect function properly, you will get that error.
if that is a concern, i'd suggest you to use your own HttpURLConnection implementation with the requestFactory to get it addressed.