Política de energía

Para garantizar que los componentes de hardware y software (como la pantalla, el audio y la interacción por voz) se activen y desactiven de forma selectiva 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. La VHAL o los servicios de proveedores con privilegios del sistema pueden aplicar una nueva política de energía cuando cambia el estado de energía de Android o cuando se cumplen las condiciones que esperan.

Se permite aplicar una política de energía en los estados de Esperar a la VHAL, Encendido y Preparación previa al apagado (a veces con algunas restricciones). A diferencia de Esperar a VHAL y Encendido, no se puede configurar una política de energía predeterminada para Preparar el apagado previo en un grupo de políticas de energía. En la fase principal de preparación para el apagado, el modo de estacionamiento se está ejecutando y no debería verse afectado por un cambio de estado de energía. Aunque no se puede aplicar una política de energía normal, se aplica una política de energía especial, que es la política de energía del sistema llamada sin interacción del usuario, en la fase principal de preparación para el apagado.

Estado de energía del AAOS

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

Diagrama de estado de energía de AAOS

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

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

Valor Descripción
Desactivado
  • No se proporciona energía físicamente al procesador de aplicaciones (AP), la memoria ni los periféricos.
Espera a la 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 los periféricos.
  • AAOS pasa de uno de tres estados (Off, Suspend-to-RAM [STR, Wait for VHAL to finish]) y, luego, ingresa a Wait for VHAL, donde espera la coordinación con la VHAL.
Activado
  • La VHAL le indica al AAOS que ingrese al estado On. En este estado, AAOS se ejecuta por completo y, además, interactúa con el conductor.
  • La pantalla se controla con la política de energía y no con las llamadas de encendido y apagado de la pantalla de Android para otros factores de forma.
Preparación para el cierre
  • Cuando el conductor deja de conducir, la VHAL le indica al AAOS que ingrese a la preparación para el apagado, que comienza con la fase de preparación previa al apagado, seguida de la fase principal de preparación para el apagado. En la fase principal, la pantalla y el audio están desactivados, y el AAOS no interactúa con el conductor. El sistema Android sigue en ejecución y puede actualizar las apps y el sistema Android. Cuando se completan las actualizaciones, el sistema Android ingresa al estado Wait for VHAL Finish.
Espera a que finalice la VHAL
  • AAOS informa a la VHAL que se puede apagar. Se espera que la unidad de microcontrolador del vehículo (VMCU) coloque el sistema en chip (SoC) en suspensión profunda y quite la energía del AP. Luego, AAOS se encuentra en el estado STR, aunque no se ejecuta ningún código.
  • Si la VHAL no finaliza y el conductor regresa, la consola central (HU) debe pasar directamente a Esperar a la VHAL.
Suspensión en RAM (STR)
  • El vehículo y el AP están apagados, no se ejecuta ningún código y se mantiene la alimentación de la RAM del AP.
Suspensión en disco (STD)
  • El vehículo y el AP están apagados, no se ejecuta ningún código y no se mantiene la energía en la unidad de procesamiento ni en la RAM del AP.

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

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

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

Política de energía

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

AUDIO
MEDIA
DISPLAY
BLUETOOTH
WIFI
CELLULAR
ETHERNET
PROJECTION
NFC
INPUT
VOICE_INTERACTION
VISUAL_INTERACTION
TRUSTED_DEVICE_DETECTION
LOCATION
MICROPHONE
CPU

Los proveedores también pueden definir sus propios componentes de energía personalizados para usarlos con las políticas de energía. Define componentes de energía personalizados en el mismo archivo XML que las políticas de energía, como en este ejemplo:

<customComponents>
  CUSTOM_COMPONENT_1000
  CUSTOM_COMPONENT_SPECIAL_SENSOR
  CUSTOM_COMPONENT_AUX_INPUT
</customComponents>

Grupo de políticas de energía

El grupo de políticas de energía especifica la política de energía predeterminada que se aplicará automáticamente en las transiciones de estado de energía. Los proveedores pueden definir la política de energía predeterminada para Esperar a la VHAL y Encendido.

La política de energía predeterminada para Esperar a la VHAL o Encendido se aplica en cada transición a ese estado, incluso cuando se cancela un apagado y Android vuelve a Esperar a la VHAL. Si no se define una política de energía predeterminada para un estado determinado en el grupo de políticas de energía actual, el daemon de la política de energía del vehículo aplica una política de energía integrada. Una excepción es cuando el sistema está en modo silencioso: el daemon de la política de energía del vehículo guarda la política de energía normal actual o solicitada como pendiente, bloquea los cambios en la política de energía normal y aplica la política de energía del sistema sin interacción del usuario. Cuando se aplica una política de energía, solo se cambian los componentes que abarca la política, y los componentes que no se modifican quedan en su estado actual.

Políticas de energía del sistema

AAOS admite dos políticas de energía del sistema, que son sin interacción del usuario y preparación para la suspensión. La política de energía del sistema se aplica cuando el dispositivo entra en el modo silencioso, el modo garaje, la suspensión en la RAM o la suspensión en el disco.

En las siguientes tablas, se indica el comportamiento de cada componente en la política de energía del sistema. Los implementadores pueden anular la detección de Bluetooth, NFC y dispositivos de confianza en la política de energía del sistema de sin interacción del usuario. Las anulaciones se aplican en /vendor/etc/automotive/power_policy.xml.

sin interacción del usuario

El comportamiento de la política de energía del sistema sin interacción del usuario se define en esta tabla:

Componentes Estado de energía Configurable
Audio Desactivado No
Medios Desactivado No
Pantalla Desactivado No
Bluetooth Desactivado Sí
Wi-Fi Activado No
Móvil Activado No
Ethernet Activado No
Proyección Desactivado No
NFC Desactivado Sí
Entrada Desactivado No
Asistente Desactivado No
Interacción del usuario Desactivado No
Detección de dispositivos de confianza para el acceso de los usuarios Activado Sí
Ubicación Desactivado No
Micrófono Desactivado No
CPU Activado No

suspender la preparación

El comportamiento de la política de energía del sistema suspend prep se define en esta tabla:

Componentes Estado de alimentación Configurable por el OEM
Audio Desactivado No
Medios N/A No
Pantalla N/A No
Bluetooth Desactivado No
Wi-Fi Desactivado No
Móvil N/A No
Ethernet N/A No
Proyección N/A No
NFC N/A No
Entrada N/A No
Asistente N/A No
Interacción del usuario N/A No
Detección de dispositivos de confianza para el acceso de los usuarios N/A No
Ubicación Desactivado No
Micrófono Desactivado No
CPU Desactivado No

Interacción con la VHAL

El daemon de la política de energía del vehículo que se ejecuta en la capa del sistema suscribe dos propiedades para escuchar las solicitudes de la VHAL:

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

Los módulos que no sean la VHAL pueden cambiar la política de energía actual del sistema. En ese caso, el daemon de la política de energía del vehículo actualiza la propiedad CURRENT_POWER_POLICY para notificar el cambio a la VHAL.

Interacción con procesos nativos

CarPowerManagementService (CPMS) delega la administración de la política de energía al daemon de la política de energía del vehículo. El daemon es la única fuente de información para las políticas de energía en el sistema. El daemon de la política de energía del vehículo administra el estado de la política de energía y notifica los cambios al CPMS, la VHAL y otros clientes nativos.

El daemon de la política de energía del vehículo exporta interfaces AIDL para que las usen las HAL y otros procesos nativos. Pueden recibir notificaciones cuando se cambia una nueva política de energía. En otras palabras, cuándo debe cambiar cada uno su estado de energía.

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.
     * @throws IllegalStateException if the current policy is not set.
     */
    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.
     * @throws IllegalArgumentException if the componentId is invalid.
     */
    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.
     * @throws IllegalArgumentException if the callback is already registered.
     * @throws IllegalStateException if the callback is dead.
     */
    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.
     * @throws IllegalArgumentException if the callback is not registered.
     */
    void unregisterPowerPolicyChangeCallback(in ICarPowerPolicyChangeCallback callback);

    /**
     * Applies the power policy.
     *
     * 

{@code policyId} should be one of power policy IDs defined in * {@code /vendor/etc/automotive/power_policy.xml} or predefined system power policies. * * @param policyId ID of power policy. * @throws IllegalArgumentException if {@code policyId} is invalid. */ void applyPowerPolicy(in @utf8InCpp String policyId); /** * Sets the current power policy group. * *

{@code policyGroupId} should be one of power policy group IDs defined in * {@code /vendor/etc/automotive/power_policy.xml}. * * @param policyGroupId ID of power policy group. * @throws IllegalArgumentException if {@code policyGroupId} is invalid. */ void setPowerPolicyGroup(in @utf8InCpp String policyGroupId); }

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 de Java

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

  • Obtén la política de energía actual
  • Aplica una nueva política de energía
  • Establece un nuevo grupo de políticas de energía

Solo los módulos con privilegios del sistema pueden usar los métodos. Los módulos que quieran recibir información cuando se aplique una política de energía pueden registrar un objeto de escucha de cambio de política de energía en CarPowerManager.