Política de energía

Para garantizar que los componentes de hardware y software (como la pantalla, el audio y la interacción de voz) se enciendan y apaguen selectivamente según sea necesario, AAOS proporciona una política de energía, que consiste en un conjunto de estados de encendido y apagado esperados para los componentes de hardware y software. . VHAL, o servicios de proveedores con privilegios del sistema, pueden aplicar una nueva política de energía cuando el estado de energía de Android cambia o cuando se cumplen las condiciones que están esperando.

Se permite aplicar una política de energía en los estados Esperar a VHAL y Encendido. En Shutdown Prepare, el modo Garaje se está ejecutando y no debe verse afectado por un cambio en el estado de energía. Aunque no se puede aplicar una política de energía normal, en Shutdown Prepare se aplica una política de energía especial , que es la política de energía del sistema denominada "sin interacción del usuario".

Estado de energía AAOS

Los dispositivos AAOS siguen este diagrama de estado de energía:

Diagrama de estado de energía AAOS

Figura 1. Diagrama de estado de energía de AAOS

Cada estado de energía se describe a continuación:

Valor Descripción
Apagado No se proporciona energía físicamente al procesador de aplicaciones (AP), a la memoria ni a los periféricos.
Espera a VHAL
  • Cuando el conductor interactúa con el vehículo (por ejemplo, abriendo una puerta), la VMCU aplica energía al AP, la memoria. y periféricos.
  • AAOS pasa de uno de tres estados (Apagado, Suspender a RAM (STR, Esperar a que finalice VHAL) y luego ingresa a Esperar a VHAL, donde espera la coordinación con VHAL.
En
  • El VHAL indica al AAOS que entre en el estado activado. En este estado, AAOS está completamente ejecutándose e interactuando con el controlador.
  • La pantalla está controlada por la política de energía y no por las llamadas de encendido/apagado de la pantalla de Android para otros factores de forma.
Apagar Preparar
  • Cuando el conductor deja 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 el AAOS no interactúa con el conductor. El sistema Android todavía está ejecutándose y puede actualizar 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 termine
  • AAOS informa a VHAL que se puede cerrar. Se espera que la unidad de microcontrolador del vehículo (VMCU) coloque el sistema en chip (SoC) en suspensión profunda y desconecte la energía del AP. AAOS se encuentra entonces en el estado STR, aunque no se está ejecutando ningún código.
  • Si VHAL no termina y el conductor regresa, la unidad principal (HU) debe pasar directamente a Esperar a VHAL.
Suspensión a RAM (STR) El vehículo y el AP están apagados, no se ejecuta ningún código y se mantiene la energía en la RAM del AP.

Arquitectura de software

La arquitectura de la política energética se ilustra a continuación y se define en la siguiente sección:

Figura 2. Arquitectura de la política energética

¿Cómo se define la política de poder?

Los implementadores definen políticas de energía en /vendor/etc/automotive/power_policy.xml , que:

  • Define la política energética.
  • Define grupos de políticas de energía, que incluyen la política de energía predeterminada y se aplican automáticamente cuando ocurren transiciones de estado de energía.
  • Anule la política de energía del sistema.

Política de poder

La política de energía es un conjunto de estados de energía esperados de los componentes de hardware y software. AAOS admite los siguientes componentes en la política energética:

  • AUDIO
  • MEDIA
  • DISPLAY_MAIN
  • DISPLAY_CLUSTER
  • DISPLAY_FRONT_PASSENGER
  • DISPLAY_REAR_PASSENGER
  • BLUETOOTH
  • WIFI
  • CELLULAR
  • ETHERNET
  • PROJECTION
  • NFC
  • INPUT
  • VOICE_INTERACTION
  • VISUAL_INTERACTION
  • TRUSTED_DEVICE_DETECTION
  • LOCATION
  • MICROPHONE
  • CPU

Grupo de políticas de energía

La política de energía predeterminada se aplica automáticamente en la transición del estado de energía que se especifica en el grupo de políticas de energía. Los proveedores pueden definir la política de energía predeterminada para Esperar a VHAL, Encendido y Esperar a que finalice VHAL (entrada en suspensión profunda o inicio de apagado).

Política de energía del sistema

AAOS solo admite una política de energía del sistema, que es "sin interacción del usuario". La política de energía del sistema se aplica cuando el dispositivo entra en modo garaje.

El comportamiento de cada componente en la política de energía del sistema se enumera en la siguiente tabla. Los implementadores pueden anular la detección de Bluetooth, NFC y dispositivos confiables en la política de energía del sistema. Las anulaciones se aplican en /vendor/etc/power_policy.xml .

Componentes Estado de energía Configurable
Audio Apagado No
Medios de comunicación Apagado No
Pantalla principal Apagado No
Grupo de visualización Apagado No
Mostrar pasajero delantero Apagado No
Display pasajero trasero Apagado No
Bluetooth Apagado SÍ
Wifi EN No
Celular EN No
Ethernet EN No
Proyección Apagado No
NFC Apagado SÍ
Aporte Apagado No
Interacción de voz Apagado No
Interacción visual Apagado No
Detección de dispositivos confiables EN SÍ
Ubicación Apagado No
Micrófono Apagado No
UPC En No

Interacción con el VHAL

El demonio de política de energía del automóvil que se ejecuta en la capa del sistema suscribe dos propiedades para escuchar las solicitudes de VHAL:

  • POWER_POLICY_REQ , el VHAL escribe el ID de la política de energía en esta propiedad.
  • POWER_POLICY_GROUP_REQ , el VHAL escribe el ID del grupo de políticas de energía en esta propiedad.

La política de energía actual en el sistema se puede cambiar mediante módulos distintos de VHAL. En ese caso, el demonio de política de energía del automóvil actualiza la propiedad CURRENT_POWER_POLICY para notificar el cambio a VHAL.

Interacción con procesos nativos

Como se mencionó anteriormente, el demonio de la política de energía del automóvil se ejecuta en la capa del sistema y, en términos de administración de la política de energía, proporciona casi la misma funcionalidad que el CPMS que se ejecuta en la capa del marco. Además, supongamos que el demonio de política de energía del automóvil y el CPMS están completamente sincronizados.

El demonio de política de energía del automóvil exporta interfaces AIDL para que las utilicen HAL y otros procesos nativos. Se les puede notificar cuando se cambia una nueva política de energía. En otras palabras, cuando cada uno debe cambiar su estado de poder.

ICarPowerPolicyServer.aidl

package android.frameworks.automotive.powerpolicy;

import android.frameworks.automotive.powerpolicy.CarPowerPolicy;
import android.frameworks.automotive.powerpolicy.CarPowerPolicyFilter;
import android.frameworks.automotive.powerpolicy.ICarPowerPolicyChangeCallback;
import android.frameworks.automotive.powerpolicy.PowerComponent;

/**
 * ICarPowerPolicyServer is an interface implemented by the power policy daemon.
 * VHAL changes the power policy and the power policy daemon notifies the change to registered
 * subscribers. When subscribing to policy changes, a filter can be specified so that the registered
 * callbacks can listen only to a specific power component's change.
 */

@VintfStability
interface ICarPowerPolicyServer {
  /**
   * Gets the current power policy.
   */
  CarPowerPolicy getCurrentPowerPolicy();

  /**
   * Gets whether the power component is turned on or off.
   *
   * @param componentId Power component ID defined in PowerComponent.aidl to check power state.
   * @return True if the component's power state is on.
   */
  boolean getPowerComponentState(in PowerComponent componentId);

  /**
   * Subscribes to power policy change.
   * Notification is sent to the registered callback when the power policy changes and the power
   * state of the components which the callback is interested in changes.
   *
   * @param callback Callback that is invoked when the power policy changes.
   * @param filter The list of components which the callback is interested in.
   */
  void registerPowerPolicyChangeCallback(in ICarPowerPolicyChangeCallback callback,
      in CarPowerPolicyFilter filter);

  /**
   * Unsubscribes from power policy change.
   *
   * @param callback Callback that doesn't want to receive power policy change.
   */
  void unregisterPowerPolicyChangeCallback(in ICarPowerPolicyChangeCallback callback);
}

ICarPowerPolicyChangeCallback.aidl

package android.frameworks.automotive.powerpolicy;

import android.frameworks.automotive.powerpolicy.CarPowerPolicy;

/**
 * ICarPowerPolicyChangeCallback is notified when a power policy changes.
 */

@VintfStability
oneway interface ICarPowerPolicyChangeCallback {
  /**
   * Called when a power policy is fully changed.
   *
   * @param policy The current policy.
   */
  void onPolicyChanged(in CarPowerPolicy policy);
}

Interacción con módulos Java

CarPowerManager proporciona métodos para habilitar la gestión de políticas de energía:

  • Obtenga la política energética actual.
  • Obtener el grupo de políticas de energía actual
  • Aplicar una nueva política energética
  • Establecer un nuevo grupo de políticas de energía

Sólo los módulos con privilegios del sistema pueden utilizar los métodos. Los módulos que quieran recibir información cuando se aplique una política de energía pueden registrar un detector de cambios de política de energía en CarPowerManager .