Minor clarificaton on USER_IDENTIFICATION_ASSOCIATION doc.
Test: none
Bug: 150409351
Change-Id: I4c8e11c118a503998736acb37259eb6aaea1c542
diff --git a/automotive/vehicle/2.0/types.hal b/automotive/vehicle/2.0/types.hal
index 733e7dc..2e6fa25 100644
--- a/automotive/vehicle/2.0/types.hal
+++ b/automotive/vehicle/2.0/types.hal
@@ -2847,7 +2847,7 @@
*
* Then to associate the user with the custom mechanism, a set request would be made:
*
- * int32[0]: 42 // request id
+ * int32[0]: 43 // request id
* int32[1]: 10 (Android user id)
* int32[2]: 0 (Android user flags)
* int32[3]: 1 (number of associations being set)
@@ -2856,7 +2856,7 @@
*
* If the request succeeded, the response would be simply:
*
- * int32[0]: 42 // request id
+ * int32[0]: 43 // request id
* int32[1]: 1 (number of associations in the response)
* int32[2]: 101 (1st type: UserIdentificationAssociationType::CUSTOM_1)
* int32[3]: 1 (1st value: UserIdentificationAssociationValue::ASSOCIATED_CURRENT_USER)
@@ -2865,7 +2865,7 @@
* example above, the end state would be 2 associations (FOB and CUSTOM_1). If we wanted to
* associate the user with just CUSTOM_1 but not FOB, then the request should have been:
*
- * int32[0]: 42 // request id
+ * int32[0]: 43 // request id
* int32[1]: 10 (Android user id)
* int32[2]: 2 (number of types set)
* int32[3]: 1 (1st type: UserIdentificationAssociationType::KEY_FOB)