Tesla BLE onboarding: app-driven discovery, VIN provisioning, staging beat (Android) - #201
Closed
dkneeland wants to merge 4 commits into
Closed
Tesla BLE onboarding: app-driven discovery, VIN provisioning, staging beat (Android)#201dkneeland wants to merge 4 commits into
dkneeland wants to merge 4 commits into
Conversation
dkneeland
changed the title
dkneeland
force-pushed
the
feat/tesla-ble-phase4
branch
from
August 24, 2026 01:35
8706de9 to
efc24e9
Compare
- Add TeslaStatus model + parser and TeslaClient with app-channel opcodes (0x01 start / 0x02 reset / 0x03 cancel) on the new CADA0200 service. - Add TeslaStatusSource (GattListener) subscribing to CADA0202 -> StateFlow. - Add one-line TeslaTile on Home (key-not-set-up / staged / connected / not-connected; first two open the enroll flow). - Add standalone TeslaEnrollFlow (Start -> tap-window countdown + Cancel -> success/fault) driven by the status flow; DevicePuck gains an accent param. - Add Settings > DashKit > Tesla key section: status, enroll, two-phase reset. - Wire nav route TeslaEnrollRoute + status source lifecycle in MainActivity; cyan #4FD1FF in Color.kt; strings in strings.xml. Review findings folded in: read current status on subscribe (fresh subscribers don't wait for a reconnect backoff) + handle onCharacteristicRead; proper HomeTile text for PairingWindow/EnrollmentFault; ErrorStep maps TeslaFaultDetail.None to a neutral message; hoisted recreate-on-recompose fallback StateFlows to stable remember values; added TeslaStatusTest covering the 7-byte frame parser + link-state mapping. Also drops dead tesla_enroll_confirm/_card_detected/_already_enrolled strings - the firmware exposes no such discrete states (ponytail-audit).
Android's GATT client allows only one operation in flight, and the app subscribes to two characteristics back-to-back when services become ready (CAN + Tesla status). The second CCCD write could be refused while the first was pending, and writeDescriptor()'s return value was ignored, so the dropped subscribe looked like success: no CAN frames arrived (Connected is gated on the first CAN frame, so onboarding stalled at Pairing), or the status tile went stale with no error. Check writeDescriptor()'s return value and retry (3 attempts, 250 ms apart) via a shared DashKitBleManager.subscribeWithRetry(), now used by both the CAN datasource and the Tesla status source. Supersedes #200.
Rebrand on-screen Tesla copy from key/enroll/set up key to Connection/connect/remove: Settings section 'Tesla key' -> 'Tesla Connection' with caption; actions 'Connect Tesla' / 'Remove Tesla connection' with remove/reconnect dialog and toasts; enroll flow 'Connect to your Tesla' / 'Connect' / 'Connected' / 'Connection failed'; pair caption reflects the separate connection. Tile: right-justify status text (TextAlign.End), single-line ellipsis, 16 dp spacer before the chevron; 'Tesla' label stays left. Show negative statuses (not present/unlocked/awake) and a 'Connection failed' fault state on the tile. Internal identifiers (tesla_enroll_*, TeslaKeySection, NeverEnrolled) and 'key card' wording left as-is; user-facing copy only.
App-driven onboarding for the Tesla flow:
- live scan of nearby Tesla adverts, deduped and expired after 10 s
without an advert; both the rendered list and the auto-match derive
from that live window
- VIN entry validated by charset/WMI plus the ISO 3779 check digit; a
failing digit requires a per-VIN "Stage this car anyway" override
- explicit staging beat: decoded identity card (model/year/plant/drive)
with a "Stage this car" CTA; TESLA_CMD_PROVISION fires only on tap
- confirmed car identity carried through start/connecting/tap-window/
success/fault screens as a muted one-liner
- Home/Settings tile reworded to recent-past ("Car seen nearby") to
match its latch-on-first-sighting design
- TeslaStatusTest covers frame-version rejection
- adds ble/TeslaVinDecoder.kt + its unit tests (previously untracked;
clean checkouts could not build without them)
dkneeland
force-pushed
the
feat/tesla-ble-phase4
branch
2 times, most recently
from
August 24, 2026 01:43
7cea3ba to
f3a5ca4
Compare
dkneeland
marked this pull request as draft
August 24, 2026 16:01
This was referenced Aug 25, 2026
Collaborator
Author
|
Superseded by a stacked series that carries this work forward with the post-review audit fixes applied and the manual-VIN / nearby-car approach removed:
Merge order: 206 -> 207 -> 208 (squash each; retarget + Update branch the next as bases collapse onto main). Context: docs/android-vin-onboarding-plan.md. The \pr/201\ branch is left intact for reference. |
This was referenced Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Phase 4 Tesla BLE app-channel UX for Android, plus two GATT-busy subscribe fixes. On-car validated end-to-end (enrollment via key card + touchscreen confirm, live status, rebrand UX). Supersedes #200 - the CAN retry fix from that PR is included here (as its own commit) and extended to the Tesla status subscription.
Three commits:
feat(android): Phase 4 Tesla BLE app-channel UX- TeslaStatus model/parser, TeslaClient (opcodes 0x01/0x02/0x03 on the CADA0200 service), TeslaStatusSource -> StateFlow, one-line Home tile, standalone enroll flow (DevicePuck-based), Settings section with two-phase reset. Review findings folded in (parser unit tests, subscribe-time status read, recompose-stability) and deadtesla_enroll_*strings dropped.fix(android): retry GATT subscribes dropped by the GATT-busy race- Android's GATT client allows one op in flight; back-to-back CCCD writes (CAN + Tesla status on service discovery) could be silently refused becausewriteDescriptor()'s return value was ignored. Now checked and retried (3 attempts, 250 ms) via a sharedDashKitBleManager.subscribeWithRetry()used by both call sites. Includes and generalizes the fix(android): retry CAN subscribe dropped by GATT-busy race #200 fix.feat(android): Phase 4 Tesla Connection UX rebrand + tile alignment- user-facing copy rebranded from "key / enroll / set up" to "Connection / connect / remove"; single-line captions; tile status right-justified with 16 dp chevron spacing; negative statuses (not present / unlocked / awake) and a Connection-failed fault state now render. Internal identifiers (tesla_enroll_*,TeslaKeySection,NeverEnrolled) intentionally unchanged; "key card" (physical card) wording kept.Testing
:app:assembleDebug -x :app:syncDashAppsclean; unit tests pass (TeslaStatusTest).Notes for reviewers/testers
link_statebyte). Against older firmware the tile simply shows not-connected.Update 2026-08-23 — full onboarding flow + audit remediation
The branch now carries the complete app-driven onboarding experience and the fixes from the firmware/Android audit (companion to dashkit-firmware#58):
New since this PR opened
TESLA_CMD_PROVISIONfires only on tap, never automatically.ble/TeslaVinDecoder.kt+ unit tests (previously untracked; required for build).Validation:
compileDebugKotlin+ fulltestDebugUnitTestgreen on this exact tree; on-car enrollment validated end-to-end (tap recognized within seconds of keycard confirm).