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 son activadas por 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 deshabilitar las fuentes de activación y garantizar que los cierres 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 potencia del automóvil
AAOS utiliza una máquina de estado para representar el estado de energía del AP. La máquina de estado proporciona los estados ilustrados a continuación:
Figura 1. Máquina de estado de potencia 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 alimentación se mantiene en la RAM del SoC.
- Espere a VHAL. Cuando el conductor interactúa con el vehículo, por ejemplo, al abrir una puerta, la VMCU aplica energía al SoC. AAOS se reanuda desde Suspender a RAM e ingresa a Esperar a VHAL, donde espera la coordinación con VHAL.
- En. El VHAL le dice a AAOS que ingrese al estado de encendido. En este estado, AAOS está completamente funcionando e interactuando con el controlador.
- Apagar Preparar. Cuando el conductor termina de conducir, el VHAL le dice a AAOS que ingrese Shutdown Prepare. En este estado, la pantalla y el audio están apagados y AAOS no interactúa con el controlador. El sistema Android aún se está ejecutando y es gratuito para actualizar las aplicaciones y el sistema Android. Cuando se completan las actualizaciones, si las hay, el sistema Android entra en Esperar a que finalice VHAL.
- Espere a que finalice VHAL. En este punto, AAOS informa al VHAL que está listo para apagarse. Se espera que la VMCU coloque el SoC en suspensión profunda y desconecte la alimentación del procesador de aplicaciones. 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 |
---|---|
CarPowerManager | API Java o C++. |
Servicio de administración de energía del automóvil | Coordina las transiciones de estado de energía. |
CochePoderPolíticaDemonio | Se comunica con los clientes de políticas de energía nativos. |
HAL del vehículo | Interfaz a la VMCU. |
Núcleo | Suspender a RAM o implementación de disco. |
La función de suspensión profunda/hibernación (suspensión de Android a 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 escribiendo 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 estado 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 cambio de política de energía a los oyentes nativos.
Algunas propiedades se definen en el 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 escuchas de políticas de energía . Esta API se puede llamar desde Java y se anota con @hide / @System API, lo que significa que solo está disponible 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 entrar en suspensión profunda y salir de suspensión profunda para explicar cómo se comunican los módulos y las aplicaciones:
Entra en el sueño profundo
Solo 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 de la 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()
de 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 asíncrona 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
provisto cuando finaliza su preparación. Tenga en cuenta que la preparación asincrónica no está permitida para SHUTDOWN_PREPARE
. Antes de enviar DEEP_SLEEP_ENTRY
a VHAL, el CPMS envía periódicamente solicitudes de posposición de apagado a 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 suspenderse. El CPMS también llama a su método de suspensión, que suspende el kernel.
La secuencia descrita anteriormente se ilustra a continuación:
Figura 3. Entrar en el sueño profundo
Interfaces de programación proporcionadas por CPM
Esta sección describe la API de Java proporcionada por el CPM para aplicaciones y servicios del sistema. Esta API permite que el software del sistema:
- Supervise los cambios de estado de energía en el AP.
- Aplicar políticas de energía.
Utilice estos pasos para llamar a las API proporcionadas por el CPM:
- Para adquirir la instancia de CPM, llame a Car API.
- Llame al método apropiado en el objeto creado en el Paso 1.
Creación de 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 los servicios del sistema pueden recibir notificaciones de cambio de estado de energía al implementar CarPowerManager.CarPowerStateListener
. Esta interfaz define un método onStateChanged()
, que es una función de devolución de llamada que se invoca cuando 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 indicar a este objeto de escucha que supervise una transición de estado de energía, cree un nuevo subproceso de ejecución y registre el escucha y este subproceso 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_EN | Introduzca el estado activado. El sistema está en pleno funcionamiento. |
ESTADO_APAGADO_CANCELADO | El apagado se cancela y el estado de energía vuelve al estado normal. |
ESTADO_APAGADO_ENTRAR | Se espera que las aplicaciones se limpien y estén listas para cerrarse. |
ESTADO_POST_APAGAR_ENTRAR | Se completaron los preparativos para el apagado y la VMCU está lista para apagarse. Ingrese al estado de apagado. |
ESTADO_PRE_APAGAR_PREPARAR | Se solicita el proceso de apagado, pero CPMS aún no inicia el proceso. La pantalla y el audio siguen encendidos |
ESTADO_APAGADO_PREPARAR | El modo de garaje puede funcionar durante el período. |
ESTADO_SUSPEND_ENTRAR | Se espera que las aplicaciones se limpien y estén listas para la suspensión a RAM. |
ESTADO_POST_SUSPEND_ENTER | Se completaron los preparativos para suspender a RAM y VMCU está listo para suspender a RAM. Ingrese al estado de suspensión. |
ESTADO_SUSPEND_SALIR | Despertar de una suspensión o reanudar una suspensión cancelada. |
ESTADO_HIBERNACIÓN_ENTRAR | Se espera que las aplicaciones se limpien y estén listas para la hibernación. |
ESTADO_POST_HIBERNATION_ENTER | Se completaron los preparativos para la hibernación y la VMCU está lista para la hibernación. Ingrese al estado de hibernación. |
ESTADO_HIBERNACIÓN_SALIDA | Despierte de la hibernación o reanude una hibernación cancelada. |
ESTADO_ESPERA_DE_VHAL | El sistema se está iniciando, pero esperando establecer comunicación con el VHAL antes de pasar al estado ON. |
Cancelación del registro de CarPowerStateListener
Para anular 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:
- Implementando la interfaz del kernel para suspender Android.
- Implementando las funciones VHAL para:
- Propague el inicio de suspensión o apagado del automóvil a Android.
- Envíe el mensaje de apagado listo desde Android al automóvil.
- 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 deshabilitadas cuando el dispositivo esté suspendido.
- Asegúrese de que las aplicaciones se apaguen lo suficientemente rápido para no posponer indefinidamente el proceso de apagado.
- 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. Esta función puede enviar un GPIO a la VMCU para notificar a la VMCU que el dispositivo se apagó por completo. El integrador también es responsable de eliminar cualquier condición de carrera entre el envío de VHAL del mensaje final a la VMCU y el sistema que entra en modo de suspensión o apagado.
responsabilidad VHAL
El 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. Por lo general, los periféricos en 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 la 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 haga la transición a diferentes estados de energía, usando los valores de enumeración VehicleApPowerStateReq. |
AP_POWER_STATE_REPORT
Use esta propiedad para informar sobre el estado actual de administración de energía de Android. Esta propiedad contiene dos enteros:
-
int32Values[0]
: enumeración VehicleApPowerStateReport del estado actual. -
int32Values[1]
: tiempo en milisegundos para posponer, dormir 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_PARA_VHAL | El AP se está iniciando y necesita establecer comunicación con el VHAL. | |
DEEP_SLEEP_ENTRY | AP está entrando en el estado de sueño profundo. La VMCU debe volver a encender el AP después del tiempo especificado en el segundo valor. | Se debe establecer |
PROFUNDO_SLEEP_SALIR | AP está saliendo del estado de sueño profundo. | |
HIBERNACIÓN_ENTRADA | AP está entrando en el estado de hibernación. La VMCU debe volver a encender el AP después del tiempo especificado en el segundo valor. | Se debe establecer |
HIBERNACIÓN_SALIR | 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 emitiendo informes SHUTDOWN_POSTPONE adicionales. | Se debe establecer |
APAGADO_PREPARAR | Android se está preparando para apagarse. | Se debe establecer |
APAGADO_START | AP está listo para apagarse. La VMCU debe volver a encender el AP después del tiempo especificado en el segundo valor. (La VMCU no es necesaria para admitir la función de encendido temporizado). | Se debe establecer |
APAGADO_CANCELADO | Android está dejando de prepararse para apagarse y procederá a WAIT_FOR_VHAL. | |
EN | Android funciona con normalidad. |
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 hacer 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 se 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 debe transitar Android. La semántica se define en VehicleApPowerStateReq.aidl
y se proporciona a continuación:
Nombre del valor | Descripción |
---|---|
EN | El AP debería comenzar a funcionar por completo. |
APAGADO_PREPARAR | El AP debe prepararse para apagarse. 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 | El AP debe dejar de prepararse para apagarse y prepararse para ENCENDERSE. |
FINALIZADO | El AP ahora se cerrará o suspenderá. |
VehicleApPowerStateShutdownParam
se define en VehicleApPowerStateShutdownParam.aidl
. Esta enumeración tiene estos elementos:
Nombre del valor | Descripción |
---|---|
PUEDE DORMIR | AP puede entrar en suspensión profunda 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_SÓLO | AP debe cerrarse. Se permite posponer. No se permite el sueño profundo. |
DORMIR_INMEDIATAMENTE | AP puede entrar en suspensión profunda, pero debe dormir o apagarse inmediatamente. No se permite posponer. |
HIBERNATE_INMEDIATAMENTE | AP puede entrar en suspensión a disco, pero debe hibernar o apagarse inmediatamente. No se permite posponer. |
APAGADO_INMEDIATAMENTE | El AP debe cerrarse inmediatamente. No se permite posponer. No se permite el sueño profundo. |
Fuentes de estela
El integrador debe deshabilitar las fuentes de activación adecuadas 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 de 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 la VHAL, como VehicleHal y HAlClient . | packages/services/Car/service/src/com/android/car/hal |
Definiciones de propiedades e interfaz VHAL. | hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle/ |
Aplicación de muestra para dar una idea sobre el 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 5. Diagrama de clases de potencia
relación de objeto
El siguiente gráfico 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 6. Diagrama de referencia de objetos