I noticed a bunch of log lines like this throughout Logcat as I used my app:
19098-19147/<package> W/OkHttpClient: A connection to <my server> was leaked. Did you forget to close a response body?
I eventually narrowed it down to a single SimpleDraweeView that was causing it when I tried to set its image URI.
Using imagepipeline-okhttp3, I added an OkHTTP client and interceptor so I could inspect what was going on with the HTTP request/response. It turns out that the response was not 200, rather a 401 error. This prevented the image from loading as expected and also led to the above log lines.
I was able to fix this particular 401 error by using an interceptor to add the necessary authentication headers I was missing. However, I was wondering If there are different HTTP errors in the future, is there a general way to catch errors in such a way that it doesn't leak a connection?
Set an image URI on a SimpleDraweeView that results in a 401 HTTP error code response.
Thank you for the report! We don't use OkHttp internally so this is fairly low priority for us. Feel free to send a pull request though!
@foghina Can you explain to me how Fresco was using OkHttp even before I included the imagepipeline-okhttp3 dependency? I was receiving the log line above when using the default settings for Fresco (not using the OkHttp image pipeline config). I even went through my build.gradle file and made sure to explicitly exclude OkHttp as a transitive dependency on all other dependencies. I then ran gradle app:dependencies and inspected the dependency tree to make sure that OkHttp was not part of it. I still somehow got the log line complaining about a leak OkHttp connection when Fresco loaded the problem image. Is OkHttp used internally by the Android system? I don't see how else it could have been in the logs if I wasn't including it as a dependency and neither was Fresco. I would assume that if OkHttp was not included as a dependency or explicitly set in the Fresco config, internally, Fresco would just use the Apache HTTP client or HttpURLConnection, which is built into Android itself, instead.
Oh, here is a tweet from Jake Wharton himself saying that OkHttp is in fact part of the system as of Android v4.4: https://twitter.com/JakeWharton/status/482563299511250944
I guess that is how HttpUrlConnection is implemented.
Oh, sweet. I had no idea 馃槄
Most helpful comment
Oh, here is a tweet from Jake Wharton himself saying that OkHttp is in fact part of the system as of Android v4.4: https://twitter.com/JakeWharton/status/482563299511250944
I guess that is how HttpUrlConnection is implemented.