Zasady dotyczące mocy

Aby zapewnić selektywne włączanie i wyłączanie komponentów sprzętowych i programowych (takich jak wyświetlacz, dźwięk i interakcja głosowa) w zależności od potrzeb, AAOS udostępnia zasady zasilania, które obejmują zestaw oczekiwanych stanów włączenia i wyłączenia komponentów sprzętowych i programowych. VHAL lub usługi dostawcy z uprawnieniami systemowymi mogą zastosować nowe zasady zasilania, gdy zmieni się stan zasilania Androida lub gdy zostaną spełnione warunki, na które czekają.

Stosowanie zasad zasilania jest dozwolone w stanach Wait for VHAL, On i Pre Shutdown Prepare (czasami z pewnymi ograniczeniami). W przeciwieństwie do opcji Wait for VHAL i On, domyślnej zasady zasilania nie można skonfigurować dla opcji Pre Shutdown Prepare w grupie zasad zasilania. W podstawowej fazie przygotowania do wyłączenia działa tryb garażowy, którego nie powinna zakłócać zmiana stanu zasilania. Nie można zastosować zwykłej zasady dotyczącej zasilania, ale w fazie przygotowania do wyłączenia systemu stosowana jest specjalna zasada dotycząca zasilania, czyli zasada systemowa o nazwie no user interaction (brak interakcji z użytkownikiem).

Stan zasilania AAOS

Urządzenia z AAOS działają zgodnie z tym schematem stanów zasilania:

Diagram stanów zasilania AAOS

Rysunek 1. Diagram stanu zasilania AAOS.

Każdy stan zasilania został opisany poniżej:

Wartość Opis
Wyłączono
  • Procesor aplikacji, pamięć i urządzenia peryferyjne nie są zasilane.
Oczekiwanie na VHAL
  • Gdy kierowca wejdzie w interakcję z pojazdem (np. otworzy drzwi), VMCU włączy zasilanie AP, pamięci i urządzeń peryferyjnych.
  • AAOS przechodzi z jednego z 3 stanów (wyłączony, zawieszony do pamięci RAM (STR, oczekiwanie na zakończenie VHAL)) i wchodzi w stan oczekiwania na VHAL, w którym czeka na koordynację z VHAL.
Włączono
  • VHAL instruuje AAOS, aby przejść w stan włączony. W tym stanie AAOS jest w pełni uruchomiony i wchodzi w interakcje z kierowcą.
  • Wyświetlacz jest kontrolowany przez zasady zasilania, a nie przez wywołania włączania i wyłączania wyświetlacza Androida w przypadku innych formatów.
Przygotowanie do wyłączenia
  • Gdy kierowca przestanie prowadzić, VHAL poleci AAOS przejście w stan Shutdown Prepare (Przygotowanie do wyłączenia), który rozpoczyna się od fazy Pre Shutdown Prepare (Przygotowanie do wyłączenia), a następnie przechodzi w fazę core Shutdown Prepare (Przygotowanie do wyłączenia). W fazie podstawowej wyświetlacz i dźwięk są wyłączone, a AAOS nie wchodzi w interakcję z kierowcą. System Android nadal działa i może aktualizować aplikacje oraz system Android. Po zakończeniu aktualizacji system Android przechodzi w stan oczekiwania na zakończenie VHAL.
Poczekaj na zakończenie działania VHAL
  • AAOS informuje VHAL, że można go wyłączyć. Jednostka mikrokontrolera pojazdu (VMCU) powinna wprowadzić układ SoC w stan głębokiego uśpienia i odłączyć zasilanie od procesora aplikacji. AAOS jest wtedy w stanie STR, mimo że nie jest wykonywany żaden kod.
  • Jeśli VHAL nie zakończy się, a kierowca wróci, jednostka główna powinna przejść bezpośrednio do stanu oczekiwania na VHAL.
Wstrzymanie do pamięci RAM (STR)
  • Pojazd i procesor aplikacji są wyłączone, nie jest wykonywany żaden kod, a zasilanie jest utrzymywane w pamięci RAM procesora aplikacji.
Wstrzymanie na dysku (STD)
  • Pojazd i AP są wyłączone, nie jest wykonywany żaden kod, a jednostka przetwarzająca i pamięć RAM AP nie są zasilane.

Jak definiuje się zasady zasilania?

Osoby wdrażające definiują zasady zasilania w /vendor/etc/automotive/power_policy.xml, które:

  • Określa zasady zasilania.
  • Definiuje grupy zasad zasilania, które obejmują domyślne zasady zasilania i są automatycznie stosowane w przypadku zmiany stanu zasilania.
  • Zastępuje zasady zasilania systemu.

Zasady dotyczące zasilania

Zasady zasilania obejmują zestaw oczekiwanych stanów zasilania komponentów sprzętowych i programowych. AAOS obsługuje te komponenty w polityce zasilania:

AUDIO
MEDIA
WYŚWIETLACZ
BLUETOOTH
WI-FI
KOMÓRKOWE
ETHERNET
PROJEKCJA
NFC
INPUT
VOICE_INTERACTION
VISUAL_INTERACTION
TRUSTED_DEVICE_DETECTION
LOCATION
MICROPHONE
CPU

Dostawcy mogą też definiować własne niestandardowe komponenty zasilania do użycia w zasadach 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 zasilania

Grupa zasad zasilania określa domyślne zasady zasilania, które mają być automatycznie stosowane podczas przejść między stanami zasilania. Dostawcy mogą zdefiniować domyślne zasady zasilania dla stanów Wait for VHAL i On.

Domyślne zasady zasilania dla stanu Wait for VHAL lub On są stosowane przy każdym przejściu do tego stanu, w tym gdy wyłączenie zostanie anulowane, a Android wróci do stanu Wait for VHAL. Jeśli w bieżącej grupie zasad zasilania dla danego stanu nie zdefiniowano domyślnej zasady zasilania, demon zasad zasilania samochodu stosuje wbudowaną zasadę zasilania. Wyjątkiem jest sytuacja, gdy system jest w trybie cichym: demon zasad zasilania samochodu zapisuje bieżącą lub żądaną zwykłą zasadę zasilania jako oczekującą, blokuje zmiany zwykłej zasady zasilania i stosuje zasadę zasilania systemu bez interakcji użytkownika. Zastosowanie zasady zasilania zmienia tylko te komponenty, których dotyczy zasada, a pozostałe komponenty pozostają w obecnym stanie.

Zasady zasilania systemu

AAOS obsługuje 2 zasady zasilania systemu: brak interakcji z użytkownikiem i przygotowanie do zawieszenia. Zasady zasilania systemu są stosowane, gdy urządzenie przechodzi w tryb cichy, tryb garażowy, uśpienie do pamięci RAM lub uśpienie na dysk.

W tabelach poniżej znajdziesz informacje o działaniu poszczególnych komponentów w ramach zasad zasilania systemu. W zasadach zasilania systemu bez interakcji użytkownika można zastąpić wykrywanie Bluetootha, NFC i zaufanych urządzeń. Zastąpienia są stosowane w /vendor/etc/automotive/power_policy.xml.

brak interakcji użytkownika,

Działanie zasady zasilania systemu brak interakcji użytkownika jest zdefiniowane w tej tabeli:

Komponenty Stan zasilania Można konfigurować
Dźwięk Wyłączono Nie
Multimedia Wyłączono Nie
Wyświetlacz Wyłączono Nie
Bluetooth Wyłączono Tak
Wi-Fi Włączono Nie
Sieć komórkowa Włączono Nie
Ethernet Włączono Nie
Odwzorowanie Wyłączono Nie
NFC Wyłączono Tak
Dane wejściowe Wyłączono Nie
Asystent Wyłączono Nie
Interakcja użytkownika Wyłączono Nie
Wykrywanie zaufanych urządzeń podczas logowania użytkownika Włączono Tak
Lokalizacja Wyłączono Nie
Mikrofon Wyłączono Nie
CPU Włączono Nie

zawieszenie przygotowań,

Zachowanie zasady zasilania systemu suspend prep jest zdefiniowane w tej tabeli:

Komponenty Stan zasilania Możliwość konfiguracji przez producenta OEM
Dźwięk Wyłączono Nie
Multimedia Nie dotyczy Nie
Wyświetlacz Nie dotyczy Nie
Bluetooth Wyłączono Nie
Wi-Fi Wyłączono Nie
Sieć komórkowa Nie dotyczy Nie
Ethernet Nie dotyczy Nie
Odwzorowanie Nie dotyczy Nie
NFC Nie dotyczy Nie
Dane wejściowe Nie dotyczy Nie
Asystent Nie dotyczy Nie
Interakcja użytkownika Nie dotyczy Nie
Wykrywanie zaufanych urządzeń podczas logowania użytkownika Nie dotyczy Nie
Lokalizacja Wyłączono Nie
Mikrofon Wyłączono Nie
CPU Wyłączono Nie

Interakcja z VHAL

Demon zasad zasilania samochodu działający w warstwie systemowej subskrybuje 2 właściwości, aby nasłuchiwać żądań z VHAL:

  • POWER_POLICY_REQ VHAL zapisuje w tej właściwości identyfikator zasady zasilania.
  • POWER_POLICY_GROUP_REQ VHAL zapisuje w tej właściwości identyfikator grupy zasad zasilania.

Bieżące zasady zasilania w systemie mogą być zmieniane przez moduły inne niż VHAL. W takim przypadku demon zasad zasilania samochodu aktualizuje właściwość CURRENT_POWER_POLICY, aby powiadomić VHAL o zmianie.

Interakcja z procesami natywnymi

Usługa CarPowerManagementService (CPMS) przekazuje zarządzanie zasadami zasilania do demona zasad zasilania samochodu. Demon jest jedynym źródłem wiarygodnych danych dotyczących zasad zasilania w systemie. Demon zasad zasilania samochodu zarządza stanem zasad zasilania i powiadamia CPMS, VHAL i innych klientów natywnych o zmianach.

Demon zasad zasilania samochodu eksportuje interfejsy AIDL do użytku przez HAL i inne procesy natywne. Mogą otrzymywać powiadomienia o zmianach w nowych zasadach zasilania. Inaczej mówiąc, kiedy każde urządzenie 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);
  }

Interakcja z modułami Java

CarPowerManager udostępnia metody włączania zarządzania zasadami zasilania:

  • Pobieranie bieżącej zasady zasilania
  • Stosowanie nowych zasad zasilania
  • Ustawianie nowej grupy zasad zasilania

Z tych metod mogą korzystać tylko moduły z uprawnieniami systemowymi. Moduły, które chcą otrzymywać informacje o zastosowaniu zasad zasilania, mogą zarejestrować odbiornik zmian zasad zasilania, aby CarPowerManager