Connect to Android App's Socket from Internet: Possible?

Question

I am trying to develop an Android (server) app that will accept TCP connections directly from the Internet. I tried this a couple of years ago with no joy. Is this even possible?

I asked this question differently way back then, on StackOverflow and elsewhere, and never got a satisfactory answer. The answers fell into two categories:

• No, you can't
  Most authoritative answer given: Most carriers won't route connection requests to mobile devices.

• Yes, you can
  These answers did not provide details or examples to help me.

What I Tried

• I can successfully get my mobile device's external IP through various means. But this is only part of the puzzle. See Note 1 below.

• I created a ServerSocket that listened on a port (e.g., 2000). But the app would not accept connections from the Internet on this socket. Apparently, this socket was listening on the local (internal) network of the device (i.e., 192.168.1.0).

• I was able to connect from other apps on the device (which are on the same subnet).

• I was also able to connect through a NAT router in my shop that translated Internet addresses to my device's local net. But this doesn't help me in the field (where no router is available). See Note 2 below.

• I tried asking AT&T customer-support-type people but I don't think they understood my question.

Notes:

• 1. Yes, the device's IP address can vary with time or location, but I can always get the correct and current IP through various means (e,g., whatmyip.com, etc.). Nontheless using the current device IP doesn't work either. BTW - my public IP has never changed. Thus, for all intents and purposes, my IP is static. In any case, the IP issue is a well-flogged horse, I am fairly sure that this is a ROUTING issue, not an IP address issue.
• 2. I can connect via WiFi because my Internet modem/router offers DHCP connections on the back side via Wifi on the device's local subnet (192.168.1.). My device has address 192.168.1.65, therefore I can connect to it without ever going through my carrier.
• 3. AT&T tells me that I cannot buy a static IP for a mobile device (update 9/23/19).

My Current Theory (9/23/19)

It is my current humble belief that there is a NAT-like entity at play here. Either:

• The public IP actually points to a NAT router at AT&T HQ.
• The device has a built-in NAT-like router

In either case, under this theory, inbound TCP connections are not forwarded to the device's local net, but outbound connections pass through just fine.

Summary

Maybe the answer's still the same, but I thought I'd ask again in case things have changed or somebody's got some better insight nowadays,

Answer 1

(UPDATED 9/26/19)

I am posting this "answer" not so much as an answer per se but rather to solicit constructive criticism and/or affirmation. Any statements I make below should definitely be implicitly prefixed by "I humbly believe that...".

Yesterday, I had a personal epiphany. I finally got it through my thick skull what some responders were saying. I present my new understanding below.

Heretofore I believed that AT&T's Mobile Data Network was just a direct extension to the Internet implemented with cell sites and trunk lines. Now I realize that it is a closed, private data transport mechanism. Since it is owned by AT&T, they can implement whatever protocols they choose to, including "private" data connections from their head-end to my registered phone. These connections are analogous to the LAN-side ports on a typical desktop NAT router. The head-end (i.e., their NAT router) is the only entity that can be accessed from the Internet.

The head-end connections between the Internet and my phone are over these AT&T-private connections. The "public IP" reported for my device (and, I believe, nearby devices) actually points to the AT&T head-end, in my case a 150 miles away in Miami). The head-end fowards outbound connections from my phone to the Internet, but does not forward inbound connection request.

About my "Public IP"

I believe that this doesn't exist and is, in fact, a meaningless concept. What would be the point of such an address if you cannot connect to it.

Summary

I now believe that the answer to my original question is "No way, Jose". This is not due to an addressing issue, but rather AT&T will not route incoming connections to devices. They also do not offer static IPs for devices over their private network (this wouldn't make much sense anyway given the above).

IF ANY STATEMENTS IN THIS PROTO-ANSWER ARE INCORRECT, PLEASE PLEASE LET ME KNOW WHICH ONE AND WHY IT IS INCORRECT

Answer 2

It's true that you can't establish any TCP or UDP connection which is listening behind the main network (i.e. behind the NAT). Nowadays all the ISP allocate a private IP to every device (due to shortage of IP) connected to it hence creating a private network of devices behind NAT. (After the complete adoption of IPv6 the situation will change with every device becoming the part of main network)

Since NAT doesn't allow an inbound connection, the problem is solved using some of the NAT traversal technique such as:

• Port forwarding
• TCP/UDP Hole punching

In the Port forwarding process, we need to deal with the router setting which will forward the connection on a specific port to the same port on the internal network node. It is mainly used in gaming, VoIP, and p2p application.

In Hole punching technique (no need to deal with the router setting) we use an external server which is not behind any NAT to get the IP address (both public and private) of the devices which are behind NAT. Further, the two hosts create there own outbound session among each other in their respective NAT devices. Since the NAT devices allow the outbound session, the session is stored, and this same session is used for further two-way communication. More information about Hole punching.