Variety of HTTPs errors while communicating to server from Android App Variety of HTTPs errors while communicating to server from Android App nginx nginx

Variety of HTTPs errors while communicating to server from Android App


I recently had to do an exhaustive analysis of my company's app as we were seeing a bunch of similar errors and didn't know why. We ended up handing out custom apps that literally logged their connection times, errors, signal quality, etc to a file. Did that for weeks. Collect thousands of data points. Keep in mind, we maintain a persistent connection while the app is open.

Turns out most of our errors were from switching networks. This is actually really common for an average user. So lets say a user is using an EDGE cell network, then walks within WIFI range or vice versa. When this occurs, Android literally severs the cell connection and makes an entirely new connection to the WIFI. From the apps perspective, it's similar to turning on airplane mode then flicking it back off again. This even occurs when switching within a cell networks. Eg, LTE to HSPA+. Each time this happens, Android will fire off the network connective changed broadcast.

Of those you listed, this behavior was causing the following similar errors:

  • javax.net.ssl.SSLException: Write error: ssl=0x5e4f4640
  • javax.net.ssl.SSLException: SSL handshake aborted:

Sometimes the network switch was fast, sometimes slow. Turns out, we were not cleaning up our resources in time with the fast switches. As a result we were attempting to re-connect to our servers with stale/old TCP connections that threw even more odd errors.

So I guess the take away is, if you are maintaining a connection for a long period of time, expect to see the phone constantly switch between networks, especially when the signal is weak. When that network switch occurs, you'll see SSLExeptions and it's completely normal. Just gotta make sure you clean up your resources and reconnect properly.


Since you are dealing with what looks like poor network connectivity, consider a more fault-tolerant HTTP client. The one I like is OkHTTP. From their description:

OkHttp perseveres when the network is troublesome: it will silently recover from common connection problems. If your service has multiple IP addresses OkHttp will attempt alternate addresses if the first connect fails. This is necessary for IPv4+IPv6 and for services hosted in redundant data centers. OkHttp initiates new connections with modern TLS features (SNI, ALPN), and falls back to SSLv3 if the handshake fails.

The implementation would be mostly a drop-in replacement.