i99dash docs
BYD API

BYD API

How i99dash reaches the BYD automotive framework — the ~21k feature catalog, the live subset that's actually bound on your car, and the push-driven SDK surface that exposes both.

i99dash talks to the BYD head-unit through one Android framework class — android.hardware.bydauto.BYDAutoFeatureIds — and a small set of device-typed AIDL services beneath it. This section is the public reference for that surface: what's in the catalog, what goes live on each trim, and how the SDK turns the framework's push events into reactive Dart streams.

At a glance

┌─────────────────────────────────────────────────────────────────┐
│ Framework catalog            BYDAutoFeatureIds                  │
│   ~21,000 public static     (~10–11k unique constants,          │
│   final int constants        stored both bare and prefixed)     │
└─────────────────────────┬───────────────────────────────────────┘
                          │ reflected at boot

┌─────────────────────────────────────────────────────────────────┐
│ Auto-discover            AutoCarRegistry                        │
│   probes every catalog    keeps the first non-sentinel reading  │
│   name × 7 WARM_DT        for each name (~9k live on Leopard 8) │
└─────────────────────────┬───────────────────────────────────────┘
                          │ push subscribe

┌─────────────────────────────────────────────────────────────────┐
│ Bridge                   CarChannel  (i99dash/car…)             │
│   allFeaturesAuto       allKnownFeatures                        │
│   labelToCatalog        registryStats / watchdogStats           │
│   EventChannel `i99dash/car/registry` — {name, value} deltas    │
└─────────────────────────┬───────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────┐
│ Dart SDK                CarRegistryClient + featureValueProvider│
│   one client app-wide   one push subscription                   │
│   reactive watch        autoDispose per-feature stream provider │
└─────────────────────────────────────────────────────────────────┘

Sections

PageCovers
CatalogThe ~21k framework catalog — what BYD defines, why nested classes are stored bare + prefixed, how to enumerate it.
Auto-discoverHow AutoCarRegistry probes the catalog, the WARM_DT device-types, the sentinel filter, the cache fast-path.
Live vs. knownWhy your car shows ~9k live features when the framework reports ~21k — the probe math, dedup, and write-only commands.
Bridge surfacesThe five method channel verbs and the registry EventChannel — wire shapes, threading, error envelopes.
Consumer SDKCarRegistryClient and featureValueProvider — discovery, reactive watch, write. The whole Dart surface.

What this section is not

  • Not a mini-app SDK surface. Mini-apps reach car state through the MiniAppClient bridge (client.car.*), which is built on top of this layer. See The bridge for that surface.
  • Not a tutorial. It's reference material — read by people who want to understand the engine, debug a missing feature, or contribute to the host.
  • Vehicle profile — per-trim capability gating.
  • Trim × capability matrix — what every BYD trim seeds by default.
  • The internal engineering docs at car-i99dash/docs/car-sdk-layers/ cover the production-grade end state from the host implementer's perspective.

On this page