Fix a RetroArch controller assigned to the wrong player on Android
Connect controllers in a known order, then assign each physical pad under Settings → Input → RetroPad Binds → Port Controls using Device Index. If the assignments change after reconnecting, use RetroArch's device reservation options where the build exposes them. Finally confirm the loaded core's port Device Type, because a correct frontend assignment can still point to an inactive emulated port.
Do this in order
- 01
Close content, disconnect all pads, reconnect only the intended player-one controller, and verify Android sees its input.
- 02
Open Settings → Input → RetroPad Binds → Port 1 Controls and select that physical pad under Device Index.
- 03
Connect the second pad, assign it under Port 2 Controls, and verify neither port points to the same unintended device.
- 04
If the build exposes device reservation, reserve each identified controller to its intended player and save the frontend configuration.
- 05
Load authorized multiplayer content, open Quick Menu → Controls, and confirm each port's core Device Type is enabled and appropriate.
- 06
Restart with both pads connected, repeat a one-button-per-player test, and record any USB/Bluetooth order that the Android device cannot stabilize.
Decision and diagnostic table
| Observation | Likely layer | Next check |
|---|---|---|
| Pad controls RetroArch but not player one | Port Device Index | Assign the pad explicitly to Port 1 |
| Players swap after reconnect | Android enumeration or missing reservation | Use reservation or a fixed connect order |
| Both ports name the right pads but one game ignores player two | Core device type or game support | Inspect Quick Menu → Controls for Port 2 |
| One identical pad cannot be distinguished | Non-unique OS/controller identity | Document the limitation; test fixed ports and order |
Detection does not choose a player
Autoconfiguration can give both pads correct button layouts while the operating system presents them in a different order. RetroArch's Device Index assignment decides which currently connected controller feeds each frontend port.
Test with one pad first. Adding the second only after Port 1 is known removes ambiguity from the first assignment.
Reservation needs a stable identity
Libretro recommends device reservation when enumeration order is not enough. It can work only with the identity the Android input layer and controller provide; two cheap pads with indistinguishable identifiers may remain order-dependent.
Do not promise a software setting can manufacture a unique hardware identity. A repeatable connection order is a valid documented fallback.
The core owns the emulated ports
After frontend assignment, the loaded core still decides which emulated controller types exist on each port. A title may support one player, require a particular device type, or expose service controls separately.
Keep frontend Device Index evidence separate from Quick Menu core-port evidence so a content limitation is not misdiagnosed as Android Bluetooth failure.
Multiplayer input testing does not require unauthorized games. Use content you dumped lawfully, creator-authorized software, or a project-original controller fixture; controller support does not change distribution rights.