From 00134a22c2bf5373360a536b183bc03c9cf50d95 Mon Sep 17 00:00:00 2001 From: felipeal Date: Fri, 8 May 2020 09:48:03 -0700 Subject: [PATCH] Minor clarificaton on USER_IDENTIFICATION_ASSOCIATION doc. Test: none Bug: 150409351 Change-Id: I4c8e11c118a503998736acb37259eb6aaea1c542 --- automotive/vehicle/2.0/types.hal | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/automotive/vehicle/2.0/types.hal b/automotive/vehicle/2.0/types.hal index 733e7dc945..2e6fa25c5e 100644 --- a/automotive/vehicle/2.0/types.hal +++ b/automotive/vehicle/2.0/types.hal @@ -2847,7 +2847,7 @@ enum VehicleProperty : int32_t { * * 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 @@ enum VehicleProperty : int32_t { * * 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 @@ enum VehicleProperty : int32_t { * 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)