i99dash docs
Native apps

Native apps

Invited developers publish native Android APKs that install on BYD cars as standalone child apps, distinct from WebView mini-apps.

A native app is a release-signed Android APK you publish to the i99dash catalog. The car installs it as a separate, standalone package that launches full-screen — it is not loaded inside the host. You bring your own Android build; the SDK hashes, attests, uploads, and submits the .apk you point it at. The SDK does not build Android.

Native apps vs mini-apps

A WebView mini-app is a static web bundle the host loads inside a sandboxed web view, sharing the host process. A native app is the opposite: a separately installed Android package with its own process and a full-screen launch.

Mini-appNative app
What shipsA .tar.gz of static web filesA release-signed .apk
Where it runsInside the host web viewA standalone installed package
LaunchWithin the hostFull-screen, on its own
InstallCatalog entry, no device installAndroid install dialog the owner confirms
GateOpen publishInvite-only + human review
CLI groupi99dash <init|build|validate|publish>i99dash apk <...>

When to choose native

Choose native when you need capabilities a sandboxed web view cannot give you — a camera pipeline, background services, hardware access, or an existing Android codebase you want to ship as-is. If your app reads context and calls backend APIs, a mini-app is lighter and has no review gate or device install. Reach for native only when the web view is the constraint.

Prerequisites

Native publishing is invite-only in v1. Your account needs the can_publish_native grant; without it, apk upload-url and submit return 403. The SDK CLI signs in with an SSH key — the one CLI credential. Register your key and log in per Authentication. That same SSH key also attests every artifact you publish (this is K1 in the trust model).

The lifecycle

You publish a release, an admin reviews it, you promote the approved release to a rollout, and cars install it on owner consent:

  1. Publish — the CLI validates apk.json, hashes the .apk, attests it with your SSH key, then uploads and submits the manifest.
  2. Review — native code on a vehicle is higher-risk, so a submit defaults to pending human review, not auto-approve. The admin moves it to approved or rejects it.
  3. Promotei99dash apk promote --rollout N exposes the approved release to a stable per-car bucket (so --rollout 10 reaches roughly 10% of cars). Raise it as confidence grows.
  4. Install — the car polls OTA and offers the update. It installs via the standard Android dialog the owner confirms.

See Distribution and rollout for the full state machine.

Verify before install

The car verifies every APK offline before it offers the install dialog. When an admin approves a release, the platform mints an Ed25519-signed envelope over the release manifest; the car checks that envelope against a pinned platform public key, then re-checks the APK SHA-256, the signing-cert SHA, that the versionCode is not a downgrade, and that the package is not revoked. Any failure means no install (fail-closed). This is supply-chain integrity — verify before install, not code secrecy. See Signing and trust.

There is no silent install for third-party apps. The owner confirms every install and can uninstall from the car's Native Apps tab.

Next

On this page