I'm curious about how Android can keep a TCP connection alive while I'm switching from 3G (mobile data) to WiFi and vice versa.
I'm asking this after I seen that I had an uninterrupted radio stream thought TuneIn radio.
Is that valid only for TuneIn (via some code workaround) or is it a cool feature in the Android API calls?
A TCP connection cannot be kept alive during a network change, since you get a new IP address, causing all connections being terminated.
TCP builds upon IP to get the data delivered. If you change networks you also change your public IP address which is used by the TCP connection to let TuneIn deliver data to you. This invalidates the current connection and forces you to establish a new one.
But there is still a chance of getting an uninterrupted audio stream. The TuneIn app most likely buffers the stream for two or three seconds to compensate for connection hiccups or even a reconnection.
One of the newest solutions to this problem is MPTCP (Multi-Path TCP) . But this one is also not yet widely supported (Apple's iOS7 supports Multipath TCP for its traffic generated by Siri).
MPTCP can stablish multiple sub TCP connections and if supported by devices on a connection, then The connection can be kept even if your IP changes (Wifi to 3G/4G and vice versa).
If you want to know more about MPTCP, read the following article: http://queue.acm.org/detail.cfm?id=2591369
While the answers given so far are true in current practice and certainly when switching between your mobile internet provider and home internet provider, both IPv4 and IPv6 do have mobility solutions, IPv4 by extension and IPv6 natively. They enable a mobile user to have a static home IP address and a dynamic mobile IP address which allows TCP connections to be maintained while moving from network to network. The details can be found in the RFCs below:
As far as the current deployment of these mobility solutions go, I am not aware of any, and I am not able to find anymore information. I would assume IPv4 mobility's solution is too cumbersome to deploy (it was an afterthought after all) and there aren't enough IPv4 addresses to go around as it is, let alone for mobile hence the heavy NAT utilization, so it won't ever be used. As for IPv6 and the reasons for its lack of widespread deployment is more difficult to speculate on, I would guess that with much of the web still on IPv4 and thus heavy use of IPv4 to IPv6 translation, the mobile solution could be tough to deploy in this environment. Regardless, even if a mobile provider did support the above, both your home and mobile provider would need some level of support, and home ISPs don't have any monetary incentive in this regard.
TL;DR TCP connections do break on your phone when changing networks (and thus network providers); however, there are mobility solutions that address this issue, but they haven't been deployed (at least not widely).
PS A better test of TCP connection breaking is a voice or video call (over data obviously). Music and movies can be buffered and the IP address transition is not noticed; however, calls cannot.
There's no way to keep a TCP connection alive if your IP address changes (and it will change when going from 3G to WiFi). You don't need uninterrupted connection for uninterrupted playback though - most "radio" apps prebuffer some data to keep the music playing even when you lose connection for a while.
