Some devices automatically reduce or disable haptics at low battery

What it is

Some devices automatically reduce or even disable haptic output at low battery or in power-saving mode. This is a system-level power policy that applications cannot prevent. The consequence is that haptic feedback weakens or disappears without the user noticing, and it is easily read as an app fault.

Why it happens

The system throttles to extend runtime, on the same logic as lowering display brightness or clocking down the processor. The problem is that haptic change has no visible marker: dimming gets noticed, while weakened haptics only make a few interactions feel "somehow off." When the app still requests the original strength, actual output is decided by the system, so app-side logs show everything normal. That asymmetry makes diagnosis hard and obliges the app to detect and communicate the state.

Studying it

Measure actual output across charge levels and power modes: record the waveform and user detection for the same request just before and after the battery threshold, identifying where and how much the reduction occurs. Variables include device model, OS version, power-saving mode, and requested strength. Outcomes include attenuation ratio, detection change, and whether users noticed.

Where it stops holding

If users deliberately enable power saving and understand it, weaker haptics are expected and the question becomes whether to notify. For devices without such a policy, the constraint does not apply. If the app offers an independent confirmation channel such as a visual cue, weakened haptics matter less—another place where a substitute channel earns its keep.

Applying it

• Measure actual haptic output across power modes on target models and record the thresholds and magnitudes of attenuation.
• When system policy clearly weakens haptics, surface a notice or confirm critical actions through another channel.
• Do not assume requested strength is delivered faithfully at low battery.
• Verification: measure detection of the same request before and after the battery threshold and confirm critical confirmations survive weakened haptics.

Related

• Within the group: D3.15.2 High-rate haptic feedback needs restraint when battery is low · D3.15.3 Power cost should factor into whether haptics are used for low-priority cases
• Adjacent: D3.12.4 Information carried by haptics must move to another channel when haptics are off · K3.04 Battery and performance tradeoffs on mobile devices
• Search terms: low battery throttling · power policy · haptic degradation