Power Management Across VMs

Advanced10 min read

Assumes: 6.1 QNX, 6.2 AAOS

AAOS won’t wake up after the car was parked overnight. Is it Android, QNX, or the body controller?

TL;DR

Power management spans the whole vehicle, not just one OS. Vehicle power states (OFF, ACC, RUN, CRANK) come from the body/BCM controller, not from Android. QNX controls power sequencing on the SoC: who boots, who sleeps, who keeps running. AAOS Garage Mode lets the IVI stay partially awake after ignition off for OTA and background tasks. Suspend/resume requires coordination: QNX host must quiesce guests, save state, cut clocks, and restore in the right order. If AAOS “won’t wake up” after sleep, check QNX power manager logs before blaming Android.

Power is the invisible orchestration layer. Users experience it as “screen off when I lock the car” and “why did my OTA finish overnight?” Engineers experience it as a state machine spanning BCM, PMIC, QNX hypervisor, AAOS Car Service, and a dozen peripheral controllers, any of which can refuse to sleep. Your phone has two power states. Your car has about seventeen, most of which involve something being partially awake.

Vehicle Power States

Before OS-level sleep, understand vehicle-level power states, driven by ignition key, start button, or virtual ignition signal:

State	Ignition Position	Typical Vehicle Behavior
OFF	Key out / engine off	Most loads off; some always-on (alarm, telematics wake)
ACC (Accessory)	ACC position	Radio/IVI available; engine not running
RUN	Engine running / ready	All systems nominal
CRANK	Starter engaged	Brief high-current draw; voltage dip; ECUs must tolerate brownout

Power state transitions arrive at the cockpit SoC via CAN/Ethernet signal from the body control module (BCM) or zone controller, not from AAOS user input.

stateDiagram-v2
    [*] --> OFF
    OFF --> ACC: Key to ACC
    ACC --> RUN: Engine start / Ready
    RUN --> CRANK: Starter engaged
    CRANK --> RUN: Engine started
    RUN --> ACC: Engine off
    ACC --> OFF: Key removed / timeout
    RUN --> OFF: Key removed

Think About It

The car enters ACC mode. Android thinks it’s still fully running but can’t access vehicle data. What state is the system in?

Reveal Answer

The vehicle is in ACC (accessory ignition), but QNX has likely put the bus gateway or VHAL server into a reduced-power listen mode — CAN transceivers sleep, some ECUs go offline — while the AAOS guest VM stays running with display and apps alive. Android is fully booted but starved of vehicle signals, not suspended. Check QNX power manager slog2 for gateway/VHAL state first, then adb shell dumpsys car_service to see whether VHAL is disconnected vs returning stale properties.

Mental Model

Vehicle power states are the building’s main breaker panel — controlled by the BCM (building manager). QNX is the floor supervisor who decides which rooms (VMs) get electricity. AAOS is a tenant who can request “keep my lights on for an hour” (Garage Mode) but can’t override the building manager.

OFF → ACC → RUN → CRANK: the car’s power states spell out a daily routine — asleep → alarm → awake → starting the engine.

Who Controls What

Layer	Controller	Decides
Vehicle	BCM / zone controller	OFF, ACC, RUN, CRANK
SoC hardware	PMIC + QNX power manager	Rail voltages, clock gating, wake sources
Hypervisor	QNX	Guest VM suspend/resume, CPU allocation
AAOS	Car Service + Power HAL	Screen off timer, Garage Mode, app wake locks
Apps	WakeLock (partial)	“Keep CPU on” requests, subject to Car Service policy

QNX is authoritative. AAOS requests power states; QNX grants or denies them based on vehicle state, thermal limits, and battery conservation policy.

QNX Controls Power Sequencing

On the SoC, QNX power manager orchestrates:

Boot Sequence

1. PMIC power-on: rails come up in hardware-defined order
2. QNX boot: hypervisor, essential drivers, display (cluster splash)
3. Guest VM launch: AAOS VM starts (may be delayed for fast cluster)
4. Peripheral resume: CAN transceivers, Ethernet PHY, audio codec

Shutdown Sequence

1. Vehicle state → OFF or ACC timeout
2. QNX notifies guests: “prepare for suspend”
3. AAOS quiesce: apps get shutdown window, filesystem sync
4. Guest VM suspend: memory saved, vCPUs halted
5. QNX services wind down: gateway enters low-power listen, cluster may stay on briefly
6. SoC sleep: clock gating, retain RAM, wake IRQ armed

Getting this wrong causes filesystem corruption (AAOS cut mid-write), lost vehicle state (gateway not flushed), or wake failures (guest not restored cleanly).

Common Gotcha

If your bug only happens when starting the car, suspect brownout recovery — not application logic. CRANK is not a normal state — it’s a stress test. During engine start, battery voltage can dip from 12.8V to 9V for 200–500 ms. The SoC must stay alive (or recover cleanly).

AAOS Garage Mode

When the driver walks away, the IVI can’t stay fully awake forever (battery drain). But OEMs want background work: OTA downloads, log uploads, app store updates, remote preconditioning UI prep.

Garage Mode (Android Automotive feature) allows AAOS to remain partially operational after ignition off:

Aspect	Normal Sleep	Garage Mode
Display	Off	Off (usually)
CPU	Suspended or minimal	Active for background tasks
Network	May disconnect	Stays connected (Wi-Fi or LTE)
Duration	N/A	Time-limited (OEM config, e.g., 30 min to 4 hours)
Trigger	Ignition off → sleep	OTA scheduled, OEM policy, cloud command

Garage Mode is a negotiation:

1. AAOS Car Service / OTA manager requests extended wake
2. QNX power manager grants timer-limited wake (considering 12V battery SOC)
3. When timer expires or battery low → QNX forces guest suspend

STR vs Deep Sleep vs Guest-Only Suspend

STR (Suspend-to-RAM): SoC retains DDR contents, most blocks clock-gated, fast resume (~1–3 s).

Deep sleep: lower power, longer wake, may require more re-init.

Guest-only suspend: QNX stays awake (running gateway, cluster), AAOS VM suspended. Common in ACC/OFF when cluster must stay lit but IVI can sleep.

Your platform BSP defines which modes are supported and the state machine transitions between them.

Suspend/Resume Coordination

Multi-VM suspend is a protocol, not a single command:

sequenceDiagram
    participant BCM as BCM / Vehicle
    participant QNX as QNX Power Manager
    participant HYP as Hypervisor
    participant AAOS as AAOS Guest VM
    participant APP as Apps / Car Service

    Note over BCM,APP: Suspend Flow
    BCM->>QNX: Ignition OFF signal
    QNX->>HYP: Prepare guest suspend
    HYP->>AAOS: Virtual power button / notify
    AAOS->>APP: Shutdown broadcast / Garage Mode check
    APP-->>AAOS: Quiesce complete (or timeout)
    AAOS-->>HYP: Guest ready for suspend
    HYP-->>QNX: Guest suspended
    QNX->>QNX: Suspend non-essential services
    QNX->>QNX: Enter SoC sleep state

    Note over BCM,APP: Resume Flow
    BCM->>QNX: Wake event (door unlock, ignition ACC/RUN)
    QNX->>QNX: Restore rails, clocks
    QNX->>HYP: Resume guest VM
    HYP->>AAOS: Restore vCPU, memory
    AAOS->>APP: Boot services / restore state
    QNX->>QNX: Resume gateway, cluster renderer

Common Failure Modes

Symptom	Likely Cause
AAOS won’t suspend	App holding wake lock; Garage Mode stuck; Car Service hang
AAOS won’t resume	Guest state corruption; VirtIO device not restored; QNX timeout
Cluster stays on, IVI dead	Guest-only suspend working as designed, or guest resume failed
Entire SoC dead after sleep	Wake IRQ not armed; PMIC config; QNX power driver bug
Battery drain overnight	Garage Mode too long; wake source stuck; modem (AMSS) not sleeping

Wake Sources

What can pull the SoC out of sleep:

Wake Source	Example
Ignition / ACC	Driver returns, presses start
CAN/Ethernet	Remote unlock, telematics command
GPIO	Door open, trunk latch
RTC alarm	Scheduled Garage Mode / OTA window
Modem (AMSS)	Incoming call, cloud push, SMS wake

Where You'll See This

Power bugs are among the hardest to reproduce. They require specific timing and vehicle state sequences.

Debug workflow:

1. Identify scope: whole SoC dead, or just AAOS guest?
2. Check vehicle state: was it OFF, ACC, or CRANK during repro?
3. QNX logs first: power manager, hypervisor guest lifecycle
4. AAOS second: adb shell dumpsys power, Car Service garage mode state
5. Check wake sources: stuck wake lock, modem keeping system up

Useful commands:

# AAOS power state
adb shell dumpsys power
adb shell dumpsys car_service | grep -i "garage\|power\|sleep"

# Wake locks holding system awake
adb shell dumpsys power | grep -i "wake"

# Simulate garage mode (if supported on your build)
adb shell cmd car_service garage-mode on

Repro tips:

• Ignition cycle scripts: automate OFF → wait → ACC → RUN sequences on bench
• Capture QNX slog2 during entire sleep/wake cycle. The bug is in the transition, not the steady state.
• Monitor 12V rail during CRANK to correlate brownout with guest crash

When filing bugs, always include: vehicle state before/after, time since ignition off, Garage Mode active?, battery SOC if available.

Connect the Dots

Module 6.1 (QNX) owns the power manager and hypervisor guest lifecycle. Module 6.2 (AAOS) owns Garage Mode and Car Service power policy. Module 6.4 (Display & Audio) explains what stays visible/audible during partial wake. Module 7.1 (AMSS) covers modem wake sources that can prevent deep sleep. Module 8 (OTA) depends on Garage Mode for background updates.

• Module 0.4 (Power Architecture): OS-level power states (ACC/RUN/CRANK) map to PMIC rail states. The PMIC’s PON register tells QNX why the system woke up.

Power State vs OS State Quick Reference

Vehicle State	QNX Typical State	AAOS Typical State	Cluster	IVI
RUN	Full operation	Full operation	On	On
ACC	Full operation	Full operation	On	On
OFF (just parked)	Garage Mode window	Garage Mode (if active)	Off or dim	Off
OFF (deep sleep)	STR / minimal	Guest suspended	Off	Off
CRANK	Must survive brownout	May freeze briefly	Must stay functional	May glitch

What matters

1. Vehicle power states (OFF/ACC/RUN/CRANK) come from BCM, not from Android.
2. QNX controls SoC power sequencing: boot order, suspend, wake sources.
3. Garage Mode = negotiated partial wake for OTA/background work after ignition off.
4. Suspend/resume is a multi-VM protocol: guest must quiesce before host sleeps.
5. CRANK brownout causes a class of bugs invisible on bench power supplies.

Check Your Understanding

1. Where do vehicle power states (OFF, ACC, RUN, CRANK) originate on a modern platform?

Recall

A. AMSS modem reports ignition state from the cloud telematics backend serverB. QNX power manager generates states based on battery voltage readings aloneC. AAOS Car Service detects key position directly via a dedicated GPIO pinD. BCM / body controller sends power state over vehicle bus (CAN or Ethernet)

2. What is the primary purpose of AAOS Garage Mode?

Applied

A. Allow background tasks (OTA, uploads) after ignition off within battery budgetB. Enable Android Auto phone projection mode while parked in the garageC. Keep the center stack display on indefinitely after the driver parks the carD. Switch the AAOS VM to QNX for safety reasons during highway driving speed

3. During multi-VM suspend, what must happen before the QNX host enters SoC sleep?

Applied

A. AAOS apps are force-killed immediately without any notification or save windowB. Both VMs suspend simultaneously with no coordination or sequencing protocolC. QNX shuts down first, then AAOS saves its own state completely independentlyD. AAOS guest VM quiesces (apps get shutdown window) and confirms suspend ready

4. AAOS Car Service requests Garage Mode after ignition OFF. Who has final authority to grant or deny extended wake?

Recall

A. AAOS PowerManager — Android owns the SoC power domain as the primary VMB. QNX power manager — vehicle state, battery SOC, thermal limits, OEM policyC. Any AAOS app with a WakeLock can indefinitely prevent the SoC from sleepingD. Google Play Services cloud command sent via FCM push notification channel

5. A bug appears only during engine start: AAOS guest crashes but recovers after CRANK ends. Bench power supply stays at 12.8V stable. Most likely cause?

Applied

A. Android Auto phone projection interference with the IVI power state machineB. CRANK brownout — battery dips to ~9 V for 200–500 ms; bench supplies mask itC. VHAL gRPC timeout during the initial start handshake between QNX and AAOSD. Car Service UX restriction misconfiguration causing a display blank on crank

6. Driver opens door after deep sleep. Cluster must show speed within 500 ms. Which component chain initiates wake?

Synthesis

Connects to: Module 0 — Power Architecture

A. AAOS AlarmManager fires first then notifies QNX power manager to follow suitB. A single CAN bus wake frame reboots the AAOS VM entirely from cold scratchC. PMIC GPIO wake → QNX reads PON reason → cluster resumes → AAOS wakes parallelD. AMSS modem performs a full SoC cold boot sequence through the PMIC watchdog

Further Reading

• Android Power Management — Android kernel and framework power states, wake locks, and suspend/resume behavior in the AAOS guest VM.
• Android Automotive Garage Mode — Official documentation on partial wake after ignition off for OTA, uploads, and background tasks.
• QNX Neutrino Power Management — QNX process and power management concepts for host-side sequencing and guest lifecycle control.
• Android Car Power Policy — How Car Service and Power HAL interact with vehicle ignition states and screen-off timers.
• Qualcomm PMIC and Power Architecture — Context for PMIC rail sequencing and wake sources that QNX power manager orchestrates at the hardware level.
• AUTOSAR Classic — ECU State Manager — How vehicle ECUs model power modes (RUN, POST_RUN, SLEEP) that BCM signals map to at the OS level.
• Linux Kernel Suspend and Resume — Guest Linux kernel STR/deep-sleep mechanics relevant when AAOS VM suspends under QNX hypervisor control.