A software-defined vehicle is only software-defined if software can actually get onto it. That is less obvious than it sounds — the route determines what your software can do and how often it can change.
The four routes#
| Route | Who decides | Cadence | Vehicle access |
|---|---|---|---|
| System image | The OEM | Vehicle programme gates — months | Anything, including vehicle control |
| OEM store | The OEM | Their review cycle | Usually read-only vehicle data |
| Public store | The store, on GAS-style vehicles | Yours | Normal permissions only |
| Sideload | You, on a dev unit | Immediate | Whatever the build allows |
What the system image route actually means#
The OEM store#
Most non-GAS vehicles have a manufacturer store. Practically, each is a separate integration project — its own submission process, review criteria, and often its own SDK for identity and payment.
Three questions before committing:
- What is the review turnaround, and is it tied to vehicle gates?
- Are additional permissions available to store apps, or only to system apps?
- Is there a test fleet, or does validation need a physical vehicle?
What runs where#
An SDV cockpit typically hosts several kinds of software with different rules:
Native platform components. Part of the image, full access, OEM cadence.
Templated apps. Navigation and point-of-interest apps built from a fixed template set the platform renders. Safe by construction, which is why third parties are allowed to ship them.
Media apps. Serve a content tree and a playback session; the car draws the UI.
Full applications. Draw their own screens. Usually restricted to OEM and system apps, because they carry the whole driver-distraction burden themselves.
Web content. Increasingly used for parked-only experiences — manuals, account management, purchase flows — where the update cadence benefit outweighs the constraints.
Keeping it updatable#
Getting software onto the vehicle is half the problem. Keeping it updatable for fifteen years is the other half.
Every dependency is a fifteen-year commitment. A library abandoned in year four becomes an unpatchable vulnerability with a regulatory obligation attached. "Small and boring" is a security requirement here, not an aesthetic preference.
Interfaces to platform services must be versioned, because they will move underneath you.
The app must tolerate an older platform. A vehicle three model years old is still in the field and still yours.
Feature detection, not version detection. Ask whether a capability exists rather than inferring it from a platform version — trims differ within a version.
Sideloading during development#
# Install for the CURRENT foreground user
adb install -r --user current app.apk
adb shell am get-current-user
# A privileged app cannot be installed this way — it must be pushed
adb root && adb remount
adb push app.apk /product/priv-app/MyApp/MyApp.apk
adb shell stop && adb shell startA decision order#
- Does it actuate the vehicle? → system image. Talk to the OEM now.
- Is it media or templated on a store-equipped vehicle? → store route. Read the quality guidelines before designing.
- Neither? → per-OEM store integration, one project per manufacturer.
- Still exploring? → sideload, but do not let a prototype's permissions set expectations the distribution route cannot meet.
Next#
How this software actually gets built and delivered — starting with virtual ECUs.