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 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:

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:

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:

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.

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:

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:

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 .

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ón VehicleApPowerStateReq , que representa el nuevo estado al que 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 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 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.

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.