Zasady dotyczące mocy

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:

Schemat stanu zasilania w AAOS

Rysunek 1. Schemat stanu zasilania w AAOS

Poniżej opisujemy poszczególne stany zasilania:

Wartość Opis
Wył.
  • Procesor aplikacji (AP), pamięć i urządzenia peryferyjne nie są zasilane.
Czekaj na VHAL
  • Gdy kierowca wchodzi w interakcję z pojazdem (np. otwiera drzwi), VMCU dostarcza zasilanie do AP, pamięci i urządzeń peryferyjnych.
  • AAOS przechodzi z jednego z 3 stanów (wyłączony, zawieszenie w pamięci RAM, oczekiwanie na zakończenie VHAL) do stanu oczekiwania na VHAL, w którym oczekuje na koordynację z VHAL.
Wł.
  • VHAL instruuje AAOS, aby przejść w stan włączenia. W tym stanie AAOS działa w pełni i wchodzi w interakcję z kierowcą.
  • Wyświetlacz jest kontrolowany przez zasady dotyczące zasilania, a nie przez wywołania włączania/wyłączania wyświetlacza w Androidzie w przypadku innych formatów.
Przygotowanie do wyłączenia
  • Gdy kierowca przestanie prowadzić, VHAL zleci AAOS przejście w tryb przygotowania do wyłączenia. W tym stanie wyświetlacz i dźwięk są wyłączone, a system AAOS nie wchodzi w interakcję z kierowcą. System Android nadal działa i może aktualizować aplikacje oraz system Android. Po zakończeniu aktualizacji (jeśli były dostępne) system Android przechodzi w stan „Czekanie na zakończenie VHAL”.
Zaczekaj na zakończenie procesu VHAL.
  • AAOS informuje VHAL, że może zostać wyłączony. Mikrokontroler pojazdu (VMCU) powinien umieścić system na chipie (SoC) w stanie głębokiego uśpienia i odłączyć zasilanie od AP. AAOS jest wtedy w stanie STR, ale nie jest wykonywany żaden kod.
  • Jeśli VHAL nie zakończy się, a kierowca wróci, jednostka główna (HU) powinna przejść bezpośrednio do Wait for VHAL.
Zawieszanie do pamięci RAM (STR)
  • Pojazd i AP są wyłączone, nie jest wykonywany żaden kod, a zasilanie jest utrzymywane dla pamięci RAM AP.
Zawieszanie na dysku (STD)
  • Samochód i AP są wyłączone, nie jest wykonywany żaden kod, a jednostka przetwarzania i pamięć AP RAM nie są zasilane.

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żytkownikiemprzygotowanie 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_REQ VHAL zapisuje identyfikator polityki zasilania w tej usłudze.
  • POWER_POLICY_GROUP_REQ VHAL 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