Administración de energía

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:

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:

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:

1. Para adquirir la instancia de CPM, llame a Car API.
2. 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:

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:

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 .

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ón VehicleApPowerStateReq , que representa el nuevo estado al que se realizará la transición.
• int32Values[1] : Valor de enumeración VehicleApPowerStateShutdownParam . Este valor se envía solo para un mensaje SHUTDOWN_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:

VehicleApPowerStateShutdownParam se define en VehicleApPowerStateShutdownParam.aidl . Esta enumeración tiene estos elementos:

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

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