Aby zapewnić, że komponenty sprzętowe i oprogramowania (takie jak wyświetlacz, dźwięk i interakcje głosowe) są włączane i wyłączane selektywnie w miarę potrzeby, AAOS udostępnia zasady zasilania, które zawierają zestaw oczekiwanych stanów włączania i wyłączania komponentów sprzętowych i oprogramowania. VHAL, czyli usługi dostawcy z uprawnieniami systemowymi, mogą stosować nową politykę zasilania, gdy stan zasilania Androida przechodzi w inny stan lub gdy są spełnione warunki, na które czekają.
Zastosowanie zasad dotyczących zasilania jest dozwolone w stanach „Czekaj na VHAL” i „Włączone” (czasami z pewnymi ograniczeniami). W trybie przygotowania do wyłączenia tryb garażu jest uruchomiony i nie powinien być zakłócany przez zmianę stanu zasilania. Chociaż nie można zastosować zwykłej zasady dotyczącej zasilania, w przygotowaniu do wyłączenia jest stosowana specjalna zasada dotycząca zasilania, która jest zasadą dotyczącą zasilania systemu o nazwie „Brak interakcji z użytkownikiem”.
Stan zasilania AAOS
Urządzenia AAOS działają zgodnie z tym diagramem stanu zasilania:

Rysunek 1. Schemat stanu zasilania w AAOS
Poniżej opisujemy poszczególne stany zasilania:
| Wartość | Opis |
|---|---|
| Wył. |
|
| Czekaj na VHAL |
|
| Wł. |
|
| Przygotowanie do wyłączenia |
|
| Zaczekaj na zakończenie procesu VHAL. |
|
| Zawieszanie do pamięci RAM (STR) |
|
| Zawieszanie na dysku (STD) |
|
Jak definiuje się zasady dotyczące zasilania?
Implementatorzy definiują zasady zarządzania energią w /vendor/etc/automotive/power_policy.xml, które:
- Definiuje zasady zasilania.
- Definiuje grupy zasad dotyczących zasilania, które obejmują domyślne zasady dotyczące zasilania i są automatycznie stosowane podczas przechodzenia między stanami zasilania.
- Zastępuje zasadę zasilania systemu.
Zasady dotyczące mocy
Zasady dotyczące zasilania obejmują zestaw oczekiwanych stanów zasilania komponentów sprzętowych i programowych. AAOS obsługuje te komponenty w ramach zasad dotyczących zasilania:
|
DŹWIĘK MEDIA WYŚWIETLACZ BLUETOOTH |
WIFI Sieć komórkowa Ethernet PROJEKCJA |
NFC INPUT VOICE_INTERACTION VISUAL_INTERACTION |
TRUSTED_DEVICE_DETECTION LOCATION MICROPHONE CPU |
Dostawcy mogą też definiować własne komponenty zasilania na potrzeby zasad dotyczących zasilania. Zdefiniuj niestandardowe komponenty zasilania w tym samym pliku XML co zasady zasilania, jak w tym przykładzie:
<customComponents>CUSTOM_COMPONENT_1000 CUSTOM_COMPONENT_SPECIAL_SENSOR CUSTOM_COMPONENT_AUX_INPUT </customComponents>
Grupa zasad dotyczących mocy
Domyślna zasada zasilania jest automatycznie stosowana podczas przejścia do stanu zasilania określonego w grupie zasad zasilania. Dostawcy mogą zdefiniować domyślną politykę zasilania dla: Wait For VHAL (Oczekiwanie na VHAL), On (Wł.) i Wait for VHAL Finish (Oczekiwanie na zakończenie VHAL (uśpienie głębokie lub rozpoczęcie zamykania)).
Zasady dotyczące zasilania systemu
AAOS obsługuje 2 zasady dotyczące zasilania systemu: bez interakcji z użytkownikiem i przygotowanie do zawieszenia. Zasady zarządzania energią systemu są stosowane, gdy urządzenie przechodzi w tryb cichego działania, tryb garażu, uśpienie do pamięci RAM lub uśpienie do dysku.
W tabelach poniżej podano działanie poszczególnych komponentów w ramach zasad zasilania systemu.
Implementatorzy mogą zastąpić wykrywanie Bluetooth, NFC i zaufanych urządzeń w ramach zasad zarządzania energią systemu bez interakcji z użytkownikiem. Zastąpienia są stosowane w /vendor/etc/power_policy.xml.
bez interakcji użytkownika
Sposób działania zasady dotyczącej mocy systemu w przypadku brak interakcji użytkownika jest określony w tej tabeli:
| Komponenty | Stan zasilania | Konfigurowalne |
|---|---|---|
| Audio | Wył. | Nie |
| Multimedia | Wył. | Nie |
| Wyświetlacz | Wył. | Nie |
| Bluetooth | Wył. | Tak |
| Wi-Fi | Wł. | Nie |
| Sieć komórkowa | Wł. | Nie |
| Ethernet | Wł. | Nie |
| Prognoza | Wył. | Nie |
| NFC | Wył. | Tak |
| Urządzenie wejściowe | Wył. | Nie |
| Asystent | Wył. | Nie |
| Interakcje użytkownika | Wył. | Nie |
| Wykrywanie zaufanych urządzeń podczas logowania użytkownika | Wł. | Tak |
| Lokalizacja | Wył. | Nie |
| mikrofon | Wył. | Nie |
| Procesor | Wł. | Nie |
zawieszenie przygotowań
Zachowanie zasady dotyczącej zasilania systemu przygotowania do zawieszenia jest określone w tej tabeli:
| Komponenty | Stan zasilania | Konfiguracja OEM |
|---|---|---|
| Audio | Wył. | Nie |
| Multimedia | Nie dotyczy | Nie |
| Wyświetlacz | Nie dotyczy | Nie |
| Bluetooth | Wył. | Nie |
| Wi-Fi | Wył. | Nie |
| Sieć komórkowa | Nie dotyczy | Nie |
| Ethernet | Nie dotyczy | Nie |
| Prognoza | Nie dotyczy | Nie |
| NFC | Nie dotyczy | Nie |
| Urządzenie wejściowe | Nie dotyczy | Nie |
| Asystent | Nie dotyczy | Nie |
| Interakcje użytkownika | Nie dotyczy | Nie |
| Wykrywanie zaufanych urządzeń podczas logowania użytkownika | Nie dotyczy | Nie |
| Lokalizacja | Wył. | Nie |
| mikrofon | Wył. | Nie |
| Procesor | Wył. | Nie |
Interakcja z VHAL
Demon zasad zasilania samochodu działający na poziomie systemu subskrybuje 2 właściwości, aby odbierać żądania z VHAL:
POWER_POLICY_REQVHAL zapisuje identyfikator polityki zasilania w tej usłudze.POWER_POLICY_GROUP_REQVHAL zapisuje identyfikator grupy zasad zasilania do tej właściwości.
Bieżące zasady zasilania w systemie mogą być zmieniane przez moduły inne niż VHAL. W takim przypadku demon zasad zasilania samochodu aktualizuje usługę CURRENT_POWER_POLICY, aby powiadomić VHAL o zmianie.
Interakcja z rodzimi procesami
Jak wspomniano powyżej, demon zasad zasilania samochodu działa na poziomie systemu i pod względem zarządzania zasadami zasilania zapewnia niemal te same funkcje co CPMS działający na poziomie frameworku. Załóżmy też, że demon zasad zasilania samochodu i CPMS są w pełni zsynchronizowane.
Demon polityki zasilania samochodu eksportuje interfejsy AIDL do użycia przez interfejsy HAL i inne natywne procesy. Mogą otrzymywać powiadomienia o zmianach w nowej polityce dotyczącej zasilania. Inaczej mówiąc, gdy każdy z nich musi zmienić stan zasilania.
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);
}
Interakcje z modułami Javy
CarPowerManager zawiera metody umożliwiające zarządzanie zasadami dotyczącymi zasilania:
- Pobieranie bieżących zasad zasilania
- Stosowanie nowych zasad dotyczących zasilania
- Konfigurowanie nowej grupy zasad dotyczących zasilania
Z tych metod mogą korzystać tylko moduły z uprawnieniami systemowymi. Moduli, które mają być informowane o zastosowaniu zasady dotyczącej zasilania, mogą zarejestrować odbiornika zmian zasad dotyczących zasilania.CarPowerManager