Skip to content

Development & delivery

Feature on demand

Selling software capability after the vehicle is built — how entitlement actually works end to end, why some attempts were rejected by customers, and the engineering it forces on you.

Intermediate7 minFeature on demand · Business model · Architecture

is the commercial reason many SDV programmes are funded. It is also the part of the SDV story that has generated the most customer anger, and the difference between the two outcomes is worth understanding precisely.

The idea#

The software already shipped — what changes is an entitlement, not the codeCustomer buysapp or portalBackendissues entitlementVehicleverifies signatureFeature enabledno reflashWhat must be true for this to be safeentitlement is signed · verified locally · works offline · expiry evaluated on the vehiclehardware is present and validated whether or not the feature is boughtthe honest tension: customers dislike paying for hardware they already ownfeatures that were never physically installed avoid that objection entirely
One build, capability gated by entitlementThe hardware and software are present in every vehicle. What differs is the entitlement the vehicle holds, and what it therefore permits.

Where it works, and where it does not#

This is the crux, and it is not subtle once stated.

ReceptionKind of featureExamples
AcceptedOngoing service with ongoing costLive traffic, connected navigation, remote services, hotspot data
AcceptedGenuinely new capability delivered laterA driver-assist function that did not exist at build
AcceptedTemporary or occasional useTrailer-towing mode for one weekend, a trial before buying
RejectedHardware present, artificially disabledHeated seats you can feel under you, unlocked by subscription
RejectedCapability the customer believes they boughtFull battery range, already-fitted acceleration

Gotcha

This is a genuinely useful thing to raise in a design review, and it is a technical point as well as an ethical one. Features on the wrong side of the line generate customer anger, press coverage, regulatory attention, and — very reliably — an aftermarket unlocking industry that becomes your security problem.

Engineering effort spent gating a feature customers believe they own is effort spent building something you will later be asked to remove.

How entitlement actually works#

The mechanism is the same regardless of the feature.

  purchase (app, web, in-car store)


   ┌──────────────────┐
   │ entitlement      │   the authority: which VIN owns what, until when
   │ service (cloud)  │
   └────────┬─────────┘
            │ signed entitlement token, bound to VIN, with expiry

   ┌──────────────────┐
   │ vehicle          │   verifies signature, stores securely,
   │ entitlement mgr  │   re-validates when connectivity allows
   └────────┬─────────┘

   ┌────────┴──────────┬──────────────────┐
   ▼                   ▼                  ▼
 feature flag      capability        UI visibility
 in the ECU        in the VHAL       in the app
 that performs     that permits      that presents
 the function      the write         the control

Gotcha

Enforcing entitlement only in the app layer is the classic mistake. Someone will send the underlying intent, call the API directly, or install a modified APK.

The rule is the same as any authorisation design: the layer that performs the action is the layer that must check. In practice that means the VHAL implementation or the vehicle-side service, not the Activity.

What this forces on the engineering#

FoD is not a feature you add at the end. It changes how the whole build is structured.

One image, many configurations. You can no longer branch the build per trim, because every vehicle ships the same software. Differences become runtime state. This is a good discipline — it collapses the variant matrix that makes automotive CI slow — but it has to be designed in.

Every feature needs a defined off state. Not "the button is hidden" but what the whole system does: what the cluster shows, what a voice command answers, what happens if an entitlement expires mid-drive. Those are product decisions that need answers before code.

Graceful expiry. A subscription ending while the vehicle is moving must not change vehicle behaviour abruptly. The usual rule is that anything affecting driving continues until the vehicle is next parked.

Testing multiplies. Every FoD feature at least doubles its own test matrix: entitled, not entitled, expired, expiring during use, offline with a cached token, offline with an expired token, and transferred to a new owner.

Ownership transfer. When the vehicle is sold, entitlements must move or end predictably. Getting this wrong produces a second owner who paid for a car whose features silently stopped, which is a support and reputation problem.

Doing it without antagonising customers#

Patterns that have worked in practice:

Charge for ongoing cost, not for unlocking. The clearest test of whether a feature belongs in the catalogue.

Offer permanent purchase alongside subscription. Customers object far less when a subscription is a choice rather than the only route.

Be explicit at the point of sale. "This vehicle includes the hardware; this function requires a subscription" printed clearly is a different transaction from a discovery in year two.

Let trials be genuine. A trial that converts silently into a charge is the fastest way to lose the argument.

Never gate safety. Emergency braking, stability control, warning telltales. Some markets are moving to make this explicit in regulation; the reputational cost already makes it settled.

Make ownership transfer work well. It is the cheapest goodwill available and the most commonly neglected.

Next#

What the fleet produces and where it goes — vehicle data pipelines.

References & further reading

Code links target the main branch on cs.android.com. AOSP moves — if a path 404s, search the symbol instead.