Skip to content

CHANGE: Add AndroidDeviceCapabilities.vibratorCount #2410

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jfreire-unity merged 2 commits into from
Apr 21, 2026
+14 −2
Merged

CHANGE: Add AndroidDeviceCapabilities.vibratorCount #2410

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7336bf5
Expand AndroidDeviceCapabilities.vibratorCount
todi1856 Apr 20, 2026
0607948
small fix
todi1856 Apr 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 14 additions & 2 deletions Packages/com.unity.inputsystem/InputSystem/Plugins/Android/AndroidGameController.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,7 @@
public bool isVirtual;
public AndroidAxis[] motionAxes;
public AndroidInputSource inputSources;
public int vibratorCount;
Comment thread
todi1856 marked this conversation as resolved.
Copy link
Copy Markdown
Collaborator

@jfreire-unity jfreire-unity Apr 20, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this only gamepad specific?

AFAIK, the Android vibrator API you mentioned is not compatible with our rumble API.
The vibrator API, at least for the android device itself, usually allows you to control the duration and, in some devices, the amplitude of vibrations, and doesn't match the concepts of motor speed in a controller.

From the Jira comments, I got a bit confused, and I believe you need to use these gamepad specific APIs instead to match our rumble interface https://developer.android.com/games/sdk/game-controller/controller-features#java ?

Copy link
Copy Markdown
Member Author

@todi1856 todi1856 Apr 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this only gamepad specific?

Yes and no, https://developer.android.com/reference/android/view/InputDevice#public-methods is heavily abstracted class, thus in theory and input device can have a vibrator. Though so far, I saw vibrators only available on gamepads

AFAIK, the Android vibrator API you mentioned is not compatible with our rumble API.
The vibrator API, at least for the android device itself, usually allows you to control the duration and, in some devices, the amplitude of vibrations, and doesn't match the concepts of motor speed in a controller.

it's compatible enough, connecting Android vibration API to https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/api/UnityEngine.InputSystem.Haptics.IDualMotorRumble.html is not that hard. Sure we could go further and have Android specific vibrator APIs to expose everything Android provides, but this is outside of that scope.

From the Jira comments, I got a bit confused, and I believe you need to use these gamepad specific APIs instead to match our rumble interface https://developer.android.com/games/sdk/game-controller/controller-features#java ?

There are not plans to use game-controller library in Unity , having access to https://developer.android.com/reference/android/view/InputDevice#public-methods is good enough for us.

Copy link
Copy Markdown
Collaborator

@jfreire-unity jfreire-unity Apr 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK thanks for the context. The only concern I have is that is that this might be too generic field. Like if the value is 3 is it the device + 2 rumble motors?
Anyway, I'm more thinking about "future" cases once we support "on-device" haptics, and not just rumble. And I guess at that point we can also adapt things since it's internal API.

Last point:

is not that hard

I understand it's not hard. But I think it won't be the same experience. I'd suggest this (if you are not planning it already): with the same gamepad on say, Windows, and Android, can you get the same "haptics experience" on both platforms with this approach?

Copy link
Copy Markdown
Member Author

@todi1856 todi1856 Apr 21, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AndroidDeviceCapabilities describes capabilities of input device (not the Android device itself) and AndroidDeviceCapabilities is per input device. Meaning:

  • Touchscreen input device has AndroidDeviceCapabilities
  • Mouse input device has AndroidDeviceCapabilities
  • Gamepad device has AndroidDeviceCapabilities, so if there are 4 gamepads connected, each of them will have its own AndroidDeviceCapabilities
  • and so on

if AndroidDeviceCapabilities class name is misleading, maybe we could change it ? But in input system package there are class names like:

  • WebGLDeviceCapabilities
  • XRDeviceDescriptor

that's why AndroidDeviceCapabilities was named like this, but if it would make it clearer, we could name it AndroidInputDeviceCapabilities ?

Like if the value is 3 is it the device + 2 rumble motors?

So if vibrator count 3, that would mean input device (for ex., Gamepad) has 3 vibrators.

P.S I chose "vibratorCount" name, because in Android API "vibrator" word (and not motor) is used - https://developer.android.com/reference/android/os/VibratorManager#getVibratorIds()

can you get the same "haptics experience" on both platforms with this approach?

you mean - does gamepad vibrate in the same manner both when connected to Windows machine or Android phone ? yes, that's the idea, it should vibrate in the same way. I'll ask our QA to double check on this, when https://github.cds.internal.unity3d.com/unity/unity/pull/102096 will be ready.


public string ToJson()
{
Expand All @@ -132,8 +133,19 @@

public override string ToString()
{
return
$"deviceDescriptor = {deviceDescriptor}, productId = {productId}, vendorId = {vendorId}, isVirtual = {isVirtual}, motionAxes = {(motionAxes == null ? "<null>" : String.Join(",", motionAxes.Select(i => i.ToString()).ToArray()))}, inputSources = {inputSources}";
var motionAxesString = motionAxes == null ? "<null>" : string.Join(",", motionAxes);
var entries = new[]

Check warning on line 137 in Packages/com.unity.inputsystem/InputSystem/Plugins/Android/AndroidGameController.cs

View check run for this annotation

Codecov GitHub.com / codecov/patch

Packages/com.unity.inputsystem/InputSystem/Plugins/Android/AndroidGameController.cs#L136-L137 

Added lines #L136 - L137 were not covered by tests
{
$"deviceDescriptor = {deviceDescriptor}",
$"productId = {productId}",
$"vendorId = {vendorId}",
$"isVirtual = {isVirtual}",
$"motionAxes = {motionAxesString}",
$"inputSources = {inputSources}",
$"vibratorCount = {vibratorCount}"
};

return string.Join(", ", entries);

Check warning on line 148 in Packages/com.unity.inputsystem/InputSystem/Plugins/Android/AndroidGameController.cs

View check run for this annotation

Codecov GitHub.com / codecov/patch

Packages/com.unity.inputsystem/InputSystem/Plugins/Android/AndroidGameController.cs#L148 

Added line #L148 was not covered by tests
Comment thread
todi1856 marked this conversation as resolved.
}
}
}
Expand Down
Loading