USER_IDENTIFICATION_ASSOCIATION

Property used to associate (or query the association) the current user with vehicle-specific identification mechanisms (such as key FOB).

This is an optional user management property - the OEM could still support user management without defining it. In fact, this property could be used without supporting the core user-related functions described on INITIAL_USER_INFO.

To query the association, the Android system gets the property, passing a VehiclePropValue containing the types of associations are being queried, as defined by UserIdentificationGetRequest. The HAL must return right away, returning a VehiclePropValue with a UserIdentificationResponse. Notice that user identification should have already happened while system is booting up and the VHAL implementation should only return the already identified association (like the key FOB used to unlock the car), instead of starting a new association from the get call.

To associate types, the Android system sets the property, passing a VehiclePropValue containing the types and values of associations being set, as defined by the UserIdentificationSetRequest. The HAL will then use a property change event (whose VehiclePropValue is defined by UserIdentificationResponse) indicating the current status of the types after the request.

For example, to query if the current user (10) is associated with the FOB that unlocked the car and a custom mechanism provided by the OEM, the request would be:

int32[0]: 42 // request id int32[1]: 10 (Android user id) int32[2]: 0 (Android user flags) int32[3]: 2 (number of types queried) int32[4]: 1 (1st type queried, UserIdentificationAssociationType::KEY_FOB) int32[5]: 101 (2nd type queried, UserIdentificationAssociationType::CUSTOM_1)

If the user is associated with the FOB but not with the custom mechanism, the response would be:

int32[0]: 42 // request id int32[1]: 2 (number of associations in the response) int32[2]: 1 (1st type: UserIdentificationAssociationType::KEY_FOB) int32[3]: 2 (1st value: UserIdentificationAssociationValue::ASSOCIATED_CURRENT_USER) int32[4]: 101 (2st type: UserIdentificationAssociationType::CUSTOM_1) int32[5]: 4 (2nd value: UserIdentificationAssociationValue::NOT_ASSOCIATED_ANY_USER)

Then to associate the user with the custom mechanism, a set request would be made:

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) int32[4]: 101 (1st type: UserIdentificationAssociationType::CUSTOM_1) int32[5]: 1 (1st value: UserIdentificationAssociationSetValue::ASSOCIATE_CURRENT_USER)

If the request succeeded, the response would be simply:

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)

Notice that the set request adds associations, but doesn't remove the existing ones. In the 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]: 43 // request id int32[1]: 10 (Android user id) int32[2]: 2 (number of types set) int32[3]: 1 (1st type: UserIdentificationAssociationType::KEY_FOB) int32[4]: 2 (1st value: UserIdentificationAssociationValue::DISASSOCIATE_CURRENT_USER) int32[5]: 101 (2nd type: UserIdentificationAssociationType::CUSTOM_1) int32[6]: 1 (2nd value: UserIdentificationAssociationValue::ASSOCIATE_CURRENT_USER)