Android controller KeyEvent vs MotionEvent: diagnose missing emulator inputs
Android normally reports digital buttons with KeyEvent and sticks, hats, and analog triggers with MotionEvent axes. Test the controller at the Android layer first; a trigger mapped as an axis will not be repaired by repeatedly binding a button keycode.
Do this in order
- 01
Connect one controller and record Android version, wired or wireless transport, and emulator build.
- 02
Use an Android input test to identify each control as a keycode or named motion axis.
- 03
Confirm D-pad hats, both sticks, and analog triggers reach Android before opening the emulator mapper.
- 04
In the frontend, map hardware to its virtual controller layer; in RetroArch that layer is RetroPad.
- 05
Map the virtual controls to the game's inputs and test press, hold, release, full axis travel, and center.
- 06
Reconnect and cold-start once to prove the mapping survives enumeration and relaunch.
Decision and diagnostic table
| Physical control | Typical Android event | Failure clue |
|---|---|---|
| Face/bumper/start button | KeyEvent | No down/up or unexpected repeat |
| Analog stick | MotionEvent axis | No range, drift, or wrong axis |
| D-pad | Hat axes or key events | Menu works but game mapping differs |
| Analog trigger | Trigger axis; some variants also send key events | Binding only a button loses analog travel |
Android reports controls before the emulator maps them
The operating system event, frontend virtual pad, core input, and machine control are separate layers. Prove each transition instead of remapping all layers at once.
Controller families can differ
Android's official guidance notes labeling and trigger-event variations among Xbox-, Switch-, and PlayStation-style controllers. Test the actual device rather than assuming the printed label is the event identity.
Input diagnostics do not authorize game data. Use a lawful test title and do not bundle controller profiles with unauthorized ROM, BIOS, artwork, or music.