The code does not work: why the two phones will not pair

"It says invalid code" covers several unrelated failures. The first two are by far the most common and neither is a network problem, which is why people spend twenty minutes on the wrong thing.

First: which phone is showing the code?

This is the cause more often than everything else combined, and it is a wording problem rather than a technical one. In any pairing flow one device shares and the other connects. The code belongs to the sharing device, and it has to be typed on the connecting one.

People routinely read the code off their own phone and type it into their own phone, or ask the other person for a code the other person has not generated. If you are getting "invalid code" instantly, before any spinner, confirm out loud: whose screen is the code on, and which phone are you typing it into?

Second: is the code still alive?

Session codes are normally short-lived and tied to a live session, not to the device. Closing the app, backgrounding it for a while, or the phone going to sleep can end the session — and the code then refers to something that no longer exists.

• If the sharing phone's screen went off while you were reading the code out, ask them to wake it and read the code again. It may have changed.
• If they pressed back or switched apps, the session probably ended. Have them start it again.
• A code that worked five minutes ago and does not now is almost always this, not a network fault.

Third: the sharing phone stopped running the app

Android is aggressive about background apps, and some manufacturers are far more aggressive than stock Android. If the sharing app is closed by the system, the session dies silently and the other side sees a code that no longer resolves.

The signature: it worked, then stopped after a minute or two of the phone being idle, with no error on either side. This is a battery-optimisation problem rather than a networking one — see why the app keeps getting killed.

Fourth: the network

Only now is it worth suspecting the connection. Two tests separate this from everything above:

1. Switch one phone to mobile data and try again. If it connects on data but not on the Wi-Fi, the network is blocking something — guest, hotel, university and corporate Wi-Fi commonly block client-to-client traffic and restrict outbound ports.
2. Try a different pair of devices. If a third phone can connect to the same sharing phone, the sharing side is fine.
3. Note whether it connects and then drops, rather than never connecting. Repeated drops after a successful connection are packet loss or a sleeping phone, not pairing.

Behind this: neither phone has a public address, so both connect outward to a signalling server and then try to negotiate a direct path. That usually works. When it cannot — symmetric NAT, carrier-grade NAT on mobile, a firewall that only permits TCP on 443 — traffic has to be relayed through a server instead, which always works but adds latency.

The order, condensed

More guides