Host or join RetroArch netplay on Android without desync
Use the same RetroArch generation, exact core build, and legally obtained matching content on every device. The host should set a nickname, start hosting, load the content, and use a relay when direct TCP reachability is uncertain. The client should refresh the lobby or enter the host directly, then stop at the first mismatch or serialization warning instead of changing latency settings at random.
Do this in order
- 01
On both Android devices, record the RetroArch version, exact core name and version, content identity, and controller port plan; use only content each player is authorized to possess.
- 02
Set a nickname under Settings → User, then confirm the same content boots locally on both devices before enabling netplay.
- 03
On the host, open the Netplay menu, set a password or disable public announcement for a private room, select Start Hosting, and then load the tested content.
- 04
Prefer a relay server when router control, UPnP success, carrier-grade NAT, or direct TCP reachability is uncertain; use direct hosting only when the listening port is actually reachable.
- 05
On the client, refresh the room list and select the host, or enter the host address for an unlisted private room; load the exact core and content manually if automatic matching fails.
- 06
If connection, desync, or spectator behavior fails, compare core/content identity and serialization support first, capture the first netplay log message, and change only one network setting before retesting.
Decision and diagnostic table
| Symptom | Most useful first check | Do not assume |
|---|---|---|
| Room is listed but connection fails | Direct TCP reachability or relay selection | Lobby visibility proves the host port is open |
| Content/core mismatch | Exact core build and content identity on both devices | A matching filename means matching bytes |
| Session connects then desyncs | Core determinism, serialization, and version parity | More latency frames repair an incompatible core |
| Game expects a link cable | Libretro core-specific netplay support | RetroArch replay netplay emulates every hardware link |
The room list is discovery, not a reachability test
Libretro documents that RetroArch may ask the gateway to forward TCP port 55435 through UPnP, but it does not confirm that the result is reachable. A room can therefore appear in the lobby while direct inbound traffic still fails.
A relay keeps both peers behind outbound connections and is the practical first choice on mobile networks, managed Wi-Fi, or routers you cannot configure. It adds a path through a proxy, so record whether the successful test used direct or relay mode.
Synchronization starts with identical inputs
RetroArch netplay replays input while the core advances a shared frame sequence. Libretro's contract requires a deterministic core plus identical core and content on host and client. A playlist title, archive name, or thumbnail is not identity evidence.
Record the displayed core version and a checksum from each player's lawful local copy. If the core cannot serialize state, netplay may be limited or unstable; no router change can add missing core behavior.
Separate netplay from hardware-link emulation
RetroArch netplay connects players to one emulated session. Libretro explicitly distinguishes it from emulating a handheld link cable, with only core-specific exceptions.
Confirm the target core's own documentation before promising a multiplayer mode. Test local two-player input first so a wrong port assignment is not misreported as a network fault.
Netplay does not grant a second player the right to download a commercial ROM, BIOS, CHD, artwork, or soundtrack. Every participant must use an independently lawful copy; do not send content through chat, room descriptions, cloud links, or ArcadeShelf.