Failed host lookup: 'www.xyz.com' (OS Error: No address associated with hostname, errno = 7)

[gbfarah]

We are getting this issue on Android device even though it is connected to internet and the server is up....

when calling several times over a 5 min period the above error is encountered

var channel = IOWebSocketChannel.connect(Uri.parse(url), connectTimeout: const Duration(seconds: 3));

What is strange is that on the same device and the same time when opening the URL in chrome there are no issues

Anyone else getting this issue

[kemalinnowise]

I got the same issue, any updates ?
In my case I imitate situation when user might lost connection. After connection is coming back I got similar error and cannot connect till I close app and open again

[natebosch]

This issue is not actionable in this repository. Questions about using networking in flutter are better answered by the flutter team, or in places like stack overflow.

If you do think there is a bug in this library (for examplesome bad behavior happens when you use this package, but not when you use WebSocket from dart:io) please file an issue with a complete reproduction case.

[quetool]

Hello @natebosch.

On every issue opened on Flutter repo related to this very problem a team member closed it by replying that "the issue should be opened on Dart-lang repository". Like here, here, here and many other places that I already lost track of it

However, here on Dart-lang repository you are telling us that we should look at this issue on Flutter repo...

Some of our users discovered that this is happening only on Android 15 devices and, after that, I found out that this is caused by Android's "doze" mechanism, so I am here asking if this could be even an issue or not, and, if not, what could possible be a solution to it.

Basically if I set my app on Unrestricted mode then my WebSocket remains opened, for a really long time. But 5 seconds (almost precisely I would say) after switching to Optimized mode then the WebSocket is getting closed to never reconnect anymore.

This is happening ONLY with Android 15 devices, I myself tested it only on an Emulator but I have several users reporting it on their own physical devices. See here: reown-com/reown_flutter#23

I do have an physical Android 14 device and this is not happening, even if I set my sample app on Optimized mode.

I would like some clarity/help here. I was thinking about implementing a wake lock but honestly we need the web socket to remain opened as much as possible.

[gbfarah]

@quetool I also found that this issue seems rather related. #1642

We ended up implemented an app layer keepalive (very inefficient to say the least)

[quetool]

This might be a bit different although the behaviors looks pretty similar. But in our case, this is happening only with Android 15 devices, which was released earlier this year, so I'm a bit lost. We are still investigating but I wanted some clarification from the dart team in the mean time

[quetool]

Should I open a new issue @natebosch ?

[natebosch]

tl;dr; - I recommend trying https://pub.dev/documentation/cupertino_http/latest/cupertino_http/CupertinoWebSocket-class.html first to see if it fixes the problem

Should I open a new issue @natebosch ?

The most effective way to get closer to finding a root cause for the error is building a minimal reproduction case using the APIs from dart:io (https://api.dart.dev/dart-io/WebSocket/connect.html) to narrow down whether this is a problem stemming from the SDK implementation, or from this package (web_socket_channel), or in package:web_socket. This type of error very rarely has a root cause in the higher level wrapping packages.

Finding the root cause does not guarantee we'll be able to fix the root cause. Potential outcomes of the SDK issue and minimal reproduction include: an upstream fix in the SDK, a workaround or fix we can implement in web_socket or web_socket_channel, or a workaround or fix that we can recommend to flutter authors.

One very likely workaround if we cannot find a way to avoid this at a lower level is to use the platform HTTP libraries. For android that means using https://pub.dev/documentation/cupertino_http/latest/cupertino_http/CupertinoWebSocket-class.html

@brianquinlan might have more advice, but I would start by trying the platform specific websocket implementation packages because they have the best chance at integrating nicely with platform behaviors like sleep/wake

[quetool]

Wait, why are you suggesting to use CupertinoWebSocket class, which uses an Objective-C API (NSURLSessionWebSocketTask) to fix an Android issue? Am I missing something? 🤔

[natebosch]

Oh that's right, Cupertino is IOs. I don't see a cronet_web_socket package. @brianquinlan do you know if we have one planned?

[quetool]

Thanks, I got confused for a bit 😅
Anyway, while we wait for @brianquinlan reply I will try to put up a simple reproducible project in the coming days but it feels to me that this is not a bug in any place but rather that we should all adapt to this new strict doze policy introduced with Android 15 (unless there is/will be an API to handle this)

I already fixed it by implementing a reconnection mechanism on our side but I still do consider that only ~5 seconds to keep alive the app in the background is really strict.

Fun fact: I also fixed it by implementing a foreground service that would keep alive the app for 3 minutes using shortService type, which, if you ask me, is ridiculous that I can bypass a strict Android policy by leveraging an Android API 😅

[brianquinlan]

Oh that's right, Cupertino is IOs. I don't see a cronet_web_socket package. @brianquinlan do you know if we have one planned?

Cronet does not support WebSockets.

package:ok_http supports OkHttpWebSocket, which can be adapted into a WebSocketChannel using AdapterWebSocketChannel.