What happens when you turn the car on

You turn the key. Fifteen seconds later there is a home screen. A great deal happens in between, and knowing the order pays off constantly — because when something does not come up, the question is always "what was it waiting for?"

Why this is worth learning properly#

Stage 1 — Power, and a signal that is not software#

Before anything digital happens, the vehicle decides to wake up. That decision is electrical: the ignition, a door handle, a remote unlock.

Stage 2 — Boot ROM and bootloader#

The chip runs a tiny program burned into it at manufacture. That program loads the bootloader, and — critically — checks it has not been tampered with before running it.

The bootloader does the same for the next stage. This is verified boot: a chain where each link verifies the next.

adb shell getprop ro.boot.verifiedbootstate   # green on a production vehicle
adb shell getprop ro.boot.flash.locked        # 1

Stage 3 — The kernel#

Linux starts. It probes hardware, loads drivers, and mounts the storage partitions — checking them against dm-verity hashes as it goes.

adb shell dmesg | grep -iE 'initcall|probe|took'

If a driver is slow to probe — a display panel, a CAN controller — the time is spent here, before Android has any say in it.

Stage 4 — init, the first process#

init is process ID 1, the ancestor of everything else. It is not Android; it is a small native program that reads configuration files and starts things.

service vendor.vega.vehicle /vendor/bin/hw/vendor.vega.vehicle
    class hal            # which group it belongs to
    user vehicle_network
    group system inet

init works in phases, and services are grouped into classes that start together:

Stage 5 — Early services, and the camera shortcut#

Among the first things init starts is EVS — the reversing camera path.

This is the exception to everything else on this page. EVS does not wait for Android, because it cannot: the regulation says roughly two seconds and Android needs fifteen. It is a small native service that talks to a camera and a display directly, and it is running long before the framework exists.

Stage 6 — Vendor HALs, including the VHAL#

class hal starts the hardware abstraction layers: audio, camera, graphics, and the Vehicle HAL.

The VHAL connects to the vehicle network, reads the initial state of everything it cares about, and registers itself so the framework can find it.

adb shell lshal | grep -i automotive.vehicle

Stage 7 — Zygote and system_server#

Now Android proper begins.

Zygote is a process that starts the Android runtime, preloads the common framework classes and resources, and then sits waiting. Every Android app is created by forking zygote, which is why apps start quickly — the expensive setup was done once.

system_server is the first fork. It starts the framework services: activity manager, window manager, package manager, and dozens more.

Stage 8 — Car Service, and the wait#

Car Service is a persistent system app. It starts after the framework is up, and the first thing it does is connect to the Vehicle HAL.

It blocks until the VHAL answers.

Once connected, Car Service asks the VHAL for its property configs, caches them, and starts its own subservices — audio, power, users, driver distraction — in dependency order.

Stage 9 — Launcher, and boot_completed#

The launcher starts, the home screen appears, and the platform sets sys.boot_completed=1.

That property is a starting gun. Everything in class late_start runs now. Deferred jobs become eligible. Garage Mode becomes possible.

adb logcat -b events | grep boot_progress
adb shell bootstat --print

boot_progress events are the framework's own milestones, and comparing them across builds is how you notice a regression before it reaches a requirement review.

The part most people miss: this usually does not happen#

Everything above describes a cold boot — the car has been fully off.

In daily use that is rare. The head unit normally suspends rather than shutting down, and comes back in about a second. The driver experiences resume, not boot.

A debugging order for "it did not boot"#

Work down. Each step is one command.

# 1. Did the kernel come up?
adb shell dmesg | head -50
 
# 2. Did init get past the early phases?
adb shell getprop init.svc.servicemanager    # running
 
# 3. Are the HALs up? (this is the automotive one that catches people)
adb shell lshal | grep -i vehicle
 
# 4. Did system_server start?
adb shell ps -A | grep system_server
 
# 5. Did Car Service start?
adb shell dumpsys car_service --help
 
# 6. Did boot complete?
adb shell getprop sys.boot_completed         # 1

The first of those that fails tells you where to look. Steps 3 and 5 are the two that are specific to automotive, and step 3 is the one that is most often the answer.

Next#

Getting a build of your own running, so you can watch all of this happen.