What causes a mobile game vibrating when the player has haptics off?

The game calls the platform vibrate API directly without checking the user's system haptic and ringer settings, so it buzzes even when the player asked for none.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix a Mobile Game Vibrating When the Player Has Haptics Off

Quick answer: Respect the OS haptic setting and your own in-game toggle before triggering vibration, and use the platform haptic feedback API that honors system preferences.

A player on silent in a meeting opens your game and it buzzes loudly on the table. Your vibrate calls ignore the system setting. Gate haptics behind both the OS preference and an in-game toggle.

How to fix it

1. Check the system setting

On iOS use the haptic feedback generators, which already respect the system haptics switch; on Android check the user's haptic feedback preference before calling Vibrator.

2. Add an in-game toggle

Provide your own haptics on/off option and default to following the OS, so players can disable rumble independently if they want.

3. Skip vibration in silent contexts

Suppress non-essential haptics when the device is in a do-not-disturb or silent state so the game stays courteous in quiet environments.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every mobile error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The errors you never hear about are the ones quietly costing you players. Visibility turns them into a worklist.