Para garantizar que los componentes de hardware y software (como pantalla, interacción de voz y audio) se activan y desactivan de forma selectiva según sea necesario, el AAOS proporciona una política de energía, que consiste en un 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 transiciones o cuando se cumplen las condiciones que están esperando.
Se permite aplicar una política de energía en los estados de Esperar por VHAL y Activada (a veces con algunas restricciones) En la preparación para el apagado, el modo garaje se está ejecutando y debería que no te interrumpa un cambio de estado de energía. Si bien no se puede aplicar una política de energía común, una se aplica la política de energía especial, que es la política de energía del sistema denominada sin interacción del usuario, Preparación para el cierre.
Estado de alimentación de AAOS
Los dispositivos AAOS siguen este diagrama de estado de energía:
Figura 1: Diagrama de estado de energía de AAOS.
A continuación, se describe cada estado de alimentación:
Valor | Descripción |
---|---|
Desactivado |
|
Esperar a VHAL |
|
Activado |
|
Preparación de apagado |
|
Espera a que finalice la VHAL |
|
Suspensión en RAM (STR) |
|
Suspensión en disco (STD) |
|
¿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:
- 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 habilitan automáticamente se aplican cuando se producen transiciones del 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. El AAOS admite estos componentes en la política de energía:
AUDIO CONTENIDO MULTIMEDIA PANTALLA BLUETOOTH |
WI-FI MÓVIL ETHERNET PROYECCIÓN |
NFC ENTRADA VOICE_INTERACTION INTERACCIÓN_VISUAL |
DETECCIÓN DE DISPOSITIVO_DE_CONFIDENCIAL UBICACIÓN MICRÓFONO CPU |
Los proveedores también pueden definir sus propios componentes de energía personalizados para usarlos con las políticas de energía. Definir 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
La política de energía predeterminada que se aplica automáticamente durante la transición del estado de energía es especificadas en el grupo de políticas de energía. Los proveedores pueden definir la política de energía predeterminada para Espera a que se active el VHAL, y espera a que finalice (entrada de sueño profundo o inicio de apagado).
Políticas de energía del sistema
El AAOS admite dos políticas de energía del sistema, que son sin interacción del usuario y suspender la preparación. La política de energía del sistema se aplica cuando el dispositivo entra en Modo silencioso, Modo garaje, Suspensión en la RAM o Suspensión en el disco.
En las siguientes tablas, se muestra el comportamiento de cada componente de la política de alimentación del sistema.
Los implementadores pueden anular la detección de Bluetooth, NFC y dispositivo de confianza en el
la política de energía del sistema sin interacción del usuario. Las anulaciones se aplican en
/vendor/etc/power_policy.xml
sin interacción del usuario
En este artículo, se define el comportamiento de la política de energía del sistema que no permite la interacción del usuario. tabla:
Componentes | Estado de alimentación | Configurable |
---|---|---|
Audio | Desactivado | No |
Contenido multimedia | Desactivado | No |
Pantalla | Desactivado | No |
Bluetooth | Desactivado | Sí |
Wifi | Activado | No |
Red 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 usuarios | Activado | Sí |
Ubicación | Desactivado | No |
Micrófono | Desactivado | No |
CPU | Activado | No |
preparación de suspensión
En esta tabla, se define el comportamiento de la política de energía del sistema para suspender la preparación:
Componentes | Estado de energía | Configurable por OEM |
---|---|---|
Audio | Desactivado | No |
Contenido multimedia | N/A | No |
Pantalla | N/A | No |
Bluetooth | Desactivado | No |
Wifi | Desactivado | No |
Red 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 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 automóvil que se ejecuta en la capa del sistema suscribe dos propiedades para escuchar 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. a esta propiedad.
La política de energía actual en el sistema puede cambiarse con otros módulos que no sean VHAL. En ese caso,
el daemon de la política de energía del automóvil actualiza la propiedad CURRENT_POWER_POLICY
para notificar al
a la VHAL.
Interacción con procesos nativos
Como se mencionó antes, el daemon de la política de energía del automóvil se ejecuta en la capa del sistema y, en términos de de políticas, brinda casi la misma funcionalidad que los CPM que se ejecutan en la capa del marco de trabajo. Además, supongamos que el daemon de la política de energía del automóvil y los CPMS están completamente sincronizados.
El daemon de la política de energía del automóvil exporta interfaces de AIDL para que las usen las HAL y otros procesos nativos. Pueden recibir notificaciones cuando se cambie una nueva política de energía. En otras palabras, cuando cada uno debe cambiar 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:
- Obtener la política de energía actual
- Aplicar una nueva política de energía
- Establecer un nuevo grupo de políticas de energía
Solo los módulos con privilegios del sistema pueden usar estos métodos. Los módulos que se quieren
informada cuando se aplica una política de energía puede registrar un objeto de escucha de cambio de política de energía a
CarPowerManager