In our Android app we have a VideoCall feature.
We use 'webRTC' library + i see a 'io.socket:socket.io-client' dependecy. We have a class 'RtcWrap' (instantiated by DI as a singleton) - this holds the RTCSocket instance + a bunch a socketing & callbacks stuff.
In a specific screen, where we are already in a RTC session (so WebSocket-ing part initiated), we have the feature of receiving messages. If app is in foreground - we show a view with the message, if app is in background we show a notification.
On Android <13 implementation works, even if you put app in background. On Android 13,14 if we put app in background, after ~20s, connection is lost = WebSocket is closed (and error callback will be thrown)
I did small experiment (but with normal sockets): a mini server with a ServerSocket & a client Android app that opens a Socket & both will send messages & print whatever they receive. I can confirm the following behaviour, if you put app in background: on Android <13, connection is kept, while on Android 13 & 14 - connection is closed after some ~20s. (if it helps, i used compileSdk 34, targetSdk 33 + normal sockets: java.net.Socket & java.net.ServerSocket)
For original problem (that was with WebSockets), my "pseudo fix" is to create a foreground Service + ongoing notification.. and basically pass there the 'RtcWrap' instance.
Issue is gone, but I don't like it.. What approaches do you suggest?
Also, how does Android know - that my "socket-ing" is done from a random object held in memory (in my case in the DI graph) or from an object held by a foreground service?