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:
suspend()
y shutdown()
.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:
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:
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:
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:
- Para adquirir la instancia de CPM, llama a la API de Car.
- 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ónVehicleApPowerStateReq
, que representa el nuevo estado al que se hace la transición.int32Values[1]
: Es el valor de enumeraciónVehicleApPowerStateShutdownParam
. Esta valor se envía solo para un mensajeSHUTDOWN_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:
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.
Figura 5: Diagrama de referencia de objeto.