Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Propiedades de HAL de usuario

Muchas arquitecturas de vehículos actuales contienen varias unidades de control electrónico (ECU) fuera del sistema de infoentretenimiento que controlan la ergonomía, como la configuración de los asientos y los ajustes de los espejos. Según las arquitecturas actuales de hardware y energía, muchas ECU se encienden antes de que se encienda el sistema de información y entretenimiento basado en Android. Estos ECUs puede interconectarse con un sistema de información y entretenimiento basado en Android a través de la capa de abstracción de hardware del vehículo (Vhal) .

A partir de Android 11, Android Automotive OS (AAOS) introdujo un nuevo conjunto de propiedades en el VHAL para crear, cambiar, eliminar y asociar accesorios externos para identificar a los usuarios. Por ejemplo, estas nuevas propiedades permiten a un conductor de par-atar un accesorio externo, como un llavero de control remoto, a su usuario de Android. Luego, cuando el conductor se acerca al vehículo, una ECU se despierta y detecta el llavero. Esta ECU indica al HAL qué usuario de Android debe iniciar el infoentretenimiento, lo que reduce el tiempo que un conductor espera a que se cargue su usuario de Android.

Habilitar el usuario HAL

Las propiedades de HAL usuario debe habilitar de forma explícita al asegurar la propiedad del sistema android.car.user_hal_enabled se establece en true . (Esto también se puede hacer en el car.mk archivo, de modo que no es necesario ajustar manualmente.) Compruebe que user_hal_enabled=true se habilita el vertido UserHalService :

$ adb shell dumpsys car_service --hal UserHalService|grep enabled
user_hal_enabled=true

También puede comprobar user_hal_enabled mediante el uso de adb shell GetProp android.car.user_hal_enabled o adb logcat CarServiceHelper *:s . Si la propiedad está desactivada, aparece un mensaje como el siguiente, cuando system_server comienza:

I CarServiceHelper: Not using User HAL

Para habilitar manualmente user_hal_enabled , establecer el android.car.user_hal_enabled propiedad del sistema y el reinicio system_server :

$ adb shell setprop android.car.user_hal_enabled true
$ adb shell stop && adb shell start

El logcat salida aparece como sigue:

I CarServiceHelper: User HAL enabled with timeout of 5000ms
D CarServiceHelper: Got result from HAL: OK
I CarServiceHelper: User HAL returned DEFAULT behavior

Propiedades de HAL de usuario

Propiedades del ciclo de vida del usuario

Las siguientes propiedades proporcionan la información de HAL para los estados del ciclo de vida del usuario, que permiten la sincronización del ciclo de vida del usuario entre el sistema Android y una ECU externa. Estas propiedades utilizan un protocolo de solicitud y respuesta, en el que el sistema Android realiza una solicitud estableciendo un valor de propiedad y HAL responde emitiendo un evento de cambio de propiedad.

Nota: Cuando se admite HAL usuario, todas las siguientes propiedades se debe implementar.

Propiedad HAL Descripción
INITIAL_USER_INFO
(LEER ESCRIBIR)
El sistema Android llama a esta propiedad para determinar qué usuario de Android iniciará el sistema cuando el dispositivo se inicie o se reanude desde Suspend-to-RAM (STR). Cuando se le llama, la HAL debe responder con una de estas opciones:
  • El comportamiento predeterminado establecido por Android (cambiar al último usuario utilizado o crear un nuevo usuario si este es el primer inicio).
  • Cambiar a un usuario existente.
  • Cree un nuevo usuario (con las propiedades opcionales de nombre, indicadores, configuración regional del sistema, etc.) y cambie a ese nuevo usuario.

Nota: Si el HAL no responde, el comportamiento por defecto es ejecutar después de un período de tiempo de espera (cinco (5) segundos por defecto), lo que retrasa el arranque. Si el HAL responde, pero el sistema Android no ejecuta la acción (por ejemplo, si se ha alcanzado el número máximo de usuarios), se utiliza el comportamiento predeterminado.

Por ejemplo, por defecto, el sistema Android se inicia en el último usuario activo en el arranque. Si se detecta un llavero para un usuario diferente, la ECU anula la propiedad HAL y, durante el inicio, el sistema Android cambia para iniciarse en ese usuario especificado.

SWITCH_USER
(LEER ESCRIBIR)
Esta propiedad se llama al cambiar el usuario de Android activo en primer plano. La propiedad puede ser invocada por el sistema Android o por HAL para solicitar un cambio de usuario. Los tres flujos de trabajo son:
  • Moderno. Interruptor partido de CarUserManager .
  • Legado. Interruptor partido de ActivityManager .
  • Vehículo. Llamado por el HAL para solicitar un cambio de usuario.

El flujo de trabajo moderno utiliza un enfoque de confirmación de dos fases para garantizar que el sistema Android y la ECU externa estén sincronizados. Cuando Android inicia el cambio:

  1. Compruebe el HAL para determinar si se puede cambiar de usuario.

    El HAL responde con SUCCESS o FAILURE , por lo que Android sabe si proceder o no.

  2. Completa el cambio de usuario de Android.

    Android envía un ANDROID_POST_SWITCH respuesta a la HAL para indicar el éxito o el fracaso del interruptor.

El HAL debe esperar hasta después de la ANDROID_POST_SWITCH respuesta a actualizar su estado para sincronizar ECU o actualizar otras propiedades HAL.

Por ejemplo, mientras está en movimiento, un intento de conductor cambiar usuarios de Android en la interfaz de usuario de información y entretenimiento. Sin embargo, debido a que la configuración del asiento para el automóvil está vinculada al usuario de Android, el asiento se moverá durante el cambio de usuario. Por lo tanto, la ECU que controla los asientos no confirma el cambio, el HAL responde con una falla y el usuario de Android no se cambia.

El flujo de trabajo heredado es una llamada unidireccional enviada después de que se cambia el usuario (por lo que la HAL no puede bloquear el cambio). Sólo se le llama en el arranque (después del cambio de usuario inicial) o para aplicaciones que llamar ActivityManager.switchUser() en lugar de CarUserManager.switchUser() . La referencia Settings y SystemUI ya aplicaciones utilizan la última, pero si un OEM ofrece sus propias aplicaciones ajustes para cambiar los usuarios, los fabricantes de equipos deben cambiar el uso.

Por ejemplo, si una aplicación utiliza ActivityManager.switchUser() para cambiar de usuario, a continuación, una llamada unidireccional se envía a la HAL para informar de que un cambio de usuario ha tenido lugar.

El flujo de trabajo del vehículo se origina en HAL, no en el sistema Android:

  1. El HAL solicita un cambio de usuario.
  2. El sistema completa el cambio de usuario de Android.
  3. Android envía un ANDROID_POST_SWITCH respuesta a la HAL para indicar el éxito o el fracaso del interruptor.

Por ejemplo, Bob utiliza llave de Alice para abrir el coche y el HAL respondió a la INITIAL_USER_INFO petición de ID de usuario de Alicia. A continuación, una ECU sensor biométrico identifica al conductor como Bob, por lo que el usuario envió una HAL SWITCH_USER solicitud a los usuarios de los interruptores.

CREATE_USER
(LEER ESCRIBIR)
Esta propiedad se llama por el sistema Android cuando se crea un nuevo usuario de Android (utilizando el CarUserManager.createUser() API).

El HAL responde con SUCCESS o FAILURE . Si el HAL responde con una falla, el sistema Android elimina al usuario.

Por ejemplo, un conductor golpea un icono de información y entretenimiento de interfaz de usuario para crear un nuevo usuario de Android. Esto envía una solicitud al HAL y al resto de los subsistemas del vehículo. Se informa a las ECU del usuario recién creado. Luego, otros subsistemas y ECU asocian su ID de usuario interno con el ID de usuario de Android.

REMOVE_USER
(Escribir solamente)
El sistema Android llama a esta propiedad después se elimina un usuario de Android (con la CarUserManager.removeUser() API).

Esta es una llamada unidireccional; no se espera respuesta del HAL.

Por ejemplo, un conductor golpea ligeramente para eliminar un usuario de Android existente en la interfaz de usuario de información y entretenimiento. Se informa al HAL y se informa a otros subsistemas del vehículo y ECU de la eliminación del Usuario para que puedan eliminar su ID de usuario interno.

Propiedades adicionales

Las siguientes son propiedades adicionales, no relacionadas con los estados del ciclo de vida del usuario. Cada uno se puede implementar sin admitir el usuario HAL.

Propiedad HAL Descripción
USER_IDENTIFICATION_ASSOCIATION
(LEER ESCRIBIR)
Utilice esta propiedad para asociar cualquier usuario de Android con un mecanismo de identificación, como un llavero o un teléfono. Utilice esta misma propiedad para get o set asociaciones.

Por ejemplo, un conductor golpea un icono de información y entretenimiento de interfaz de usuario para asociar el dispositivo de llave se utiliza para abrir el vehículo (KEY_123) a la corriente activa usuario de Android (USER_11).

Bibliotecas auxiliares

Todos los objetos utilizados en los mensajes de solicitud y de respuesta (tales como UserInfo , InitialUserInfoRequest , InitialUSerInfoResponse , etc.) tienen una representación de alto nivel usando C ++ struct , pero la eliminación deben ser aplanadas en estándar VehiclePropValue objetos (ver los ejemplos siguientes). Para facilidad de desarrollo, una biblioteca de ayuda C ++ se proporciona en AOSP para convertir automáticamente HAL usuario structs en un VehiclePropValue (y viceversa).

Ejemplos de

INITIAL_USER_INFO

Ejemplo de solicitud (en el primer arranque)

VehiclePropValue { // flattened from InitialUserInfoRequest
prop: 299896583 // INITIAL_USER_INFO
prop.values.int32Values:
 [0] = 1 // Request ID
 [1] = 1 // InitialUserInfoRequestType.FIRST_BOOT
 [2] = 0 // user id of current user
 [3] = 1 // flags of current user (SYSTEM)
 [4] = 1 // number of existing users
 [5] = 0 // existingUser[0].id
 [6] = 1 // existingUser[0].flags
}

Ejemplo de respuesta (crear usuario administrador)

VehiclePropValue { // flattened from InitialUserInfoResponse
prop: 299896583 // INITIAL_USER_INFO
prop.values.int32Values:
  [0] = 1      // Request ID (must match request)
  [1] = 2      // InitialUserInfoResponseAction.CREATE
  [2] = -10000 // user id (not used on CREATE)
  [3] = 8      // user flags (ADMIN)
prop.values.stringValue: "en-US||Car Owner" // User locale and User name
}

CAMBIAR DE USUARIO

El nombre real de las clases y propiedades difiere ligeramente, pero el flujo de trabajo general es el mismo, como se ilustra a continuación:

Flujo de trabajo

Figura 1. El usuario HAL Propiedades de flujo de trabajo

Ejemplo de solicitud de flujo de trabajo moderno

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896585 // SWITCH_USER
prop.values.int32Values:
 [0]     = 42    // Request ID
 [1]     = 2     // SwitchUserMessageType::ANDROID_SWITCH ("modern")
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 10,8  // current user id (10) and flags (ADMIN)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

Ejemplo de respuesta de flujo de trabajo moderno

VehiclePropValue { // flattened from SwitchUserResponse
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0] = 42        // Request ID (must match request)
 [1] = 3         // SwitchUserMessageType::VEHICLE_RESPONSE
 [2] = 1         // SwitchUserStatus::SUCCESS
}

Ejemplo de respuesta posterior al cambio de flujo de trabajo moderno

Esta respuesta suele ocurrir cuando un cambio de Android tiene éxito:

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = 42    // Request ID (must match "pre"-SWITCH_USER request )
 [1]     = 5     // SwitchUserMessageType::ANDROID_POST_SWITCH
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 11,0  // current user id (11) and flags (none in this case)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

Respuesta posterior al cambio de flujo de trabajo moderno

Esta respuesta suele ocurrir cuando falla un conmutador de Android:

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = 42    // Request ID (must match "pre"-SWITCH_USER request )
 [1]     = 5     // SwitchUserMessageType::ANDROID_POST_SWITCH
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 10,8  // current user id (10) and flags (ADMIN)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

Ejemplo de solicitud de flujo de trabajo heredado

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = 2     // Request ID
 [1]     = 1     // SwitchUserMessageType::LEGACY_ANDROID_SWITCH
 [2,3]   = 10,8  // target user id (10) and flags (ADMIN)
 [4,5]   = 0,1   // current user id (0) and flags (SYSTEM)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

Ejemplo de solicitud de flujo de trabajo del vehículo

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = -108  // Request ID (must be negative)
 [1]     = 4     // SwitchUserMessageType::VEHICLE_REQUEST
 [2]     = 11    // target user id
}

Respuesta posterior al cambio de flujo de trabajo heredado

Esta respuesta suele ocurrir cuando un cambio de Android tiene éxito:

VehiclePropValue { // flattened from SwitchUserRequest
prop: 299896584 // SWITCH_USER
prop.values.int32Values:
 [0]     = -108  // Request ID (must match from vehicle request )
 [1]     = 5     // SwitchUserMessageType::ANDROID_POST_SWITCH
 [2,3]   = 11,0  // target user id (11) and flags (none in this case)
 [4,5]   = 11,0  // current user id (11) and flags (none in this case)
 [6]     = 3     // number of existing users (0, 10, 11)
 [7,8]   = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [9,10]  = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [11,12] = 11,0  // existingUser[2] (id=11, flags=NONE)
}

CREAR USUARIO

Ejemplo de solicitud

VehiclePropValue { // flattened from CreateUserRequest
prop: 299896585 // CREATE_USER
prop.values.int32Values:
 [0]      = 42  // Request ID
 [1,2]    = 11,6     // Android id of the created user and flags (id=11, flags=GUEST, EPHEMERAL)
 [3,4]    = 10,0  // current user id (10) and flags (none in this case)
 [5]      = 3  // number of existing users (0, 10, 11)
 [6,7]    = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [8,9]    = 10,8  // existingUser[1] (id=10, flags=ADMIN)
 [10,11] = 11,6 // newUser[2] (id=11, flags=GUEST,EPHEMERAL)
}

Ejemplo de respuesta

VehiclePropValue { // flattened from CreateUserResponse
prop: 299896585 // CREATE_USER
prop.values.int32Values:
 [0] = 42        // Request ID (must match request)
 [1] = 3         // CreateUserStatus::SUCCESS
}

REMOVE_USER

Ejemplo de solicitud

VehiclePropValue { // flattened from RemoveUserRequest
prop: 299896586 // REMOVE_USER
prop.values.int32Values:
 [0]      = 42  // Request ID
 [1,2]    = 11,0     // Android id of the removed user and flags (none in this case)
 [3,4]    = 10,0  // current user id (10) and flags (none in this case)
 [5]      = 2  // number of existing users (0, 10)
 [6,7]    = 0,1   // existingUser[0] (id=0, flags=SYSTEM)
 [8,9]    = 10,8  // existingUser[1] (id=10, flags=ADMIN)
}

USER_IDENTIFICATION_ASSOCIATION

Establecer ejemplo (llavero asociado con el usuario 10)

VehiclePropValue { // flattened from UserIdentificationSetRequest
prop: 299896587 // USER_IDENTIFICATION_ASSOCIATION
prop.values.int32Values:
 [0]      = 43  // Request ID
 [1,2]    = 10,0     // Android id (10) and flags (none in this case)
 [3]    = 1  // number of associations being set
 [4]      = 1  // 1st type: UserIdentificationAssociationType::KEY_FOB
 [5]    = 1   // 1st value: UserIdentificationAssociationSetValue::ASSOCIATE_CURRENT_USER
}