From 412a7fe2340d117eb403e8c6369ab7ec0c96767e Mon Sep 17 00:00:00 2001 From: Steven Moreland Date: Tue, 1 Dec 2020 17:51:20 +0000 Subject: [PATCH] vibrator: example for how to get ID Since someone asked, and I was still confused, after discussion, this is the way things work. Bug: 173817747 Test: N/A Change-Id: I2c4e062672a2f2d998479d4f9ae11b7749c2aca6 --- vibrator/aidl/android/hardware/vibrator/IVibrator.aidl | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/vibrator/aidl/android/hardware/vibrator/IVibrator.aidl b/vibrator/aidl/android/hardware/vibrator/IVibrator.aidl index 0b21248220..cd7b60340c 100644 --- a/vibrator/aidl/android/hardware/vibrator/IVibrator.aidl +++ b/vibrator/aidl/android/hardware/vibrator/IVibrator.aidl @@ -206,7 +206,10 @@ interface IVibrator { * device/board configuration files ensuring that no ID is assigned to * multiple clients. No client should use this API unless explicitly * assigned an always-on source ID. Clients must develop their own way to - * get IDs from vendor in a stable way. + * get IDs from vendor in a stable way. For instance, a client may expose + * a stable API (via HAL, sysprops, or xml overlays) to allow vendor to + * associate a hardware ID with a specific usecase. When that usecase is + * triggered, a client would use that hardware ID here. * * @param id The device-specific always-on source ID to enable. * @param effect The type of haptic event to trigger.