CHANGE: Add AndroidDeviceCapabilities.vibratorCount#2410
CHANGE: Add AndroidDeviceCapabilities.vibratorCount#2410jfreire-unity merged 2 commits intodevelopfrom
Conversation
todi1856
changed the title
![u-pr[bot]](https://avatars.githubusercontent.com/in/1201017?s=60&v=4){kind=small}
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## develop #2410 +/- ##
===========================================
- Coverage 78.13% 78.12% -0.01%
===========================================
Files 483 483
Lines 98770 98771 +1
===========================================
- Hits 77169 77166 -3
- Misses 21601 21605 +4 Flags with carried forward coverage won't be shown. Click here to find out more.
|
| public bool isVirtual; | ||
| public AndroidAxis[] motionAxes; | ||
| public AndroidInputSource inputSources; | ||
| public int vibratorCount; |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
@jfreire-unity could you merge this branch if everything's okay, I don't have the necessary permission. |
jfreire-unity
deleted the
android/device-capabilities-add-vibrator-count
branch
Done, thanks! |
2 participants
Description
Android team is adding rumble support for gamepads - https://jira.unity3d.com/browse/PLAT-19228 (The changes will be done mainly in Android's backend). One of the changes is DeviceCapabilities expansion - https://github.cds.internal.unity3d.com/unity/unity/pull/102096/commits/f682823cc6640dddb48d172bb57cb1f2bdd2b460
Basically it allows you to query how many motors (a.k.a vibrators in Android term) the device has.
This PR simply mirrors the change on input system package.
Note AndroidDeviceCapabilities is an internal class, so no user facing changes, additionally if backend doesn't report vibratorCount, it will simply default to 0.