BYDMate Waze 3.16.1-dev.3

BYDMate Waze 3.16.1-dev.3 (development pre-release)

The lane strip is cropped from the rectangles Waze's own accessibility tree gives, instead of
being re-derived from the pixels, and Waze's reports list becomes the car's camera source.

Added

• Cameras from Waze's reports list. navListReportsList is plain text — a type row beside a
  distance row — and it is the one place on this build where a camera is a word. The nearest
  camera ahead is sent to the panel as sendCameraGuidanceInfo(1, metres, 1), the only camera
  call this cluster has been seen to draw (it is what puts the speed-limit roundel there), and its
  disappearance as the donor's clear, type 0 at -1 m. A camera nobody reports again for ten
  seconds leaves the glass on its own. Police and hazard rows are read and logged but draw
  nothing: they have no sign of their own yet. The words live in the language packs
  (assets/navi/phrases/<lang>.json, new "reports" section), never in code. Every change is a
  REPORT line in the trip log, and every panel write a PANEL line.
• Lane rectangles in the trip log. The LANES lines now carry
  display=… container=l,t,r,b cells=n [l,t,r,b …], so a drive finally says which widget the
  classifier looked at. Cells whose signature matched nothing carry their 225 shape bits
  (grid#i=…, at most eight per line), which is what the lane table has to be built from.
• Bounds on node discovery. Every TREE new id=… line ends with bounds=l,t,r,b.

Changed

• Lane crops come from the tree. Where laneGuidanceView has leaf children — 3, 5, 7 or 8 of
  them on the 2026-09-15 drive — their rectangles are the lane crops directly. The donor's column
  segmentation kept finding fewer cells than the tree has (3 against 5, 1 against 5) and is now
  only the fallback for a strip drawn as a single view. Each cell is classified at the same two
  thresholds as before, and a lane counts as on-route when its brightness reaches 0.9 of the
  brightest cell's, which is the donor's own rule.

BYDMate Waze 3.16.1-dev.2

BYDMate Waze 3.16.1-dev.2 (development pre-release)

The SDK camera call returns 0 on the Tang L and the panel draws nothing for any of its twenty
types. This release tries the instrument features BYD's own catalogue lists, and writes down what
Waze shows for the maneuver after the next one.

Added

• HUD Tester: raw-FID rows. "Camera (raw FIDs)" writes the type, distance and state straight
  to 0x43F03010 / 0x43F0301C / 0x43F03018 — type, then distance, then the display state —
  bypassing sendCameraGuidanceInfo. "Safety (raw FIDs)" does the same on
  0x43F04010/1C/18, and "Then (raw FIDs)" sends a secondary maneuver (icon, distance, action) to
  0x43F08010/18/30. Every write's raw status is shown on the card and written to the trip log as
  a PANEL line — logcat on the car rotates in minutes, the trip log is the only evidence that
  survives a drive. The existing SDK camera row now logs a PANEL line too.
• The Waze "then" glyph is recorded. navBarThenDirection is read on every pass and, when it
  changes, written to the trip log as a THEN line with the character and its code points
  (U+XXXX). It is an icon-font character, so the code points are the key the panel's secondary
  maneuver icons have to be mapped from. Nothing is sent to the panel from it yet.

Changed

• Node discovery reaches the lists. The per-read walk now visits 800 nodes instead of 300, and
  inside routeDetailsRecycler, eventsOnRouteContainer, eventsOnRouteView and
  instructionView it also records rows that carry no view id at all, as
  TREE new text='…' desc='…' class=… under=<container>. Those rows are exactly what the maneuver
  and report lists are made of, and the id-only walk never wrote down a single one. Deduped by
  text and description, 300 such lines per session.

BYDMate Waze 3.16.1-dev.1

BYDMate Waze 3.16.1-dev.1 (development pre-release)

Same code as 3.16.0-dev.10 plus one fix in the updater, republished under a version that a car
on dev.9 can actually see.

Fixed

• Update check on the development channel picked the wrong release. GitHub does not return
  /releases in date order: v3.16.0-dev.10 came fifth in the list, after dev.9…dev.6, and the
  app took the first entry, so every car on dev.9 reported itself up to date. The newest
  non-draft release by version is chosen now.

Carried over from dev.10

• HUD Tester: camera row (all 20 SDK camera types, distance, state; send / clear).
• Speed limit from Waze written to the panel the way openbyd does (sendSpeedLimitInfo).
• Trip log records every Waze accessibility node id seen for the first time in a session, with
  its text (TREE lines) — open the "Maneuvers" and "Reports" lists once during a drive.

BYDMate Waze 3.16.0-dev.9

BYDMate Waze 3.16.0-dev.9 (development pre-release)

Development channel. First fix from the dev.7 drive log (2026-09-11 21:25–21:44).

What the log showed

The pixel classifier works on this car: every left/right/straight/slight-right arrow matched
its Waze reference shape at hamming 0–1, the roundabout with exit 2 was recognised as such, and
the transliterated street name reached the panel with status 0 every time.

The phantom roundabouts had one source: whenever Waze reported no navBarDirection node, the
donor's fixed fallback rectangle was captured instead, which on this head unit is a piece of the
map. The map "matched" a roundabout 80 times in one drive, always at hamming 10–12, while no real
arrow ever scored above 8.

Fixed

• No navBarDirection node → no classification (the donor's phone-layout rectangle is dropped).
• The shifted-match tolerance is 9 instead of the donor's 18: the three remaining false hits
  (arrow shrinking mid-animation, partial crop) all scored 11–14.

Lanes

dev.7 read lanes only from accessibility labels, which this Waze build does not provide, so the
strip was sent with empty glyphs. dev.8/dev.9 read the strip from pixels; this is the first build
where the log will show whether that works on the car (LANES lines).

BYDMate Waze 3.16.0-dev.8

BYDMate Waze 3.16.0-dev.8 (development pre-release)

Development channel. Completes the openbyd port started in dev.7.

New

• HUD test screen (Settings → Display → HUD, AR-HUD block): openbyd's "HUD Tester" ported
  1:1. "Start Automatic HUD Test" cycles the donor's 49 steps every 3 s (arrow, distance, street
  name); "Send Manual Test Frame" pushes one frame with a chosen step, street, speed limit and a
  lane strip (code,front|…, default 1,255|0,255|0,255|4,3|3,3). Every SDK call reports its raw
  status on screen. Refuses to run while a Waze route is active; leaving the screen clears the
  panel. This is the way to check the glass while parked, without driving.
• Lane guidance from pixels: the donor's column segmentation of laneGuidanceView and
  per-lane signature classification; the highlighted lane's arrow doubles as the main arrow.
  The accessibility-label path stays as a fallback. LANES lines in the trip log.

Testbed

• The Waze stub now renders the real Waze arrow PNGs and exposes navBarDirectionText the way
  Waze does (exit number only), so the emulator gate exercises the classifier for real: all 17
  scenarios pass, every stub arrow matches its reference shape.

BYDMate Waze 3.16.0-dev.7

BYDMate Waze 3.16.0-dev.7 (development pre-release)

Development channel. The instrument-panel path is now a port of openbyd's field-proven
implementation, taken as the working solution rather than reconstructed from catalogues.

What openbyd does that we now do the same way

• Street name in UTF-16LE to feature 0x43FA1008, followed by the SDK call
  sendNextPathName. dev.6 wrote UTF-8 bytes and the panel decoded them as UTF-16LE, which is
  exactly the run of Chinese characters seen under the arrow. The write status 0 is now read as
  success (it always was; the code demanded > 0). The charset picker is gone; instead a
  "Sanitize HUD text" switch (on by default, like openbyd) transliterates the name to Latin.
  Switch it off to test raw Cyrillic on the glass.
• Navigation start/stop sequences: status 2 plus the setting-device screen layout 3 and the
  statistic-device navigation flag 1, re-armed whenever the panel reports anything but 2/621;
  stop clears every feature openbyd clears (icon, distance -1, street, trip fields, statistic
  segment fields, all lane slots) and calls the SDK sendAutoNaviStatus(4).
• Maneuver, rest route: the SDK calls sendSimpleGuidanceInfo and sendRestRouteInfo follow
  the feature writes; the remaining-seconds feature is written; roundabouts without an exit
  number draw glyph 25, unknown maneuvers draw straight (11), arrival draws 48.
• Lanes: 14 setting-device writes plus one 25-value instrument batch, exactly the donor's
  layout and glyph tables.
• Waze arrow recognised from pixels: the donor's 15×15 signature classifier with its 45
  reference shapes. Checked offline against the Waze APK pulled from this car: all 56 arrow
  drawables match, 54 of them bit-for-bit. The roundabout exit number comes from
  navBarDirectionText, so a roundabout with exit N draws glyph 24+N. Classification runs every
  2 s on every read, not only when the text path failed.
• Timing: 200 ms event debounce, route considered over after 40 s of silence.

Also fixed

• Two daemon verbs shared transaction code 40, so accessibility-service recovery through the
  daemon never ran.

Not in this build (next)

• Lane guidance read from pixels (the donor's column segmentation) and the HUD test screen for
  checking the glass while parked.

Trip log

Every classification writes a VISUAL line: target, matched shape, distance, glyph, exit number;
an unmatched arrow records its 225-bit grid so a new reference shape can be built from the log.

BYDMate Waze 3.16.0-dev.6

BYDMate Waze 3.16.0-dev.6 (development pre-release)

Development channel. Everything here exists because the dev.5 drive produced no evidence.

The car ran the right build, the drive is in the log, and BYDMate wrote not one line about
guidance for its whole duration. The trip folder was empty. So there was nothing to say about why
the roundabout was wrong or why the panel filled with Chinese characters — and guessing from a
symptom is how the last three of these went. This release is about making that impossible to
repeat.

Fixed

• Turning the trip log on starts recording immediately. startTrip() was reachable only from
  TrackingService.onCreate, and the service has been running for a long time by the moment
  anyone opens settings — so the switch did nothing at all until the next ignition. That is
  precisely how a drive was lost.
• The trip log is on by default on the development channel. The entire point of the feature is
  the drive that cannot be observed any other way: Wi-Fi is gone the moment the car leaves the
  driveway. A switch defaulting to off produced exactly one outcome in the field — an empty folder
  after the drive that mattered. An explicit "off" still wins. The stable channel is unchanged.
• A silent HUD now says why it is silent. With guidance inactive the push loop returned without
  logging, so afterwards "we never pushed anything" and "we pushed and then stopped" looked
  identical. Every ~30 s it now writes a line naming the actual state: accessibility service not
  bound, navigator window unreachable, events arriving but carrying no guidance, projection off.

New

• Street name encoding (Settings → Display → HUD, AR-HUD only): Auto, UTF-8, GBK, UTF-16LE,
  UTF-16BE. The panel decodes the byte array itself and its reply never says with which charset —
  the write status is positive for all of them, so the panel cannot be asked. Auto applies the one
  rule that is more than a guess: the overseas feature belongs to an export firmware and takes
  UTF-8, the domestic one to a Chinese build and takes GBK. Cyrillic UTF-8 bytes read as GBK render
  as a run of Chinese characters, which is exactly what the Tang L drew under the arrow on dev.5 —
  so the bytes do reach the glass, and only the charset is wrong. The chosen charset and the first
  bytes go into the trip log.

What the next drive should answer

The trip log now records, per changed value: what Waze showed, the maneuver code sent to the panel
and whether it was accepted, the lane cells and how they parsed, which of the two street-name
features the firmware took, and under which charset. If the panel still shows Chinese, switch the
encoding in settings until Cyrillic appears — no drive needed for that part, the name updates on
the next maneuver.

BYDMate Waze 3.16.0-dev.10

BYDMate Waze 3.16.0-dev.10 (development pre-release)

Development channel. After the Tang L drive on dev.9: arrows, roundabouts, the street name
and the lane strip all render on the instrument panel. Next up are the two things that do not:
cameras and the speed limit.

Speed limit on the panel

The live path now sends openbyd's sendSpeedLimitInfo whenever the limit read from Waze changes:
both segment-speed statistics plus the CAMERA_TYPE_SPEED_LIMITED call that actually draws the
roundel (state 1 while a limit is known, 0 when it goes away). Only on change, like the donor, and
the trip log carries a PANEL speed limit line for every one of them.

HUD Tester: camera row

A type picker over the SDK's twenty CAMERA_TYPE_* constants, a distance and a state, "Send
camera" and "Clear camera" (the donor's type 0 / distance -1 / state 1). The raw SDK status is on
screen. Nothing but a parked car and a look at the glass can say which of those twenty signs this
cluster really draws — that is what the row is for.

Waze node discovery

The camera and speed-limit alerts are drawn by Waze views nobody has named yet, and the existing
per-maneuver tree dump is rate-limited and carries no text, so a panel that appears for ten
seconds never shows up in it. Every Waze read now writes one TREE new id=… line the first time
it sees a view id in a session — id, text, description, class — capped at 200 ids per session.
Diagnostics build only; the trip log stays on the car.

BYDMate Waze 3.16.0-dev.5

BYDMate Waze 3.16.0-dev.5 (development pre-release)

Development channel. Street names on the instrument panel, debug mode, default automations.

New

• Street name on the panel. Its next-street features take a byte array and the helper daemon
  only wrote integers, so the name was never sent. A new daemon transaction carries bytes by
  calling BYD's own SDK the way the factory navigation does, rather than guessing an undocumented
  binder transaction against a live vehicle bus. BYD ships two such features, domestic and
  overseas; both are tried, overseas first, and the one the panel accepts is kept. The trip log
  records which one won.
• Debug mode: trip logs (Settings -> Service and data, off by default). The car writes its own
  guidance record per ignition cycle to Download/BYDMate-trips: every changed Waze read with the
  raw street text, the lane cell labels and what they parsed to, the maneuver code sent to the
  panel and whether it was accepted. Wi-Fi is not involved, so the drive that matters is finally
  observable. Newest 12 trips kept.
• Default automations, seeded once and then yours: open Spotify and start playback, and open
  Waze. Both fire on start-up, once per trip. Updates never re-add or overwrite them.
• Adds a media_play action - launching a player opens it but starts nothing.

Fixed

• Maneuver glyphs. The panel numbers its icons differently from our internal codes. The raw
  code drew a detour for a roundabout, a slight left arrow for a slight right, and the Chinese
  destination glyph on arrival. All three reported from the car, all three covered by tests now.
• Lane direction inside a multi-direction lane follows the maneuver instead of the first arrow.
• Lane labels come from a new lanes section in the language packs, so they work in every
  language rather than only Ukrainian by accident.

Faster start-up

The boot worker was a plain WorkManager request waiting on the scheduler while the head unit was
busy booting. It is now expedited. How much this saves on your car will show in the trip log and
ChainLog, which now carry the timestamps to measure it.

BYDMate Waze 3.16.0-dev.2

BYDMate Waze 3.16.0-dev.2 (development pre-release)

Development channel. Lane guidance, corrected against BYD's own feature catalogue.

Fixed

The car carries BYD's own name catalogue for every vehicle feature (com.byd.feature, 11,483
entries). Checking the lane feature ids against it confirmed the layout exactly — the lane count,
and per slot an arrow, a line type and a recommended flag, repeating every 16 — but showed that two
fields mean something different from what the donor's code suggested:

• what was treated as a slot "state" is INSTRUMENT_n_LANE_LINE_TYPE_SET, the divider style;
• what was treated as a "valid" flag is INSTRUMENT_IS_LANE_n_RECOMMENDED_SET.

The donor set the recommended flag to 1 for every lane present, which cannot be right for a field
with that name. It is now set only for the lanes the route actually takes. The arrow glyph carries
the highlight too, so a panel that ignores the flag still shows the right thing. If the strip fails
to render at all in the car, the donor's values are one flag away.

Note on speed limits

Waze only shows the limit while you are over it, which is why every log line so far reads
limit=0. In Waze, Settings -> Speedometer -> Show speed limit can be set to always, which would
give a continuous reading for the panel.