Power Management Across VMs

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.

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

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.

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

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). If your bug is “only happens when starting the car,” suspect brownout recovery, not application logic.

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.

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?

A. AAOS Car Service detects key position via GPIO directlyB. BCM / body controller sends power state over vehicle bus (CAN/Ethernet)C. QNX generates them based on battery voltage aloneD. AMSS modem reports ignition state from cloud telematics

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

A. Keep the center stack display on indefinitely after parkingB. Allow background tasks (OTA, uploads) to continue after ignition off within a time/battery budgetC. Switch AAOS to QNX for safety during highway drivingD. Enable Android Auto phone projection in the garage

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

A. AAOS apps are force-killed immediately without notificationB. AAOS guest VM quiesces (apps get shutdown window) and confirms ready for suspendC. QNX shuts down first, then AAOS saves its own state independentlyD. Both VMs suspend simultaneously with no coordination