-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android O StrictMode: Untagged socket detected #3537
Comments
It used to be supported and was removed. I looked at adding it back a few months ago, but it's weird because of HTTP/2. The easiest thing to do is probably tag them with a random int that we declare as being OkHttp and not bothering to differentiate per-request. |
I’m looking deeper into this. There’s a bunch of things that makes fixing this unsatisfying. The way socket tagging works on Android is as follows:
This doesn’t map neatly to the HTTP protocol, or to OkHttp’s design. In particular:
We could just blast a tag like I’m going to icebox this because all of the fixes I can imagine add considerable code and don’t provide additional value to the TrafficStats aggregate. |
Suppose a dev team sets |
If you don't need a SOCKS proxy configured, is this a suitable workaround for now? n.b. DelegatingSocketFactory is a test class, but you get the idea.
|
Is there any update or workaround on this? |
See above
…On Mon, Sep 25, 2017, 10:34 PM Wooram ***@***.***> wrote:
Is there any update or workaround on this?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3537 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEawQBXQCdXRYEDiCcKlHt7BLV8RHks5smGLSgaJpZM4O_9Zh>
.
|
i am facing same issue please help |
Hi @swankjesse , |
The current policy which I don't think you will like is if you want to enable strict mode, you should also apply the workaround I posted above. There isn't a clean way to do this for library code like OkHttp given HTTP/2, and no current plans to implement tagging with an arbitrary number. Worth keeping this open as 13 +1 suggests it's a popular topic. |
Implement okhttp fix for Android >= Oreo, when all outgoing sockets have to be tagged See square/okhttp#3537
The proposed workaround does not work for me. StrictMode now complains from the
Setting an arbitrary tag through the |
I have tried @yschimke solution but it still gives me same error |
As suggested in the warning message, I've applied |
Whether the latest version has fixed this problem? |
@zhangchaojiong No, you should use a workaround see comment by @azizbekian. See @swankjesse comment above for why we don't have a clean automatic solution for OkHttp. |
How I can set it up for picasso? |
I took a look at this again, even looking at Android specific code and a SocketFactory that sets the thread tag. But that implementation isn't called if we hit a proxy. Then the connect call might happen without that invocation. So best workaround is problem implementing this in an EventListener.connectStart, if you are really keen this happens. Closing for now as won't fix in OkHttp. |
I am also facing same issuse so should I just add a tag and it will be resolved? |
To be clear, OKHttp doesn't spontaneously issue HTTP requests and cannot know what is the content it transports. The tagging should be done by the caller with |
If I use a 3rd party sdk that doesn't add the tag themself, is there a way to provide a "default tag strategy" to OkHttp so I don't need to wait on all 3rd party sdk to fix their tag themself ? |
@damienmabin not as far as I know. |
Firebase Crashlytics is affected by this issue... Is the only way removing |
If you can't change their socket factory, then removing detectUntaggedSockets() is the only option. Assuming no proxies involved, they could add this into the SDK, but I'm not sure they have the motivation. |
closes #164 context square/okhttp#3537
If we use StrictMode with VmPolicy detectAll() in Android O (Preview 6) we get errors in logcat like this:
From what I can tell, this happens because the sockets are untagged - is that something okhttp might want to support?
The text was updated successfully, but these errors were encountered: