I've got a temporary work around, which I can use for now. The exception above is thrown when I run the emulator as a Pixel 3 Android 9.+ Target (Q API). I made up a second emulated device, a Pixel 2 Android 9.0 Target (28 API), and this target works fine.
I'm also noticing that the Pixel 2 target takes up 8.5GB on Disk, while the Pixel 3 target only takes up 1.4GB. It makes me wonder if the Pixel 3 target is missing some important things.
I'm having it on one machine (Mac OS Mojave) even when connecting physical iOS devices. Of course it happens too with emulated Android devices (no matter which one).
I've also having this problem in a different computer (MacOS Mojave too) with a physical Android device (with a very old Android version: 5.1).
flutter clean does not fix it at all in my case(s).
I've faced the same problem. Actually the problem was in the native code.
You can track the problem for android if you open an your_app/android project from Android Studio and run it, the same for iOS -> open ios project in XCode
So after I've fixed it the app run as intended
I found the solution/work around. For me, it worked on physical device but not on emulator. The simple fix is to use your an emulator of x86 environment rather than x86_64 emulator.
In my case (error "HttpException: Connection closed before full header was received") the call was to an https address using Microsoft Internet Information Services as backend, in the SSL settings of the website in IIS i had mistakenly set "Client certificates: Accept" instead of "Client certificates: Ignore", setting "Ignore" solved the problem.
CAUSE
I was using cached_network_image, When users uploaded heavy photos > 2MB, cache ran out of memory then app crashes. No warning.
SOLUTION
Use FadeInImage.memoryNetwork() or something else like NetworkImage() but not cache_network_image, it only works for less than 2 MB photos
thanks :)
You also need to mention your listening port which you define in your file like this
final WebSocketChannel channel =
IOWebSocketChannel.connect('wss://check.com:6043/');
I'm using Dio and faced the same issue so I have made this workaround by creating this interceptor which can be implemented too using the http interceptors.
If you have your own http server running, make sure the Keep-Alive timeout config is set to >=15 seconds. If you don't have access to the http server, try lowering the HttpClient's idleTimeout to 5 seconds.