Administración de energía

Para admitir la administración de energía específica de vehículo, Android proporciona un CarPowerManagementService servicio y un CarPowerManager.

La unidad de control principal del vehículo (VMCU) activa las transiciones de estado. Para comunicarte con la VMCU, los integradores deben implementar varios componentes. Los integradores son responsables de integrar con la capa de abstracción de hardware del vehículo (VHAL) y la implementación del kernel Los integradores son también es responsable de inhabilitar las fuentes de activación y garantizar que no se pospongan los cierres. indefinidamente.

Terminología

Estos términos se usan en todo el documento:

procesador de apps (AP)
Parte del sistema en chip (SoC).
Paquete de asistencia para la placa (BSP)
La capa de software que contiene controladores de dispositivo y firmware de inicio específicos de hardware que permiten que un sistema operativo incorporado funcione en un entorno de hardware determinado (una motherboard) integrado en el sistema operativo incorporado.
CarPowerManager (CPM)
Expone una API para que las apps se registren para los cambios de estado de energía.
CarPowerManagementService (CPMS)
Implementa la máquina de estado de energía del vehículo, interactúa con VHAL y realiza las últimas llamadas al suspend() y shutdown().
CarPowerPolicyDaemon (CPPD)
Expone las interfaces del AIDL para procesos nativos a fin de registrar el objeto de escucha de la política de energía.
Entrada o salida de uso general (GPIO)
Un pin de señal digital de uso general.
capa de abstracción de hardware (HAL)
Es una capa de software con la que deben interactuar todos los demás módulos de nivel superior para acceder. la funcionalidad del hardware.
hibernar
También se lo conoce como Suspensión en el disco (S2D/S4). El SoC se coloca en el modo de alimentación de S4. (hibernación), y el contenido de la memoria RAM se escribe en medios no volátiles (como flash o disco), y la totalidad del Si el sistema está apagado.
procesador multimedia (MP)
Consulta sistema en chip (SoC).
circuito integrado de administración de energía (PMIC)
Chip usado para administrar los requisitos de alimentación del sistema host.
sistema en chip (SoC)
Procesador principal que ejecuta AAOS, generalmente suministrados por fabricantes como Intel, MediaTek, Nvidia, Qualcomm, Renesas y Texas Instruments.
suspend
También se denomina Suspensión a RAM (S2R o STR). El SoC se coloca en el modo de energía de S3. mientras que la CPU permanece apagada, mientras que la RAM permanece encendida.
HAL de vehículo (VHAL)
La API de Android que se usa para interactuar con la red del vehículo. El OEM o socio de nivel 1 es de escribir este módulo. La red del vehículo puede usar cualquier capa física (como CAN, LIN, MOST y Ethernet). El VHAL abstrae esta red de vehículos para permitir que AAOS interactúe con el vehículo.
Procesador de interfaz del vehículo (VIP)
Consulta el MCU del vehículo.
Unidad de control principal de vehículo (VMCU)
El microcontrolador que proporciona la interfaz entre la red del vehículo y el SoC. El SoC se comunica con la VMCU a través de señales USB, UART, SPI y GPIO.

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é y los módulos implementan el sistema de administración de energía. Este material también describe cómo funcionan y cómo suelen ocurrir las transiciones de estado.

Máquina para estado de energía del automóvil

AAOS utiliza una máquina de estados para representar el estado de energía del AP. El estado proporciona los estados que se ilustran a continuación:

Máquina para estado de energía del automóvil

Figura 1: Máquina para estado de energía del automóvil

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

  • Suspensión en 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.
  • Espera a VHAL. Cuando el conductor interactúa con el vehículo, por ejemplo, se abre una puerta, la VMCU aplica energía al SoC. AAOS se reanuda desde la suspensión a la RAM y, luego, ingresa "Esperar a la VHAL", donde espera la coordinación con el VHAL.
  • Activado. El VHAL le indica a AAOS que entre en estado de encendido. En este estado, El AAOS está funcionando en su totalidad y está interactuando con el controlador.
  • Preparación para el apagado. Cuando el conductor termina de conducir, el VHAL le indica AAOS para ingresar a Cierre de preparación. En este estado, la pantalla y el audio están apagados y AAOS no interactuar con el conductor. El sistema Android sigue ejecutándose y puede actualizar aplicaciones y el sistema Android. Cuando se completan actualizaciones, si las hay, el sistema Android ingresa Esperar por VHAL. Finalizar.
  • Espera a que finalice la VHAL. En este punto, AAOS informa a la VHAL que que está listo para apagarse. Se espera que la VMCU coloque el SoC en modo de suspensión profunda y quite la energía del procesador de la app. Entonces, AAOS queda en estado de suspensión a 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:

Nombre del módulo Descripción
CarPowerManager API de Java o C++.
CarPowerManagementService Coordina las transiciones del estado de energía.
CarPowerPolicyDaemon Se comunica con los clientes nativos de la política de energía.
HAL de vehículo Interfaz de la VMCU.
Kernel Suspender a la RAM o la implementación del disco.

En el kernel, se implementa la función de hibernación/sueño profundo (que suspende Android en la memoria RAM o el disco). Esta función se expone al espacio del usuario como un archivo especial ubicado en /sys/power/state AAOS se suspende escribiendo mem o disk a este archivo.

Los CPMS coordinan el estado de energía con otros servicios y HAL. Los CPMS implementan el estado máquina descrita anteriormente y envía notificaciones a cada observador cuando se produce una transición de que ocurra. Este servicio también usa la 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 un cambio en la política de energía. notificaciones a los objetos de escucha nativos.

Algunas propiedades se definen en el VHAL. Para comunicarse con la VMCU, los CPMS realizan operaciones de lectura y escritura estas propiedades. Las apps pueden usar la interfaz definida en el CPM para supervisar el estado de energía. cambios. Esta interfaz también permite que las apps registren power policy. Esta API se puede se llama desde Java y tiene anotaciones con la API @hide / @System, lo que significa que está disponible para solo para aplicaciones con privilegios. La relación entre estos módulos, apps y servicios se ilustra a continuación:

Diagrama de referencia de los componentes de energía

Figura 2: Diagrama de referencia de componentes de energía.

Secuencia de mensajes

En la sección anterior, se describieron los módulos que componen el sistema de administración de energía. Esta utiliza los ejemplos de ingresar al sueño profundo y salir del sueño profundo para explicar cómo se módulos y aplicaciones comunican lo siguiente:

Ingresar al 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 los CPM a través de la VHAL. El CPM cambia el estado a SHUTDOWN PREPARE y transmite esta transición de estado a todos los observadores (las aplicaciones y los servicios que supervisan 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 CPM. El El método onStateChanged() para las apps o los servicios se invoca de forma síncrona en el Método onStateChanged() de CPM. La mayoría de las apps y servicios deben completarse su preparación antes de regresar de esta llamada. Los servicios con privilegios pueden continuar con sus preparaciones de forma asíncrona después de mostrar PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER, POST_SUSPEND_ENTER En este caso, el servicio con privilegios que debe llamar a complete() en el objeto CompletablePowerStateChangeFuture proporcionado. cuando termine su preparación. Ten en cuenta que la preparación asíncrona no está permitida para SHUTDOWN_PREPARE Antes de enviar DEEP_SLEEP_ENTRY a la VHAL, los CPM envía de forma periódica solicitudes para posponer el cierre a la VHAL.

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

La secuencia descrita anteriormente se ilustra a continuación:

Ingresar al sueño profundo

Figura 3: Entra al sueño profundo.

Interfaces de programación que proporciona el CPM

En esta sección, se describe la API de Java que proporciona el CPM para los servicios y las apps 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 proporcionadas por el CPM:

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

Cómo crear 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 un 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 energía implementando CarPowerManager.CarPowerStateListener Esta interfaz define un método onStateChanged(), que es una función de devolución de llamada que se invoca cuando el estado de energía de CPMS un cambio. 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 indicar a este objeto de escucha que supervise una transición de estado de energía, crea una ejecución nueva 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 energía, el método onStateChanged() del objeto de escucha se invoca 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 el siguiente tabla:

Nombre Descripción
ACTIVADO_ESTADO Ingresa el estado de activado. El sistema está completamente operativo.
APAGADO_DE_ESTADO_CANCELADO Se cancela el apagado y el estado de energía vuelve al estado normal.
ESTADO_APAGADO_INTRO se espera que se limpien y estén listas para cerrarse.
POST_DE_estado_DE_APAGAR_INTRO_ENTERO Se completaron los preparativos para el cierre y la VMCU está lista para el cierre. Ingresa el estado de apagado.
ESTADO_PREPARADO_APAGAR_PREPARAR Se solicita el proceso de apagado, pero los CPM aún no lo inician. La pantalla y el audio son Sigue encendido
PREPARAR_APAGAR_ESTADO Es posible que el Modo garaje se ejecute durante el período.
STATE_SUSPEND_ENTER se espera que las apps se limpien y estén listas para la suspensión en la RAM.
STATE_POST_SUSPEND_ENTER Se completaron los preparativos para la suspensión a la RAM y la VMCU está lista para la suspensión a la RAM. Ingresa el el estado de suspensión.
STATE_SUSPEND_EXIT Activar desde una suspensión o reanudar desde una suspensión cancelada.
ESTADO_HIBERNATION_ENTER se espera que se limpien y estén listas para hibernar.
POST_HIBERNATION_ESTADO Se completaron los preparativos para la hibernación y la VMCU está lista para esta acción de hibernación.
ESTADO_DE_HIBERNATION_SALIR Despierta del estado de hibernación o reanuda una hibernación cancelada.
ESTADO_DE_ESPERA_PARA_VHAL El sistema se está iniciando, pero está esperando establecer comunicación con la VHAL antes de el estado ON.

Anulación del registro de CarPowerStateListener

Para cancelar el registro de todos los objetos de escucha registrados en CPM, llama a clearListener. método:

powerManager.clearListener();

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

Los integradores son responsables de los siguientes elementos:

  • Cómo implementar la interfaz del kernel para suspender Android.
  • Implementa las funciones de VHAL para lo siguiente:
    • Propagar el inicio de la suspensión o el cierre del vehículo a Android
    • Envía el mensaje de apagado de Android al vehículo.
    • 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é en suspensión.
  • Asegúrate de que las apps se cierren lo suficientemente rápido para no posponer de manera indefinida. el proceso de apagado.
  • Asegúrate de que el BSP encienda (o apague) los componentes del dispositivo según la política de energía para lo siguiente: no bloquear la suspensión ni la hibernación

Interfaz de kernel: /sys/power/state

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

Responsabilidad de VHAL

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

  • Propaga el inicio de la suspensión o el cierre del vehículo a Android.
  • Envía el mensaje de apagado de Android al vehículo.
  • Inicia el cierre o la suspensión de Android a través de la interfaz del kernel de Linux.

Cuando los CPM informan al VHAL que está listo para apagarse, el VHAL envía el cierre listo. a la VMCU. Normalmente, los periféricos en el chip, como UART, SPI y USB, transmiten la mensaje. Una vez que se envía el mensaje, el CPM llama al comando del kernel para suspender o apagar. el dispositivo. Antes de hacerlo, el VHAL o BSP pueden activar o desactivar un GPIO para indicarle a la VMCU que es seguro para desconectar la alimentación del dispositivo.

El VHAL debe admitir las siguientes propiedades, que controlan la administración de energía mediante el VHAL:

Nombre Descripción
INFORME_DE_ESTADO_DE_POTENCIA AP Android informa las transiciones de estado a la VMCU con esta propiedad usando Valores de enumeración de VehicleApPowerStateReport.
AP_POWER_STATE_REQ La VMCU usa esta propiedad para indicar a Android que haga la transición a diferentes estados de energía, con Valores de enumeración VehicleApPowerStateReq.

INFORME_DE_ESTADO_DE_POTENCIA AP

Usa esta propiedad para informar el estado actual de administración de baterí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 que se debe 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 la hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle

Nombre del valor Descripción Segundo valor
ESPERA_PARA_VHAL Se está iniciando el AP y debe establecerse comunicación con la VHAL.
ENTRADA_DE_SUEÑO_FUNTO El PA entra en el estado de sueño profundo. La VMCU debería volver a activar el PA después de ese momento especificadas en el segundo valor. Se debe establecer
SALIR_PENSO El PA está saliendo del estado de sueño profundo.
ENTRADA_HIBERNATION El AP entra en el estado de hibernación. La VMCU debería volver a activar el PA después de ese momento especificadas en el segundo valor. Se debe establecer
HIBERNATION_SALIR El AP sale del estado de hibernación.
APAGAR_DESPUÉS Android no está listo para apagarse. La VMCU debe esperar el tiempo especificado en el segundo valor antes de apagar el PA. Android puede solicitar una postergación adicional emitiendo Informes SHUTDOWN_POSTPONE. Se debe establecer
APAGAR_PREPARAR Android se está preparando para apagarse. Se debe establecer
APAGAR_START El PA está listo para apagarse. La VMCU debe volver a activar el PA luego del tiempo especificado en la segundo valor. (no se requiere la VMCU para admitir la función de activación temporizada). Se debe establecer
APAGADO_CANCELADO Android deja de prepararse para apagarse y procederá a WAIT_FOR_VHAL.
ACTIVADA Android se ejecuta 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]: Es el valor de enumeración VehicleApPowerStateReq, que representa el nuevo estado al que se hace la transición.
  • int32Values[1]: Es el valor de enumeración VehicleApPowerStateShutdownParam. Esta valor se envía solo para un mensaje SHUTDOWN_PREPARE y transmite a Android la opciones que contiene.

El primer valor entero representa el nuevo estado al que transita Android. La semántica se definen en VehicleApPowerStateReq.aidl y se proporcionan a continuación:

Nombre del valor Descripción
ACTIVADA El AP debería comenzar a funcionar por completo.
APAGAR_PREPARAR El AP debería prepararse para el cierre. El segundo valor indica si el PA puede posponer apagar y determinar si el AP debería apagarse o entrar en modo de suspensión profunda.
CANCELAR_APAGAR El AP debería dejar de prepararse para apagar el sistema y comenzar a encenderlo.
LISTO Ahora, se cerrará o suspenderá el AP.

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

Nombre del valor Descripción
CANNOT TRANSLATE El PA puede entrar en modo de suspensión profunda en lugar de apagarse por completo. Se permite la postergación.
CANNOT TRANSLATE El PA puede entrar en hibernación en lugar de apagarse por completo. Se permite la postergación.
SOLO_APAGADO El PA debería apagarse. Se permite la postergación. No se permite el sueño profundo.
SUEÑO_INMEDIATO El PA puede entrar en modo de suspensión profunda, pero debe suspenderse o apagarse de inmediato. Posponer es no se permite.
HIBERNATE_INMEDIATO El PA puede entrar en modo de suspensión en el disco, pero debe entrar en hibernación o apagarse de inmediato. Posponer es no se permite.
APAGADO DE INMEDIATO El PA debe apagarse de inmediato. No se permite posponerlo. No se permite el sueño profundo.

Fuentes de activación

El integrador debe inhabilitar las fuentes de activación adecuadas cuando el dispositivo está en modo de suspensión. Las fuentes de activación comunes incluyen la señal de monitoreo de funcionamiento, el módem, el Wi-Fi y el Bluetooth. La única fuente de activación válida debe puede ser una interrupción de la VMCU para activar el SoC. Se da por sentado que la VMCU puede escuchar el tráfico para eventos de activación remota (como inicio remoto de motor). Si esta funcionalidad se envía al AP, luego, se debe agregar otra fuente de activación para reparar el módem.

Apps

Los OEMs deben tener cuidado cuando escriban apps para que puedan cerrarse rápidamente y no posponerse. el proceso indefinidamente.

Apéndice

Directorios en el árbol del código fuente

Content Directorio
Código relacionado con CarPowerManager packages/services/Car/car-lib/src/android/car/hardware/power
CarPowerManagementService, etcétera. packages/services/Car/service/src/com/android/car/power
Servicios que trabajan con VHAL, como VehicleHal y HAlClient. packages/services/Car/service/src/com/android/car/hal
Interfaz de VHAL y definiciones de propiedades. hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle/
App de ejemplo para proporcionar una idea sobre CarPowerManager packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink

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:

Diagrama de clase de potencia

Figura 4: Diagrama de clase de potencia.

Relación de objeto

En la figura 5, se ilustran los objetos que tienen referencias a otros objetos. Una arista significa que el objeto de origen contiene una referencia al objeto de destino. Por ejemplo, VehicleHAL tiene un a un objeto PropertyHalService.

Diagrama de referencia del objeto

Figura 5: Diagrama de referencia de objeto.