Targets — trims, WebView & host

Two independent gates decide whether a mini-app runs on a given car. A build must pass both. Most "works on L8 but blank on L5" reports are one of these.

The two gates

1. Runtime gate (the WebView). Can the trim's WebView execute your bundle at all? Di5.0 ships Chromium 95 (verified on-car: com.android.webview 95.0.4638.74). Chromium 95 runs all ES2022 syntax, so the constraints are narrower than "old browser": (a) the Di5.0 mini-app host loads a classic script, not an ES module — a Next.js /_next/, Vite-ESM, or <script type="module"> bundle silently does not run (no error, blank screen), and (b) runtime APIs added in Chrome 96+ (structuredClone, Array.findLast, Promise.withResolvers, …) are absent. See the Troubleshooting entry ("Mini-app blank on L5 … but works on L8").

   Enforced since i99dash 5.1. No longer a discover-it-in-production failure: i99dash build (and therefore i99dash publish) statically checks every shipped JS file against the Di5.0 baseline (WEBVIEW_BASELINE — ES2022 syntax ceiling, classic/IIFE format, no Chrome-96+ APIs) and hard-fails on a violation. The only opt-out is declaring the app Di5.1-only (see the escape hatch below).

2. Launch gate (minHostVersion). The host refuses to launch a mini-app whose manifest.json minHostVersion exceeds the host's own version. It is hard-enforced — there is no override (see What is a mini-app?).

Trim matrix

Any trim not listed: treat an unknown trim as Di5.0 (assume the strict gate) until you confirm otherwise from display.list's vehicle.dilinkFamily at runtime.

"Runs ES modules? No" on Di5.0 is the host behaviour, not a Chromium-95 engine limit: the Di5.0 mini-app host loads a classic script only. Build the classic IIFE and this column stops mattering.

Declaring an app Di5.1-only (the escape hatch)

If an app genuinely needs a modern bundle or APIs and you accept it won't run on Di5.0, declare that in manifest.json requires so the backend catalog hides it from Di5.0 cars (rather than serving a bundle that's dead on arrival):

{ "requires": { "modernWebview": true } }

or restrict the DiLink generation explicitly:

{ "requires": { "dilink": ["di5.1"] } }

With either set, i99dash build/publish downgrades the WebView- baseline check to an informational note (Gate A already excludes the app on Di5.0). The model is binary: stay within the Di5.0 baseline → one bundle runs on 5.0 and 5.1; or declare Di5.1-only → it's hidden on 5.0. There is no in-between "ships but blank" state.

What "classic IIFE bundle" means

esbuild src/main.js --bundle --format=iife --target=es2019 plus a plain <script src="./app.bundle.js"></script> (no type="module"). This single bundle runs on both Di5.0 and Di5.1, so when in doubt, build this way for everything. The SDK bundles cleanly into it — you do not have to hand-roll the bridge to get a classic bundle. Full walkthrough: Build for L5 + L8.

Choosing minHostVersion

minHostVersion is a launch floor, not a feature switch. Set it to the lowest version your code actually needs, so the host on older trims still launches the app:

• If the app only reads context / calls the backend / reads the car.* catalog, keep it low.
• Raising it does not add capability — it only narrows the set of cars that will launch the app at all.
• For features the host may not implement on older builds, detect at runtime instead of gating the whole app — see Capability detection.

There is no per-trim host-version table: host builds vary by ROM and update independently of the trim. Treat minHostVersion as "the oldest host I can tolerate" and feature-detect everything above that.

Related

• Build for L5 + L8 — the end-to-end build.
• Capability detection — degrade per host.
• Host catalog status — what the v2 catalog ships now vs. v5.1.
• Trim × capability matrix — per-trim vehicle hardware capabilities.