Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 00134a22 authored by felipeal's avatar felipeal
Browse files

Minor clarificaton on USER_IDENTIFICATION_ASSOCIATION doc. 

Test: none
Bug: 150409351
Change-Id: I4c8e11c118a503998736acb37259eb6aaea1c542
parent 91c5deaf

automotive/vehicle/2.0/types.hal

+3 −3
Original line number Diff line number Diff line
@@ -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)