Create a RetroArch controller autoconfig profile on Android
Disconnect other pads, confirm Android itself sees the controller, then update RetroArch's controller profiles. If the pad is detected but not configured, record its controller driver, Device Index, vendor ID, and product ID, bind the RetroPad controls, and save one controller profile to a writable Controller Profiles directory. Restart and verify the same profile is selected before changing any core-specific controls.
Do this in order
- 01
Disconnect every other gamepad, connect the target pad, and confirm Android can navigate or report its buttons before opening RetroArch.
- 02
In RetroArch, update Controller Profiles, then record Settings → Drivers → Controller and the Port 1 Device Index.
- 03
If no suitable profile loads, choose a Controller Profiles directory that this Android build can write and preserve that exact path in your setup note.
- 04
Open Settings → Input → RetroPad Binds → Port 1 Controls, use Set All Controls, and manually finish any bind that the sequence skips.
- 05
Select Save Controller Profile once; record the profile name, driver, Device Index, vendor ID, product ID, and whether the connection is USB or Bluetooth.
- 06
Quit RetroArch normally, reconnect the same pad, restart, and verify the autoconfiguration notice and menu buttons before loading authorized content.
Decision and diagnostic table
| Evidence | Likely boundary | Next action |
|---|---|---|
| Android does not see input | Cable, Bluetooth pairing, firmware, or OS support | Fix the Android layer before RetroArch |
| Device Index exists but no profile loads | Autoconfig match or profile database | Update profiles, then create one exact profile |
| Binds work but profile will not save | Controller Profiles directory is not writable | Select a writable directory and retry once |
| Profile loads but one game is wrong | Core or game remap, not autoconfig | Keep the profile; create a narrow input remap |
Autoconfig maps hardware to the RetroPad
A controller profile describes how a physical Android controller maps to RetroArch's virtual RetroPad. It should make the menu and common frontend binds consistent before a core translates that RetroPad into the emulated machine's controls.
Do not repair one game's unusual layout by corrupting the hardware profile for every core. Prove the base profile first, then use a core or game remap for content-specific changes.
A visible name is only part of the match
Libretro documents a scored match that can use the controller driver, Device Index, vendor ID, product ID, and, on supported platforms, a physical identifier. Android profiles require correct vendor and product evidence, while the displayed device name can also vary between USB and Bluetooth.
Record the transport and identifiers shown by the build you actually use. A profile copied from another operating system or driver can have the right marketing name and still bind the wrong buttons.
Prove persistence with a cold restart
Saving without restarting proves only that the current session accepts the binds. Quit normally, reconnect, and reopen RetroArch so the profile must be discovered from disk and matched again.
Keep a copy of a working custom profile outside app-private storage before clearing app data or reinstalling. Do not assume the example shared-storage path in the official Android notes applies to every package.
Controller setup requires no commercial game data. Test the menu, the built-in Remote RetroPad core, your own program, or content you are authorized to use; a working controller profile does not grant rights to ROM, BIOS, artwork, or music files.