Para admitir la administración de energía específica del vehículo, Android proporciona un servicio CarPowerManagementService
y una interfaz CarPowerManager
.
Las transiciones de estado las activa la Unidad de control maestro del vehículo (VMCU). Para comunicarse con la VMCU, los integradores deben implementar varios componentes. Los integradores son responsables de la integración con la capa de abstracción de hardware del vehículo (VHAL) y la implementación del kernel. Los integradores también son responsables de desactivar las fuentes de activación y garantizar que los apagados no se pospongan indefinidamente.
Terminología
Estos términos se utilizan a lo largo de este documento:
suspend()
y shutdown()
.Diseño de sistemas
Esta sección describe cómo AAOS representa el estado de energía del procesador de la aplicación y qué módulos implementan el sistema de administración de energía. Este material también describe cómo estos módulos funcionan juntos y cómo ocurren típicamente las transiciones de estado.
Máquina de estado de energía del automóvil
AAOS utiliza una máquina de estado para representar el estado de energía del AP. La máquina de estados proporciona los estados que se ilustran a continuación:
Figura 1. Máquina de estados de energía del automóvil.
Las transiciones más comunes están resaltadas en azul. Estos son los estados y transiciones comunes:
- Suspender a RAM. El vehículo y el SoC están apagados. No se está ejecutando ningún código. La energía se mantiene en la RAM del SoC.
- Espere a VHAL. Cuando el conductor interactúa con el vehículo, por ejemplo, abriendo una puerta, la VMCU aplica energía al SoC. AAOS se reanuda desde Suspender a RAM y entra en Esperar a VHAL, donde espera la coordinación con VHAL.
- En. El VHAL le dice a AAOS que entre en el estado Encendido. En este estado, AAOS está completamente ejecutándose e interactuando con el controlador.
- Apagar Preparar. Cuando el conductor termina de conducir, el VHAL le indica a AAOS que ingrese a Shutdown Prepare. En este estado, la pantalla y el audio están apagados y AAOS no interactúa con el controlador. El sistema Android todavía está funcionando y es gratuito actualizar las aplicaciones y el sistema Android. Cuando se completan las actualizaciones, si las hay, el sistema Android ingresa a Esperar a que finalice VHAL.
- Espere a que VHAL finalice. En este punto, AAOS informa al VHAL que está listo para cerrarse. Se espera que la VMCU coloque el SoC en suspensión profunda y desconecte la energía del procesador de la aplicación. AAOS se encuentra entonces en el estado Suspender a RAM, aunque no se está ejecutando ningún código.
Módulos de administración de energía
El sistema de administración de energía se compone de estos módulos:
Nombre del módulo | Descripción |
---|---|
CochePowerManager | API Java o C++. |
Servicio de gestión de energía del coche | Coordina las transiciones de estados de poder. |
CochePolítica De EnergíaDemonio | Se comunica con los clientes de políticas de energía nativas. |
Vehículo HAL | Interfaz a la VMCU. |
Núcleo | Suspender a RAM o implementación de disco. |
La función de suspensión/hibernación profunda (suspender Android a la RAM/disco) está implementada en el kernel. Esta característica está expuesta al espacio del usuario como un archivo especial ubicado en /sys/power/state
. AAOS se suspende al escribir mem
o disk
en este archivo.
El CPMS coordina el estado de energía con otros servicios y HAL. El CPMS implementa la máquina de estados descrita anteriormente y envía notificaciones a cada observador cuando ocurre una transición de estado de energía. Este servicio también utiliza VHAL para enviar mensajes al hardware.
El CPPD gestiona la política energética hasta que el CPMS toma el control. También envía notificaciones de cambios de políticas de energía a los oyentes nativos.
Algunas propiedades están definidas en VHAL. Para comunicarse con la VMCU, el CPMS lee y escribe estas propiedades. Las aplicaciones pueden usar la interfaz definida en el CPM para monitorear los cambios en el estado de energía. Esta interfaz también permite que las aplicaciones registren oyentes de políticas de energía . Esta API se puede llamar desde Java y está anotada con @hide/@System API, lo que significa que está disponible solo para aplicaciones privilegiadas. La relación entre estos módulos, aplicaciones y servicios se ilustra a continuación:
Figura 2. Diagrama de referencia de los componentes de potencia.
Secuencia de mensajes
La sección anterior describió los módulos que componen el sistema de administración de energía. Esta sección utiliza los ejemplos de entrada y salida del sueño profundo para explicar cómo se comunican los módulos y las aplicaciones:
Entra en un sueño profundo
Sólo la VMCU puede iniciar el sueño profundo. Una vez que se inicia el sueño profundo, la VMCU envía una notificación al CPMS a través del VHAL. El CPMS cambia el estado a SHUTDOWN PREPARE y transmite esta transición de estado a todos los observadores (las aplicaciones y servicios que monitorean el CPMS) llamando al método onStateChanged()
con una nueva ID de estado proporcionada por el CPM.
El CPM media entre las aplicaciones/servicios y el CPMS. El método onStateChanged()
para las aplicaciones/servicios se invoca sincrónicamente en el método onStateChanged()
del CPM. La mayoría de las aplicaciones y servicios deben completar su preparación antes de regresar de esta llamada. Los servicios privilegiados pueden continuar sus preparativos de forma asincrónica después de regresar para PRE_SHUTDOWN_PREPARE
, SUSPEND_ENTER
, POST_SUSPEND_ENTER
. En este caso, se supone que el servicio privilegiado llama a complete() en el objeto CompletablePowerStateChangeFuture
proporcionado cuando finaliza su preparación. Tenga en cuenta que no se permite la preparación asincrónica para SHUTDOWN_PREPARE
. Antes de enviar DEEP_SLEEP_ENTRY
al VHAL, el CPMS envía periódicamente solicitudes de posposición de apagado al VHAL.
Cuando todos los objetos CPM han completado los preparativos de apagado, el CPMS envía AP_POWER_STATE_REPORT
al VHAL, que luego notifica a la VMCU que el AP está listo para suspender. El CPMS también llama a su método suspender, que suspende el núcleo.
La secuencia descrita anteriormente se ilustra a continuación:
Figura 3. Ingrese al sueño profundo.
Interfaces de programación proporcionadas por CPM
Esta sección describe la API de Java proporcionada por CPM para aplicaciones y servicios del sistema. Esta API permite que el software del sistema:
- Monitorear los cambios de estado de energía en el AP.
- Aplicar políticas de poder.
Utilice estos pasos para llamar a las API proporcionadas por CPM:
- Para adquirir la instancia de CPM, llame a Car API.
- Llame al método apropiado en el objeto creado en el Paso 1.
Crear un objeto CarPowerManager
Para crear un objeto CPM, llame al método getCarManager()
del objeto Car. Este método es una fachada utilizada para crear objetos CPM. Especifique android.car.Car.POWER_SERVICE
como argumento para crear un objeto CPM.
Car car = Car.createCar(this); CarPowerManager powerManager = (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);
CarPowerStateListener y registro
Las aplicaciones y servicios del sistema pueden recibir notificaciones de cambios en el estado de energía implementando CarPowerManager.CarPowerStateListener
. Esta interfaz define un método onStateChanged()
, que es una función de devolución de llamada invocada cuando se cambia el estado de energía de CPMS. El siguiente ejemplo define una nueva clase anónima que implementa la interfaz:
private final CarPowerManager.CarPowerStateListener powerListener = new CarPowerManager.CarPowerStateListener () { @Override public void onStateChanged(int state) { Log.i(TAG, "onStateChanged() state = " + state); } };
Para indicarle a este objeto de escucha que supervise una transición de estado de energía, cree un nuevo hilo de ejecución y registre el objeto de escucha y este hilo en el objeto CPM:
executor = new ThreadPerTaskExecutor(); powerManager.setListener(powerListener, executor);
Cuando se cambia el estado de energía, se invoca el método onStateChanged()
del objeto de escucha con un valor para representar el nuevo estado de energía. La asociación entre el valor real y el estado de energía se define en CarPowerManager
y se muestra en la siguiente tabla:
Nombre | Descripción |
---|---|
ESTADO_ON | Ingrese al estado encendido. El sistema está en pleno funcionamiento. |
STATE_SHUTDOWN_CANCELLED | El apagado se cancela y el estado de energía vuelve al estado normal. |
ESTADO_SHUTDOWN_ENTER | Se espera que las aplicaciones se limpien y estén listas para cerrarse. |
STATE_POST_SHUTDOWN_ENTER | Se han completado los preparativos para el apagado y VMCU está lista para apagarse. Ingrese al estado de apagado. |
STATE_PRE_SHUTDOWN_PREPARE | Se solicita el proceso de cierre pero CPMS aún no inicia el proceso. La pantalla y el audio siguen encendidos. |
STATE_SHUTDOWN_PREPARE | El modo Garaje puede ejecutarse durante el período. |
STATE_SUSPEND_ENTER | Se espera que las aplicaciones se limpien y estén listas para suspenderse en RAM. |
STATE_POST_SUSPEND_ENTER | Se completaron los preparativos para la suspensión a RAM y VMCU está lista para la suspensión a RAM. Ingrese al estado de suspensión. |
STATE_SUSPEND_EXIT | Despertar de una suspensión o reanudar de una suspensión cancelada. |
ESTADO_HIBERNACIÓN_ENTER | Se espera que las aplicaciones se limpien y estén listas para la hibernación. |
STATE_POST_HIBERNATION_ENTER | Los preparativos para la hibernación se han completado y VMCU está listo para la hibernación Ingrese al estado de hibernación. |
ESTADO_HIBERNACIÓN_EXIT | Despierte de la hibernación o reanude una hibernación cancelada. |
ESTADO_WAIT_FOR_VHAL | El sistema se está iniciando, pero está esperando establecer comunicación con el VHAL antes de pasar al estado ON. |
Cancelación del registro de CarPowerStateListener
Para cancelar el registro de todos los objetos de escucha registrados en CPM, llame al método clearListener
:
powerManager.clearListener();
Integración del sistema en su implementación de Android
Los integradores son responsables de los siguientes elementos:
- Implementación de la interfaz del kernel para suspender Android.
- Implementando las funciones VHAL para:
- Propagar el inicio de suspensión o apagado del automóvil a Android.
- Envía el mensaje de apagado listo desde Android al coche.
- Inicie el apagado o suspensión de Android a través de la interfaz del kernel de Linux.
- Asegúrese de que todas las fuentes de activación estén desactivadas cuando el dispositivo esté suspendido.
- Asegúrese de que las aplicaciones se cierren lo suficientemente rápido como para no posponer indefinidamente el proceso de cierre.
- Asegúrese de que el BSP encienda (o apague) los componentes del dispositivo de acuerdo con la política de energía para no bloquear la suspensión o la hibernación.
Interfaz del núcleo: /sys/power/state
AAOS coloca un dispositivo en modo de suspensión cuando una aplicación o servicio escribe mem
para suspender en RAM o disk
para suspender en disco en un archivo ubicado en /sys/power/state
. El integrador debe proporcionar una función que supervise este archivo y ponga a Linux en estado de suspensión de energía. Esta función puede enviar un GPIO a la VMCU para notificarle que el dispositivo se ha apagado por completo. El integrador también es responsable de eliminar cualquier condición de carrera entre que VHAL envíe el mensaje final a la VMCU y que el sistema entre en modo de suspensión o apagado.
Responsabilidad VHAL
VHAL proporciona una interfaz entre la red del vehículo y Android. El VHAL:
- Propaga el inicio de suspensión o apagado del automóvil a Android.
- Envía el mensaje de apagado listo desde Android al automóvil.
- Inicia el apagado o suspensión de Android a través de la interfaz del kernel de Linux.
Cuando el CPMS informa al VHAL que está listo para apagarse, el VHAL envía el mensaje de apagado listo a la VMCU. Normalmente, los periféricos integrados en el chip, como UART, SPI y USB, transmiten el mensaje. Una vez que se ha enviado el mensaje, el CPMS llama al comando del kernel para suspender o apagar el dispositivo. Antes de hacerlo, el VHAL o el BSP pueden alternar un GPIO para indicarle a la VMCU que es seguro desconectar la alimentación del dispositivo.
El VHAL debe admitir las siguientes propiedades, que controlan la administración de energía a través del VHAL:
Nombre | Descripción |
---|---|
AP_POWER_STATE_REPORT | Android informa las transiciones de estado a VMCU con esta propiedad, utilizando los valores de enumeración VehicleApPowerStateReport. |
AP_POWER_STATE_REQ | La VMCU usa esta propiedad para indicarle a Android que realice la transición a diferentes estados de energía, utilizando los valores de enumeración VehicleApPowerStateReq. |
AP_POWER_STATE_REPORT
Utilice esta propiedad para informar el estado actual de administración de energía de Android. Esta propiedad contiene dos números enteros:
-
int32Values[0]
: VehicleApPowerStateReport enumeración del estado actual. -
int32Values[1]
: tiempo en milisegundos para posponer, suspender o apagar. El significado de este valor depende del primer valor.
El primer valor puede tomar uno de los siguientes valores. VehicleApPowerStateReport.aidl
contiene descripciones más específicas, que se almacenan en hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle
.
Nombre del valor | Descripción | Segundo valor |
---|---|---|
ESPERA_FOR_VHAL | AP está comenzando y necesita establecer comunicación con VHAL. | |
PROFUNDO_SLEEP_ENTRY | AP está entrando en el estado de sueño profundo. La VMCU debería volver a encender el AP después del tiempo especificado en el segundo valor. | Se debe establecer |
PROFUNDO_SLEEP_EXIT | AP está saliendo del estado de sueño profundo. | |
HIBERNACIÓN_ENTRY | AP está entrando en estado de hibernación. La VMCU debería volver a encender el AP después del tiempo especificado en el segundo valor. | Se debe establecer |
HIBERNACIÓN_SALIDA | AP está saliendo del estado de hibernación. | |
APAGADO_POSTPONE | Android no está listo para apagarse. La VMCU debe esperar el tiempo especificado en el segundo valor antes de apagar el AP. Android puede solicitar un aplazamiento adicional mediante la emisión de informes SHUTDOWN_POSTPONE adicionales. | Se debe establecer |
APAGADO_PREPARE | Android se está preparando para cerrarse. | Se debe establecer |
APAGADO_START | AP está listo para cerrar. La VMCU debería volver a encender el AP después del tiempo especificado en el segundo valor. (No es necesario que la VMCU admita la función de encendido programado). | Se debe establecer |
APAGADO_CANCELADO | Android está dejando de prepararse para apagarse y procederá a WAIT_FOR_VHAL. | |
EN | Android funciona normalmente. |
El estado se puede configurar de forma autónoma o en respuesta a una solicitud a través de la VMCU.
AP_POWER_STATE_REQ
La VMCU envía esta propiedad para realizar la transición de Android a un estado de energía diferente y contiene dos números enteros:
-
int32Values[0]
: valor de enumeraciónVehicleApPowerStateReq
, que representa el nuevo estado al que realizar la transición. -
int32Values[1]
: valor de enumeraciónVehicleApPowerStateShutdownParam
. Este valor se envía solo para un mensajeSHUTDOWN_PREPARE
y transmite a Android las opciones que contiene.
El primer valor entero representa el nuevo estado al que transitará Android. La semántica se define en VehicleApPowerStateReq.aidl
y se proporciona a continuación:
Nombre del valor | Descripción |
---|---|
EN | AP debería comenzar a funcionar en pleno funcionamiento. |
APAGADO_PREPARE | La AP debería prepararse para cerrar. El segundo valor indica si el AP puede posponer el apagado y si el AP debe esperar apagarse o entrar en suspensión profunda. |
CANCELAR_APAGAR | La AP debería dejar de prepararse para cerrar y prepararse para continuar. |
FINALIZADO | La AP ahora será cerrada o suspendida. |
VehicleApPowerStateShutdownParam
se define en VehicleApPowerStateShutdownParam.aidl
. Esta enumeración tiene estos elementos:
Nombre del valor | Descripción |
---|---|
PUEDE DORMIR | AP puede entrar en sueño profundo en lugar de apagarse por completo. Se permite posponer. |
PUEDE HIBERNAR | AP puede entrar en hibernación en lugar de apagarse por completo. Se permite posponer. |
APAGADO_ONLY | AP debería cerrarse. Se permite posponer. No se permite el sueño profundo. |
DORMIR_INMEDIATAMENTE | AP puede entrar en modo de sueño profundo, pero debe dormir o apagarse inmediatamente. No se permite posponer. |
HIBERNAR_INMEDIATAMENTE | El AP puede entrar en suspensión en disco, pero debe hibernar o apagarse inmediatamente. No se permite posponer. |
APAGADO_IMMEDIATAMENTE | AP debe cerrarse inmediatamente. No se permite posponer. No se permite el sueño profundo. |
fuentes de estela
El integrador debe desactivar las fuentes de activación apropiadas cuando el dispositivo está en modo de suspensión. Las fuentes de activación comunes incluyen latidos del corazón, módem, Wi-Fi y Bluetooth. La única fuente de activación válida debe ser una interrupción de la VMCU para activar el SoC. Esto supone que la VMCU puede escuchar el módem en busca de eventos de activación remota (como el arranque remoto del motor). Si esta funcionalidad se envía al AP, entonces se debe agregar otra fuente de activación para dar servicio al módem.
Aplicaciones
Los OEM deben tener cuidado al escribir aplicaciones para que puedan cerrarse rápidamente y no posponer el proceso indefinidamente.
Apéndice
Directorios en el árbol del código fuente.
Contenido | Directorio |
---|---|
Código relacionado con CarPowerManager. | packages/services/Car/car-lib/src/android/car/hardware/power |
CarPowerManagementService, etc. | packages/services/Car/service/src/com/android/car/power |
Servicios relacionados con VHAL, como VehicleHal y HAlClient . | packages/services/Car/service/src/com/android/car/hal |
Interfaz VHAL y definiciones de propiedades. | hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle/ |
Aplicación de muestra para dar una idea sobre CarPowerManager | packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink |
Diagrama de clase
Este diagrama de clases muestra las clases e interfaces de Java en el sistema de administración de energía:
Figura 4. Diagrama de clases de potencia.
Relación de objeto
La Figura 5 ilustra qué objetos tienen referencias a otros objetos. Un borde significa que el objeto de origen contiene una referencia al objeto de destino. Por ejemplo, VehicleHAL tiene una referencia a un objeto PropertyHalService.
Figura 5. Diagrama de referencia de objetos.