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.

La unidad de control principal del vehículo (VMCU) activa las transiciones de estado. 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 inhabilitar las fuentes de activación y garantizar que las desactivaciones no se pospongan de forma indefinida.

Terminología

En este documento, se utilizan los siguientes términos:

Diseño de sistemas

En esta sección, se describe cómo el AAOS representa el estado de energía del procesador de la app y qué módulos implementan el sistema de administración de energía. En este material, también se describe cómo funcionan estos módulos juntos y cómo suelen ocurrir las transiciones de estado.

Máquina de estado de energía del vehículo

El AAOS usa 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 estado de la alimentación del vehículo.

Las transiciones más comunes se destacan en azul. Estos son los estados y las transiciones comunes:

• Suspender en la RAM El vehículo y el SoC están apagados. No se ejecuta ningún código. Se mantiene la energía en la RAM del SoC.
• Espera a que se establezca la VHAL. Cuando el conductor interactúa con el vehículo, por ejemplo, abriendo una puerta, la VMCU aplica energía al SoC. El AAOS se reanuda desde la suspensión en la RAM y entra en Espera de VHAL, donde espera la coordinación con el VHAL.
• Activado. El VHAL le indica al AAOS que ingrese al estado de encendido. En este estado, el AAOS se ejecuta por completo y también interactúa con el controlador.
• Preparación para el apagado. Cuando el conductor termina de conducir, el VHAL le indica al 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 sigue ejecutándose y puede actualizar las apps y el sistema Android sin problemas. Cuando se completan las actualizaciones, si las hay, el sistema Android entra en Espera a que finalice VHAL.
• Espera 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 modo de suspensión profunda y quite la alimentación del procesador de la app. Luego, el AAOS se encuentra en el estado de suspensión en la RAM, aunque no se ejecuta ningún código.

Módulos de administración de energía

El sistema de administración de energía consta de los siguientes módulos:

La función de suspensión profunda o hibernación (suspende Android en la RAM o el disco) se implementa en el kernel. Esta función se expone al espacio del usuario como un archivo especial ubicado en /sys/power/state. Para suspender el AAOS, escribe 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 todos los observadores cuando se produce una transición de estado de energía. Este servicio también usa el VHAL para enviar mensajes al hardware.

El CPPD administra la política de energía hasta que el CPMS toma el control. También envía notificaciones de cambios de política de energía a los objetos de escucha nativos.

Algunas propiedades se definen en el VHAL. Para comunicarse con el VMCU, el CPMS lee y escribe estas propiedades. Las apps pueden usar la interfaz definida en el CPM para supervisar los cambios de estado de la alimentación. Esta interfaz también permite que las apps registren objetos de escucha de la política de energía. Se puede llamar a esta API desde Java y está anototada con la API de @hide / @System, lo que significa que solo está disponible para apps con privilegios . A continuación, se ilustra la relación entre estos módulos, apps y servicios:

Figura 2: Diagrama de referencia de los componentes de alimentación.

Secuencia de mensajes

En la sección anterior, se describieron los módulos que componen el sistema de administración de energía. En esta sección, se usan los ejemplos de entrada al modo de suspensión profunda y salida del modo de suspensión profunda para explicar cómo se comunican los módulos y las apps:

Entrar en el modo de suspensión profunda

Solo la VMCU puede iniciar el modo de suspensión profunda. Una vez que se inicia el modo de suspensión profunda, 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 apps y los servicios que supervisan el CPMS) llamando al método onStateChanged() con un nuevo ID de estado proporcionado por el CPM.

El CPM media entre las apps o los servicios y los CPMS. El método onStateChanged() de las apps o servicios se invoca de forma síncrona en el método onStateChanged() del CPM. La mayoría de las apps y los servicios deben completar su preparación antes de regresar de esta llamada. Los servicios con privilegios pueden continuar sus preparaciones de forma asíncrona después de mostrar PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER y POST_SUSPEND_ENTER. En este caso, se supone que el servicio con privilegios debe llamar a complete() en el objeto CompletablePowerStateChangeFuture proporcionado cuando finaliza su preparación. Ten en cuenta que no se permite la preparación asíncrona para SHUTDOWN_PREPARE. Antes de que se envíe DEEP_SLEEP_ENTRY al VHAL, el CPMS envía solicitudes de aplazamiento del cierre de forma periódica al VHAL.

Cuando todos los objetos CPM completaron las preparaciones para el cierre, el CPMS envía AP_POWER_STATE_REPORT al VHAL, que luego notifica al VMCU que el AP está listo para suspenderse. El CPMS también llama a su método de suspensión, que suspende el kernel.

A continuación, se ilustra la secuencia que se describió anteriormente:

Figura 3: Entrar en el modo de suspensión profunda

Interfaces de programación que proporciona CPM

En esta sección, se describe la API de Java que proporciona el CPM para las apps y los servicios del sistema. Esta API permite que el software del sistema haga lo siguiente:

• Supervisa los cambios de estado de energía en el AP.
• Aplica políticas de energía.

Sigue estos pasos para llamar a las APIs que proporciona el CPM:

1. Para adquirir la instancia de CPM, llama a la API de Car.
2. Llama al método adecuado en el objeto creado en el paso 1.

Crea un objeto CarPowerManager

Para crear un objeto CPM, llama al método getCarManager() del objeto Car. Este método es una fachada que se usa para crear objetos CPM. Especifica 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 apps y los servicios del sistema pueden recibir notificaciones de cambio de estado de la batería mediante la implementación de 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. En el siguiente ejemplo, se 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 objeto de escucha que supervise una transición de estado de la batería, crea un subproceso de ejecución nuevo y registra el objeto de escucha y este subproceso en el objeto CPM:

executor = new ThreadPerTaskExecutor();
powerManager.setListener(powerListener, executor);

Cuando se cambia el estado de la batería, se invoca el método onStateChanged() del objeto del objeto de escucha con un valor para representar el nuevo estado de la batería. La asociación entre el valor real y el estado de la baterí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 objeto de escucha registrados en CPM, llama al método clearListener:

powerManager.clearListener();

Integración del sistema en tu implementación de Android

Los integradores son responsables de los siguientes elementos:

• Implementa la interfaz del kernel para suspender Android.
• Implementa las funciones de VHAL para lo siguiente:
  • Propaga el inicio de la suspensión o el apagado del automóvil a Android.
  • Envía el mensaje de apagado listo desde Android al automóvil.
  • Inicia el cierre o la suspensión de Android a través de la interfaz del kernel de Linux.
• Asegúrate de que todas las fuentes de activación estén inhabilitadas cuando el dispositivo esté suspendido.
• Asegúrate de que las apps se cierren lo suficientemente rápido como para no posponer el proceso de cierre de forma indefinida.
• Asegúrate de que el BSP encienda (o apague) los componentes del dispositivo según la política de energía para no bloquear la suspensión ni la hibernación.

Interfaz de kernel: /sys/power/state

El AAOS coloca un dispositivo en modo suspendido cuando una app o un servicio escribe mem para la suspensión en la RAM o disk para la suspensión en el disco en un archivo ubicado en /sys/power/state. El integrador debe proporcionar una función que supervise este archivo y ponga Linux en el estado de suspensión de energía. Esta función puede enviar un GPIO a la VMCU para notificarle que el dispositivo se apagó por completo. El integrador también es responsable de quitar cualquier condición de carrera entre que VHAL envíe el mensaje final a la VMCU y el sistema entre en modo de suspensión o apagado.

Responsabilidad de VHAL

El VHAL proporciona una interfaz entre la red del vehículo y Android. El VHAL:

• Propaga el inicio de la suspensión o el cierre del vehículo a Android.
• Envía el mensaje de apagado listo de Android al automóvil.
• Inicia el apagado o la 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 integrados en el chip, como UART, SPI y USB, transmiten el mensaje. Una vez que se envía el mensaje, CPMS llama al comando del kernel para suspender o apagar el dispositivo. Antes de hacerlo, el VHAL o el BSP pueden activar o desactivar un GPIO para indicarle al VMCU que es seguro quitar 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

Usa esta propiedad para informar el estado actual de la administración de energía de Android. Esta propiedad contiene dos números enteros:

• int32Values[0]: Es la enumeración VehicleApPowerStateReport del estado actual.
• int32Values[1]: Es el tiempo en milisegundos para posponer, suspender o apagar. El significado de este valor depende del primer valor.

El primer valor puede tener 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 establecer 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 que Android realice la transición a un estado de energía diferente y contiene dos números enteros:

• int32Values[0]: Es el valor de enumeración VehicleApPowerStateReq, que representa el estado nuevo al que se debe realizar la transición.
• int32Values[1]: Es el valor de la enumeración VehicleApPowerStateShutdownParam. Este valor solo se envía para un mensaje SHUTDOWN_PREPARE y transmite a Android las opciones que contiene.

El primer valor entero representa el estado nuevo al que Android debe pasar. La semántica se define en VehicleApPowerStateReq.aidl y se proporciona a continuación:

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

Fuentes de activación

El integrador debe inhabilitar las fuentes de activación adecuadas cuando el dispositivo está en modo suspendido. Las fuentes de activación comunes incluyen los latidos, el 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 para eventos de activación remotos (como el inicio remoto del motor). Si se envía esta funcionalidad al AP, se debe agregar otra fuente de activación para reparar el módem.

Apps

Los OEM deben tener cuidado de escribir apps para que se puedan apagar rápidamente y no posponer el proceso de forma indefinida.

Apéndice

Directorios en el árbol del código fuente

Diagrama de clases

En este diagrama de clases, se muestran las clases y las interfaces de Java en el sistema de administración de energía:

Figura 4: Diagrama de clases de potencia.

Relación de objetos

En la Figura 5, se ilustran los objetos que 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.