Essential design considerations

When implementing gamepad support, consider the following essential requirements to help players enjoy smooth, uninterrupted gameplay.

Let users on the Play Store know your game supports controllers

Declaring the gamepad feature in your Android manifest displays a gamepad-supported icon and tag on Google Play. Use this declaration to help more users discover and play your game. For detailed configuration instructions and manifest examples, see Play Store visibility and Gamepad hardware features.

Let players switch seamlessly between input devices

When players transition between input devices, make the switch seamless. Avoid requiring players to manually toggle their input method in a settings menu or restart the game.

Side-by-side racing game screens: touch steering and nitro buttons appear during mobile play and disappear automatically when a physical gamepad connects.
Figure 1. Seamless switching between input methods without interrupting gameplay.

Switch automatically and support hot-plugging

Keep all supported input devices active simultaneously so players can switch between them on the fly. Listen for input device changes at runtime so gamepads work immediately upon connection without restarting the app, and seamlessly transition to other available input methods if an active controller disconnects during gameplay. To detect controller connections and disconnections, see Verify a game controller is connected (Kotlin or Java) or Register or remove a controller status callback (C++ Game Controller library). On Android 16 (API level 36) and lower, also declare android:configChanges="keyboard|keyboardHidden|navigation" in your manifest so connecting or disconnecting a controller does not restart your activity (see Handle configuration changes).

Not recommended Recommended
Not recommended: A modal dialog requiring the player to switch input mode manually in Settings and restart the game when a controller is detected. Recommended: A non-intrusive banner confirming the controller is connected and input switched automatically with gamepad prompts.

Update button iconography and text guides to match the active device

Dynamically switch on-screen button icons and text guides based on the active input device. For example, transition a touch-control guide like "Tap to jump" to "Press B to jump" (or the platform-equivalent button) when your game detects gamepad input.

Side-by-side adventure game screens: Tap to Jump and Tap Chest to Open prompts switch to Press B to Jump and A Open Chest when a gamepad connects.
Figure 2. Dynamically updating on-screen button icons and guide text to match the active controller.

Hide virtual touch controls when a gamepad is active

To prevent screen clutter and player confusion, hide all virtual touch UI elements, such as virtual joysticks and on-screen buttons, when a gamepad is active. Restore the touch UI immediately if the player touches the screen.

Side-by-side adventure game screens: the virtual joystick and sword attack button are visible during touch play and hidden for an unobstructed view when a gamepad connects.
Figure 3. Hiding virtual touch controls when gamepad input is active.

Provide full gamepad support for all in-game logic

Avoid relying on touch as a fallback mechanism. Using touch to exit menus or perform specific parts of the game can break immersion. Implement all in-game interactions so players can perform them entirely using a gamepad.

Map all HUD elements and dialogs to controller inputs

Let players open, interact with, and close all on-screen heads-up display (HUD) elements, menus, and dialogs using the controller through dedicated shortcut buttons, bumpers, or directional pad (D-pad) navigation so they don't have to touch the screen.

Not recommended Recommended
Not recommended: A modal dialog and on-screen interface icons with no controller shortcuts, forcing the player to tap the close button on screen. Recommended: On-screen interface icons and modal dialog buttons mapped to controller inputs with clear A and B button prompts.

Separate gameplay and UI input contexts

When a menu or dialog opens over gameplay, switch contexts or block background controls so the gamepad only interacts with the active UI. This separation prevents directional navigation or button presses in a menu from accidentally triggering character movement or actions in the background.

Not recommended Recommended
Not recommended: Navigating an open inventory menu accidentally causes the character to move and swing their weapon in the background. Recommended: Opening the inventory menu blocks background gameplay input so D-pad and button presses only move the item grid focus while the character stands still.

Assign initial focus immediately when a screen opens

Unlike touch input, where players tap buttons directly, gamepad navigation moves from the currently focused element to an adjacent one. If a new menu or dialog opens without an initial focus target, D-pad and confirm inputs can fail to respond or remain trapped on background elements. Assign initial focus to a default button as soon as a screen opens.

Not recommended Recommended
Not recommended: A pause menu opens with no button focused, leaving the player with no starting point for D-pad navigation. Recommended: The pause menu immediately highlights the default Continue button with a clear focus border and A button prompt.