Vitaly

Firmware update 34.1.35.2602261.1Firmware version34.1.35.2602261.1ModelsBYD Titanium 7Update contentUnknownChipset34 chipsetRegionChineseDetailsDi5.1_34.1.35.2602261.1 🇷🇺 Китайская прошивка на 34 чипсет. 🇺🇸 Chinese firmware for 34 chipset. 🇺🇿 34-chipset uchun xitoy proshivka LinksLink Update instruction:

DashCast v1.2.11DashCast v1.2.11 — build 202 (pre-release) Target branch: beta/1.2.0-dilink5 Platforms affected: DiLink 5 (testeur) only — fix is gated by Platform.isDiLink5. DL3 / DL2 unaffected. Protocol: PROTOCOL_VERSION=2 unchanged APK: DashCast-v1.2.11-debug.apk (14 MB, versionCode 202, versionName 1.2.11) versionCode 201 → 202 so the BYD AUTO OTA installer recognises this as an update over v1.2.10 — no uninstall required. Why this release Field report (May 23, 2026) on DL5 testeur with v1.2.10 installed, system locale = Russian, Yandex Maps active on the cluster. Two coupled symptoms reported from a single screenshot: A French opaque banner appeared at the top of the head-unit screen the moment the keyboard bridge was triggered (manually or via the a11y service). Title Clavier déporté, hint Tapez ici : chaque caractère est envoyé au champ actif du cluster., three buttons Entrée / Retour / Fermer. The banner was in French regardless of the system locale and intrusively covered part of the live cluster mirror. Characters typed on the system IME never reached the Yandex search field on the cluster. The keyboard popped up, the user typed, but nothing appeared on the cluster side. The user explicitly hypothesised this was the same root cause as the May 22 touch-injection bug (v1.2.7 fix: MotionEvent.setDisplayId(2)). They were right — same pattern, applied to KeyEvent this time. Root cause #1 — Visible chrome (always FR, intrusive) KeyboardBridgeActivity was authored in v1.2.8 with a full LinearLayout: title TextView + hint TextView + visible EditText + 3-button row, semi-opaque dark background 0xCC202020, MATCH_PARENT × WRAP_CONTENT pinned at the top of display 0. The visible chrome was purely cosmetic — the system IME pops up regardless of EditText visibility — but the strings were never translated to the 11 supported locales and the overlay was always present, covering part of the cluster mirror. Fix — invisible 1×1 px bridge window KeyboardBridgeActivity.onCreate rewritten: Removed the entire LinearLayout + title + hint + 3-button row. Window is now 1×1 px pinned BOTTOM | END, transparent background (android.R.color.transparent), dim 0f. Sole content view is the focused EditText, stripped of every visible property: setBackground(null) transparent text & hint colours (0x00000000) setCursorVisible(false) zero padding The IME still pops up automatically thanks to SOFT_INPUT_STATE_ALWAYS_VISIBLE + mImm.showSoftInput posted on the EditText. The 1 px footprint means the rest of display 0 (DashCast UI, cluster mirror tile) stays interactive — touches outside that 1 px fall through to the windows below. Enter forwarding preserved via the existing OnEditorActionListener (IME's Done/Search/Send button → KEYCODE_ENTER injected to cluster). Back key naturally closes the activity (Android default onBackPressed). Unused imports (View, Button, LinearLayout) and the unused dp(int) helper removed. The translated keyboard_bridge_* strings remain in values/strings.xml for the activity label in the manifest (android:label=@string/keyboard_bridge_title, but excludeFromRecents=true so the label is never user-visible). Root cause #2 — Keys never reach the cluster MirrorDaemon.injectKey(KeyEvent) (uid 2000 daemon) called InputManager.injectInputEvent(kev, ASYNC) without first calling KeyEvent.setDisplayId(sClusterDisplayId). Without the displayId override, the system InputDispatcher routes the key to the globally focused window — and on multi-display Android 12, focus is per-display: our own KeyboardBridgeActivity on display 0 owns the head-unit focus and swallows every injected key. The cluster app on display 2 never sees a single KeyEvent. This is the exact same root cause as the May 22 touch-injection bug (MotionEvent wasn't routed to display 2). v1.2.7 fixed touch by adding MotionEvent.setDisplayId(clusterId). The symmetric KeyEvent.setDisplayId(clusterId) call was simply never added when the keyboard bridge shipped in v1.2.8. Fix — KeyEvent.setDisplayId(clusterId) in both injection paths daemon/MirrorDaemon.java (primary daemon-uid path): New static sSetDisplayIdKey Method cached via KeyEvent.class.getDeclaredMethod("setDisplayId", int.class) alongside the existing sSetDisplayId for MotionEvent in initInputManager(). injectKey(KeyEvent) now calls sSetDisplayIdKey.invoke(kev, sClusterDisplayId) (with inner try/catch so a reflection failure still attempts the bare inject) BEFORE InputManager.injectInputEvent. First-event log line upgraded: injectKey FIRST OK displayId=N setDisplayIdAvail=true/false keyCode=K action=A (mirror of the existing motion log) so the next field capture exposes whether the override took effect. dashboard/ClusterInputForwarder.java (direct app-uid fallback, used when daemon Binder is null): New instance mSetDisplayIdKeyMethod cached in the constructor. Applied in the direct-fallback path of injectKeyEvent(KeyEvent) immediately before InputManager.injectInputEvent. Both paths now route keys to the cluster display id (typically 2 on DL5 — same as touch). Behavioural contract DL3 Seal EU (production): the ⌨ button is hidden (Platform.isDiLink5(this) ? VISIBLE : GONE), the a11y service short-circuits on !isDiLink5, the bridge is never launched → zero observable change. DL5 testeur: Tap the ⌨ button or focus an EditText on the cluster (with the a11y service enabled) → no visible overlay, IME pops up at the bottom of display 0. Each typed character → KeyCharacterMap → KeyEvent[] → setDisplayId(clusterId) → daemon injectKey → cluster app's focused EditText receives the keys natively (no app-level integration needed). IME's Done/Search/Send button → KEYCODE_ENTER injected to cluster (e.g. triggers Yandex Maps search). DL2: completely unaffected (no cluster, ⌨ button hidden, a11y service inert). Touched files File Change app/build.gradle versionCode 201 → 202, versionName "1.2.10" → "1.2.11" app/src/main/java/com/byd/dashcast/daemon/MirrorDaemon.java +sSetDisplayIdKey field, +KeyEvent.class.getDeclaredMethod("setDisplayId") lookup in initInputManager, +setDisplayIdKey.invoke(kev, sClusterDisplayId) in injectKey with inner try/catch, +upgraded first-event log (~15 LoC net). app/src/main/java/com/byd/dashcast/dashboard/ClusterInputForwarder.java +mSetDisplayIdKeyMethod field, cached in ctor, applied in direct-fallback path (~10 LoC). app/src/main/java/com/byd/dashcast/KeyboardBridgeActivity.java Entire onCreate body replaced (~70 LoC → ~50 LoC). All visible chrome stripped, 1×1 px transparent window, invisible focused EditText. Unused imports + dp(int) helper removed. CHANGELOG.md v1.2.11 build 202 entry. Net stats: 5 files changed, 55 insertions, 76 deletions (the chrome removal is bigger than the displayId-routing addition). No new permissions. No new dependencies. No new strings. No new layouts. No protocol bump (still PROTOCOL_VERSION=2). Validation plan (in-car checks) (a) DL5 testeur — invisible bridge Install v1.2.11 over v1.2.10 (no uninstall, versionCode bumped). Start cluster projection, launch Yandex Maps on the cluster. Tap the search field on the cluster (with a11y service enabled) or tap the ⌨ button manually. Expected: NO French overlay at the top, only the IME keyboard at the bottom of display 0. The cluster mirror remains fully visible. (b) DL5 testeur — characters reach the cluster Continuing from (a), type any text on the IME. Expected: every character appears immediately in the Yandex search field on the cluster. Tap IME's Done/Search button. Expected: KEYCODE_ENTER reaches Yandex → search fires. (c) Logcat smoking gun Run adb logcat | grep MirrorDaemon. Type the first character. Expected line: injectKey FIRST OK displayId=2 setDisplayIdAvail=true keyCode=29 action=0 displayId=2 → the cluster display id was applied. setDisplayIdAvail=true → reflection succeeded on this ROM. If setDisplayIdAvail=false → reflection failed, falls back to default routing (cluster won't receive — escalate to alternative routing). (d) DL3 Seal EU regression Install v1.2.11 on DL3 production. Navigate UI. Expected: ⌨ button remains GONE, no log lines from KeyboardBridge, no post-!isDiLink5 log lines from ClusterImeWatcherService. All other features behave identically to v1.2.10. (e) DL2 regression Install v1.2.11 on DL2. Expected: zero impact (no cluster path triggered). Install Direct sideload (BYD file manager → tap APK): DashCast-v1.2.11-debug.apk Or via DashCast's built-in OTA updater once GitHub picks up this release. Branch & tag Branch: beta/1.2.0-dilink5 Commit: ede59ee Tag: v1.2.11 Previous: v1.2.10 (build 201, May 23, 2026 — DL5 IME banner one-click activation + i18n) Next planned: v1.3.0 — full ProxyDaemon migration (see docs/PLAN_v1.3.x_FULL_PROXY.md) LinksAPK download GitHub release page

DashCast v1.2.10DashCast v1.2.10 — build 201 (pre-release) Target branch: beta/1.2.0-dilink5 Platforms affected: DiLink 5 (testeur) — banner visibility / fix is DL5-only. DL3 / DL2 unaffected. Protocol: PROTOCOL_VERSION=2 unchanged APK: DashCast-v1.2.10-debug.apk (14.5 MB, versionCode 201, versionName 1.2.10) Increment versionCode 200 → 201 so the BYD AUTO OTA installer recognises this as an update over v1.2.9 build 200 — no uninstall required. Why this release Field report (May 23, 2026) on DL5 testeur, immediately after the v1.2.9 install, surfaced two issues with the IME accessibility onboarding banner introduced in v1.2.8: The banner was hardcoded in French — non-FR system locales (German, English, Italian, Spanish, etc.) fell back to the French strings. The "Enable" button appeared to do nothing — the user tapped it multiple times, no visible reaction. Both root causes identified and fixed in this build. Root cause #1 — Missing translations The 8 IME-related string keys introduced in v1.2.8 (a11y_ime_watcher_label, _summary, _description, ime_banner_title, _body, _btn_enable, _btn_later, _btn_dismiss, _toast_enabled) only existed in res/values/strings.xml (the default = French). None of the 11 sibling locale folders (values-en, values-de, values-es, values-it, values-ar, values-be, values-kk, values-ru, values-tr, values-uk, values-uz) had these keys, so Android's resource resolver fell back to the default French strings on any non-FR system locale. Fix — 10 strings × 11 locales = 110 new translations Hand-crafted, locale-appropriate translations of every IME banner string for all 11 supported locales: Locale Status values-en/ (English) +10 strings values-de/ (German) +10 strings values-es/ (Spanish) +10 strings values-it/ (Italian) +10 strings values-ru/ (Russian) +10 strings values-uk/ (Ukrainian) +10 strings values-be/ (Belarusian) +10 strings values-tr/ (Turkish) +10 strings values-ar/ (Arabic) +10 strings values-kk/ (Kazakh) +10 strings values-uz/ (Uzbek) +10 strings values/ (FR default) +1 new key (ime_banner_toast_cannot_open_settings) Every translation uses locale-appropriate keyboard / cluster terminology (e.g. "Cluster auto-keyboard" in English, "Cluster-Auto-Tastatur" in German, "Auto-pernetaqta" in Kazakh, etc.). Root cause #2 — "Enable" button silently failing The v1.2.8 button handler fired a single intent: Intent i = new Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS); i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); startActivity(i); // caught Throwable, logged only — no toast, no fallback, no visible feedback On BYD AUTO ROM (heavily customised Android 10 on DL3 and Android 12 on DL5), the standard AOSP Settings.ACTION_ACCESSIBILITY_SETTINGS action is not advertised by BYD's custom Settings.apk. The intent silently failed to resolve, the Throwable was caught, only an AppLogger line was written — and the user saw nothing happen. Tapping multiple times produced no effect because each tap hit the same dead path. Fix — one-click activation via daemon shell + three-tier Settings fallback The "Enable" button now bypasses the Settings UI entirely and uses the proxy daemon's shell (uid=2000, same uid as adb shell) to write directly to Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES via the settings binary. Primary path — enableImeA11yServiceOneClick(): COMP='com.byd.dashcast/com.byd.dashcast.ime.ClusterImeWatcherService' CURRENT=$(settings get secure enabled_accessibility_services 2>/dev/null) if [ "$CURRENT" = "null" ] || [ -z "$CURRENT" ]; then NEW="$COMP" elif echo "$CURRENT" | grep -q "$COMP"; then NEW="$CURRENT" else NEW="$CURRENT:$COMP" fi settings put secure enabled_accessibility_services "$NEW" settings put secure accessibility_enabled 1 echo OUT=$(settings get secure enabled_accessibility_services) The shell is posted through ShellGateway.execShellWithResult which already routes through either the typed proxy daemon or the legacy AdbLocalClient fallback chain. On onSuccess, the OS state is re-read via ClusterImeWatcherService.isEnabled(this) (we trust the OS, not the shell echo). If true: Banner card hidden. Toast: localised ime_banner_toast_enabled (e.g. "Auto-keyboard active ✓" in English, "Auto-Tastatur aktiv ✓" in German). AppLogger info line for forensics. Fallback path — openA11ySettingsFallback(): If the shell route fails (no daemon, no legacy fallback, ROM blocks settings put, or the shell succeeds but the OS still reports the service as disabled — rare SELinux edge case), three intents are tried in sequence, each wrapped in its own Throwable catch: Standard AOSP — Settings.ACTION_ACCESSIBILITY_SETTINGS (works on stock AOSP). Direct ComponentName — com.android.settings/.Settings$AccessibilitySettingsActivity (BYD ROM may not advertise the standard action but still ship the activity). Generic Settings — Settings.ACTION_SETTINGS (last resort — user manually navigates to Accessibility). If all three fail, a localised toast ime_banner_toast_cannot_open_settings is shown ("Cannot open Settings — please enable the accessibility service manually") so the user finally gets visible feedback instead of the silent failure of v1.2.8 / v1.2.9. Button is always re-enabled on every code path so a failure never leaves it stuck disabled (the user can tap again). Behavioural contract DL3 (Seal EU production): banner is never shown (Platform.isDiLink5(this) == false), the new shell helper and fallback chain are never invoked → zero behavioural change. DL5 (testeur): Tap "Enable/Activate/Aktivieren/Attiva/etc." → if proxy daemon is reachable → service is enabled in <500 ms with no Settings trip required → banner disappears → localised toast confirms. If daemon down → falls back transparently to the Settings UI chain → user manually toggles the service. If Settings UI also blocked → localised toast surfaces the failure (no more silent dead button). DL2: completely unaffected (no cluster, banner is DL5-gated). Touched files File Change app/build.gradle versionCode 200 → 201, versionName "1.2.9" → "1.2.10" app/src/main/java/com/byd/dashcast/MainActivity.java Enable click handler now calls one-click helper (~5 LoC). New enableImeA11yServiceOneClick(card, btnEnable) (~70 LoC). New openA11ySettingsFallback() three-tier fallback (~40 LoC). app/src/main/res/values/strings.xml +1 new key ime_banner_toast_cannot_open_settings app/src/main/res/values-en/strings.xml +10 IME banner strings app/src/main/res/values-de/strings.xml +10 IME banner strings app/src/main/res/values-es/strings.xml +10 IME banner strings app/src/main/res/values-it/strings.xml +10 IME banner strings app/src/main/res/values-ru/strings.xml +10 IME banner strings app/src/main/res/values-uk/strings.xml +10 IME banner strings app/src/main/res/values-be/strings.xml +10 IME banner strings app/src/main/res/values-tr/strings.xml +10 IME banner strings app/src/main/res/values-ar/strings.xml +10 IME banner strings app/src/main/res/values-kk/strings.xml +10 IME banner strings app/src/main/res/values-uz/strings.xml +10 IME banner strings CHANGELOG.md v1.2.10 build 201 entry Net stats: 15 files changed, 245 insertions, 10 deletions. No new permissions. No new dependencies. No new layouts. No protocol bump (still PROTOCOL_VERSION=2). Validation plan (suggested in-car checks) (a) DL5 testeur — translation Install v1.2.10 over v1.2.9 (no uninstall required). System Settings → Language → switch to English (or German / Spanish / Italian / etc.). Open DashCast → banner appears at the top. Expected: banner title, body, and buttons are in the selected language (no French fallback). (b) DL5 testeur — one-click activation (primary path) Tap the "Enable" button (or its localised label). Expected within ~500 ms: Localised toast "Auto-keyboard active ✓" appears. Banner disappears. Go to Settings → Accessibility → confirm "Cluster auto-keyboard (DashCast)" is checked. (c) DL5 testeur — end-to-end IME bridge Start cluster projection → launch any cluster app with a text field (e.g. Yandex Maps search). Tap the text field on the cluster. Expected: KeyboardBridgeActivity auto-launches on the head unit ~100 ms later → typing forwards to the cluster. (d) Fallback path If the proxy daemon happens to be unavailable (rare, post-bootstrap), tap "Enable". Expected: Settings → Accessibility opens directly (no error visible to user, transparent fallback). User manually flips the toggle, returns to DashCast → toast confirms + banner disappears. (e) DL3 / DL2 regression check Install v1.2.10 on DL3 Seal EU / DL2. Expected: banner never shown. All other features behave identically to v1.2.9 (the new code path is never invoked). Install Direct sideload (BYD file manager → tap APK): DashCast-v1.2.10-debug.apk Or via DashCast's built-in OTA updater (Settings → Check for updates) once GitHub picks up this release. Branch & tag Branch: beta/1.2.0-dilink5 Commit: 20b8a49 Tag: v1.2.10 Previous: v1.2.9 (build 200, May 23, 2026 — DL3/DL5 Kill race + Stop Projection ghost resurrection fixes) Next planned: v1.3.0 — full ProxyDaemon migration (see docs/PLAN_v1.3.x_FULL_PROXY.md) LinksAPK download GitHub release page

DashCast v1.2.9DashCast v1.2.9 — build 200 (pre-release) Target branch: beta/1.2.0-dilink5 Platforms validated: DiLink 3 (Seal EU production reference), DiLink 5 (testeur — same code path) Protocol: PROTOCOL_VERSION=2 unchanged APK: DashCast-v1.2.9-debug.apk (14.5 MB, versionCode 200, versionName 1.2.9) Increment versionCode 199 → 200 so the BYD AUTO OTA installer recognizes this as an update over v1.2.8 build 199 — no uninstall required. Why this release Field report (May 23, 2026) on DL3 Seal EU surfaced two distinct user-visible symptoms that share the same architectural root cause: BYD AUTO ROM's am force-stop / IActivityManager.forceStopPackage kill the process but do not remove the corresponding TaskRecord from the Recents stack. The existing dumpsys-based cleanup fallback (dumpsys activity recents | grep | sed → am task remove → TaskRemover app_process) silently fails on this ROM (uid 2000 lacks REMOVE_TASKS, am task remove not always available). The same code paths are shared by DL5, so the fixes apply transparently to both platforms. Bug 1 — Long-press "Kill" leaves a ghost Recents tile Symptom: long-press any app currently rendering on the cluster → tap Kill → the process dies (cluster goes blank) BUT the app's tile remains in the head-unit Recents. Tapping it relaunches the activity. Root cause: in MainActivity.doKillApp, two async operations were fired in close succession on different threads: mClusterService.moveTaskToDisplay(pkg, 0, null) — move the cluster-active task back to display 0. AdbLocalClient.forceStopApp(...) — force-stop the package, which internally runs dumpsys activity recents | grep <pkg> | sed → am task remove $taskId to purge the Recents entry. forceStopApp's dumpsys scan could parse the recents stack during the move-to-display-0, see a stale or already-moved TaskId, and am task remove would target the wrong (or no longer existing) task — leaving the real TaskRecord orphaned in Recents. Fix (a) — serialize move → forceStop via LaunchCallback ClusterService.moveTaskToDisplay(pkg, displayId, callback) already exposed LaunchCallback.onResult(boolean) fired on the main thread (added in v1.1.x). doKillApp now: Extracts the forceStopApp callback as a final local killCallback. Wraps the cluster-app branch's moveTaskToDisplay(pkg, 0, ...) call with a LaunchCallback whose onResult fires mSessionClusterPackages.remove + persistSessionClusterPackages + AdbLocalClient.forceStopApp(this, pkg, killCallback). The non-cluster branch (else) is structurally unchanged but routes through the same extracted killCallback. Result: the dumpsys activity recents scan inside forceStopApp is now guaranteed to run after the move-to-display-0 has fully completed, eliminating the race window. Bug 2 — Stop Projection relaunches the cluster app fullscreen on the head unit Symptom: start cluster projection → launch Waze (or any app) on the cluster → tap Stop Projection. The cluster is correctly restored to the BYD dashboard, but ~1 second later Waze pops up fullscreen on display 0, covering the BYD launcher. Root cause: in MainActivity.restoreBydDashboard (TEST 10 path) and originCluster, the call order was: moveSessionAppsToMainDisplay() — iterates mSessionClusterPackages and moves every cluster-launched app (including the currently-active capturedClusterPkg) to display 0 as a foreground task. AdbLocalClient.restoreBydOnCluster(this, capturedClusterPkg, ...) — force-stops capturedClusterPkg, then fires sendInfo(18) + sendInfo(0) to restore the Qt cluster surface. Step 1 brings the active cluster app to display 0 as a foreground task. Step 2 force-stops it — kills the process, but the TaskRecord on display 0 survives (Bug 1 root cause applies here too). Then sendInfo(18)+sendInfo(0) triggers the Qt cluster surface restoration, which appears to fire a RESUME_TOP_ACTIVITY ripple effect on display 0 that picks up the orphan TaskRecord and resurrects the activity. Fix (b) — invert order: remove capturedClusterPkg from session set BEFORE moveSessionAppsToMainDisplay() Both restoreBydDashboard and originCluster now do: if (capturedClusterPkg != null) { mSessionClusterPackages.remove(capturedClusterPkg); persistSessionClusterPackages(); } moveSessionAppsToMainDisplay(); AdbLocalClient.restoreBydOnCluster(this, capturedClusterPkg, ...); Now moveSessionAppsToMainDisplay() iterates a set that no longer contains the active cluster pkg — it stays on display 1 (cluster). restoreBydOnCluster (unchanged) then force-stops it in place on display 1 just before sendInfo(18). No orphan TaskRecord ever lands on display 0, no resurrection path. Other session apps (split-mode side dashboards) are still moved to display 0 as before. Fix (c) — verifyForceStop active escalation (defense in depth) v1.2.8's AdbLocalClient.verifyForceStop only logged a WARN when BetaProxyClient.getPidsByPackage(pkg) reported surviving PIDs after the typed IActivityManager.forceStopPackage returned OK. Build 200 actively escalates: surviving PIDs → BetaProxyClient.runShell("kill -9 <pid1 pid2 ...>") via the daemon (uid 2000 owns the same uid as the target app, so the kill is permitted) → sleep 200 ms → re-query PIDs → log the final state. The whole escalation is wrapped in an inner try/catch so a daemon glitch can never break the teardown sequence. This also benefits restoreBydOnCluster / restoreOriginCluster (typed paths call verifyForceStop) — if the cluster pkg somehow survives the in-place force-stop in Fix (b), the kill -9 escalation finishes the job before sendInfo(18) fires. Known limit (roadmap) This v1.2.9 patch fixes the process-survival and race-window sides of both bugs, but it does not purge the TaskRecord itself from Recents — architectural limitation of the dumpsys + shell pipeline on BYD AUTO ROM. Practical impact: Bug 1 (Kill): the ghost Recents tile may still appear briefly on DL3. Tapping it now relaunches a fresh instance instead of resurrecting state on display 1, but the visual tile may linger. Bug 2 (Stop Projection): fully resolved by Fix (b). No Waze flash on the head unit. Robust fix scheduled for v1.3.x A new typed verb TXN_REMOVE_TASKS_BY_PACKAGE will be added to the proxy daemon: Uses IActivityTaskManager.getRecentTasks() + removeTask(taskId) from the stable uid 2000 daemon context. Atomic, no shell parse, no race. Will be called from AdbLocalClient.forceStopApp (replacing the current dumpsys + sed + am task remove + TaskRemover block) and from restoreBydOnCluster / restoreOriginCluster. Requires PROTOCOL_VERSION bump 2 → 3 (first real bump since v1.1.6). Full specification in docs/PLAN_v1.3.x_FULL_PROXY.md §7.b (this repo, this branch). Touched files File Change app/build.gradle versionCode 199 → 200, versionName "1.2.8" → "1.2.9" app/src/main/java/com/byd/dashcast/MainActivity.java doKillApp serialize move → kill via LaunchCallback (~50 LoC); restoreBydDashboard + originCluster pre-remove captured pkg from session set (~14 LoC total) app/src/main/java/com/byd/dashcast/AdbLocalClient.java verifyForceStop active kill -9 escalation (~40 LoC) docs/PLAN_v1.3.x_FULL_PROXY.md NEW §7.b documenting the typed-verb robust fix for v1.3.x CHANGELOG.md v1.2.9 build 200 entry Net stats: 5 files changed, 454 insertions, 14 deletions. No new permissions. No new dependencies. No new strings. No protocol bump (still PROTOCOL_VERSION=2). Behavioural contract DL3 (Seal EU production): zero behaviour change outside the targeted fixes. The wm overscan -d 1 cluster routing, all typed verbs, all sendInfo Parcel layouts — all bit-for-bit identical to v1.2.8. DL5 (testeur): same — shared MainActivity / AdbLocalClient code paths. The DL5-specific IME bridge / display-0 hard guards / displayId override (from v1.2.6 — v1.2.8) are untouched. DL2: completely unaffected. No cluster path → only verifyForceStop escalation could trigger there, but DL2 doesn't ship the typed verbs that gate this code path. Validation plan (suggested in-car checks) (a) DL3 Seal EU — Bug 1 Install v1.2.9 (over v1.2.8 — should NOT prompt for uninstall). Start cluster projection → launch Waze on cluster. Long-press the Waze tile in DashCast → tap Kill. Expected: Waze process dies, cluster goes blank. Open Recents on the head unit. The Waze tile may still appear (known TaskRecord limitation — see roadmap). Tap it. Expected: Waze relaunches fresh (no prior state from display 1) — proves the move-then-kill race is gone. (b) DL3 Seal EU — Bug 2 Start cluster projection → launch Waze on cluster. Tap Stop Projection. Expected: cluster restored to BYD dashboard AND NO Waze flash on the head unit (previously: Waze popped fullscreen ~1 s after restore). Logcat tag MainActivity should show mSessionClusterPackages remove com.waze before any moveSessionAppsToMainDisplay line. (c) DL5 testeur Same two scenarios as (a) and (b), same expected results (shared code path). (d) DL2 Install, navigate UI, no cluster path triggered, zero behaviour change. (e) Logcat hygiene Search for verifyForceStop ... escalating kill -9 in logcat. Should only appear when the typed forceStopPackage left a surviving PID (rare on a healthy device) — confirms the escalation is dormant in nominal operation. Install Direct sideload (BYD file manager → tap APK): DashCast-v1.2.9-debug.apk Or via DashCast's built-in OTA updater (Settings → Check for updates) once GitHub picks up this release. Branch & tag Branch: beta/1.2.0-dilink5 Commit: e7f1a90 Tag: v1.2.9 Previous: v1.2.8 (build 199, May 22, 2026) Next planned: v1.3.0 — full ProxyDaemon migration (see docs/PLAN_v1.3.x_FULL_PROXY.md) LinksAPK download GitHub release page

DashCast v1.2.8DashCast v1.2.8 (build 199) — Pre-release Branch: beta/1.2.0-dilink5 Target: DiLink 5 testers (no impact on DiLink 3 production users) Built from: commit 7e94519 Overview Four coordinated DL5 payloads built on top of the v1.2.7 tactile fix, all gated behind Platform.isDiLink5(Context) so the DL3 production hot path is bit-for-bit identical to v1.2.7. (A) Keyboard bridge — manual ⌨ button + KeyboardBridgeActivity Problem. Field report (22/05/2026, post-v1.2.7): touch injection on the DL5 cluster mirror now works (Yandex maps reacts to taps), BUT tapping an EditText inside Yandex does NOT pop up the system IME on the head unit. Root cause. WindowManager per-display IME isolation routes the focused-window IME request to display 3 (the 1×1 shared_fission_bg_XDJAScreenProjection shadow framebuffer) where the IME has nowhere to render. No clean override exists on API 32 without MANAGE_DEVICE_POLICY_LOCAL_OVERRIDE (System API, unavailable on BYD-AUTO ROM). Workaround. A new translucent landscape KeyboardBridgeActivity is launched on display 0 (head unit) with a hidden EditText that triggers the native IME on tap. A TextWatcher computes the per-character diff and forwards each typed character to the cluster via ClusterInputForwarder.injectKeyEvent(KeyEvent), which already routes through the existing TRANSACT_INJECT_KEY daemon transaction (uid 2000, holds INJECT_EVENTS). KeyCharacterMap.load(VIRTUAL_KEYBOARD).getEvents(char[]) converts each character into a meta-state-aware KeyEvent[] (handles SHIFT for capitals, ALT for symbols). Fallback mapAsciiToKeyCode for degenerate ASCII when KCM lookup fails. Backspace is translated to N×KEYCODE_DEL based on before count from TextWatcher. EditText is reset after 80 characters to prevent unbounded growth. A new ⌨ button (btn_keyboard_bridge, 36 dp, tertiary-container colours) is inserted in the toolbar after the Split-screen button, visibility-gated to DL5 only (DL3 → GONE). (B) Auto-popup via ClusterImeWatcherService (AccessibilityService) Manual ⌨ taps work, but the UX target is automatic pop-up on EditText focus. Android does not expose an in-process focus listener for foreign apps' windows, so the only supported path is an AccessibilityService. New service com.byd.dashcast.ime.ClusterImeWatcherService listens for TYPE_VIEW_FOCUSED | TYPE_WINDOW_STATE_CHANGED events (feedbackGeneric, notificationTimeout=100, canRetrieveWindowContent=true). Five-guard filter chain — each event must pass ALL of these to trigger: Platform.isDiLink5(this) — DL3 strictly never triggers (refreshed every event). eventType == TYPE_VIEW_FOCUSED. ClusterService.sIsRunning — hard gate: only react while the DashCast cluster projection is actually live. If DashCast is closed, the service is registered with the system but does nothing. event.getDisplayId() > 0 — strictly secondary displays only, blocks display 0 and the unknown-id (-1) case on pre-API-30 fallbacks. node.editable && pkg != getPackageName() — no self-trigger on the bridge's own EditText. Additional safety: 600 ms debounce via mLastLaunchAt. KeyboardBridgeActivity.isShowing() static check (set in onStart/onStop/onDestroy) to skip launch when the bridge is already visible. Every callback wrapped in try { … } catch (Throwable t) { AppLogger.e(…); } — the service never crashes the host app. The launch sends an intent with EXTRA_AUTO_OPENED=true so the bridge can distinguish manual vs. auto invocations. (C) On-boarding banner for the AccessibilityService Android requires the user to enable an AccessibilityService manually in Settings (no programmatic enable possible by design). A new MaterialCardView card_ime_a11y_banner (tertiary-container, corner 12 dp) is inserted in MainActivity after the top bar. It shows on first launch when all three are true: Platform.isDiLink5(this) The service is not yet in Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES (parsed colon-separated, comparing both flattenToString and flattenToShortString). The user has not dismissed it (PREF_IME_BANNER_DISMISSED). Three actions: Enable → deep-links to Settings.ACTION_ACCESSIBILITY_SETTINGS. Toast Clavier automatique actif ✓ shown on return to MainActivity if the service is then enabled. Later → session-hide only, banner reappears next launch. Dismiss → persists PREF_IME_BANNER_DISMISSED=true, banner never shown again unless prefs are cleared. Fully no-op on DL3 (never shown). (D) DL5 resize sliders — dynamic cluster routing Problem. The per-app resize panel (btn_toggle_resize → SeekBars W/H → Apply) was a no-op on DL5. Two hard-coded bugs: MainActivity.btnResizeApply and autoApplyInsetsIfNeeded both issued wm overscan W,H,W,H -d 1 (cluster id on DL3 only — on DL5 the cluster lives on display 3 or 4, so the command silently failed). ClusterService.resizeActiveTask hard-coded the freeform Rect to 1920 - insetH, 720 - insetV (DL3 cluster size). Fix: Both MainActivity call sites now resolve the cluster display id dynamically via ClusterService.getDisplayId() → DashboardDisplayHelper.getKnownClusterDisplayId() — the same source already used by every other cluster-routed code path. Skip the wm overscan call entirely when clusterId <= 0 (no cluster connected — never silently retarget to display 0). ClusterService.resizeActiveTask and the inline post-moveTaskToDisplay resize block now compute bounds from mInputForwarder.getClusterWidth()/getClusterHeight() (set live from Display.getSize() in setClusterDisplay), with explicit fallback to 1920×720 if either getter returns 0. DL3 behaviour stays bit-for-bit identical (DL3 cluster IS 1920×720; fallback path matches the old hard-coded values). On DL5 the bounds now reflect actual cluster dimensions reported by the system. (E) Head-unit display-0 hard guards (defense in depth) Concern. Even with the per-call-site clusterId > 0 checks in (D), a regressed caller could still ship a wm overscan|size|density … -d 0 to the head-unit display 0 and shrink the main UI (the v1.2.5 DL2 incident playbook). Three independent layers: (E1) ShellGateway.WM_DISPLAY_ZERO — new regex ^\s*wm\s+(?:overscan|size|density)\b.*\s-d\s+0\b.*$ blocks any wm verb explicitly targeting display 0. Checked at the top of execShellWithResult before both the proxy-ON typed-verb path AND the legacy AdbLocalClient fallback — neither can reach the system. Blocked commands emit AppLogger.e("BLOCKED wm verb on display 0 (head unit): …") and the caller's Callback.onError("blocked: wm command targets display 0 (head unit)"). (E2) New abort in ClusterService.resizeActiveTask: if mDisplayHelper.getKnownClusterDisplayId() <= 0 at call time, log and return without invoking IActivityTaskManager.resizeTask. Without this, a stale taskId that happens to live on display 0 (because a prior cluster-move failed silently) would have applied DL3 freeform bounds to the head-unit task. (E3) The two MainActivity clusterId > 0 guards from (D) form the outermost UI-level layer. Coverage matrix: to reach display 0 a caller would have to simultaneously bypass the UI guard, the cluster-connected guard in resizeActiveTask, AND the regex at the shell gateway — three independent layers, no single point of failure. Behavioural contract Platform Result DL3 production (BYD Seal EU) ⌨ button GONE, banner hidden, AccessibilityService inert (!isDiLink5 short-circuit), resize sliders identical to v1.2.7 (cluster id resolves to 1, bounds 1920×720, command -d 1), display-0 guards never fire. DL5 testeur (BYD-AUTO) ⌨ button visible, bridge forwards keystrokes to cluster apps. With AccessibilityService enabled, EditText focus on cluster auto-launches bridge in ~100 ms. Resize sliders actually work. Display-0 protections active. DL2 Unaffected — no cluster surface ever runs on DL2; AccessibilityService stays inert if accidentally enabled. v1.2.5 DL2 hard-ban still in place + new WM_DISPLAY_ZERO regex adds another layer. Touched files NEW: KeyboardBridgeActivity.java, ime/ClusterImeWatcherService.java, res/xml/accessibility_ime_watcher.xml MODIFIED: AndroidManifest.xml, MainActivity.java, ClusterService.java, dashboard/ClusterInputForwarder.java, beta/ShellGateway.java, res/layout/activity_main.xml, res/values/strings.xml, app/build.gradle No new permissions. No protocol bump (PROTOCOL_VERSION=2 unchanged). All daemon traffic reuses existing TRANSACT_INJECT_KEY=3. Validation plan DL5 testeur Install, start cluster projection, open Yandex on cluster. Tap ⌨ button → bridge appears on head unit, typing forwards to Yandex search bar. Enable AccessibilityService in Settings (Accessibility → DashCast Cluster IME Watcher). Tap Yandex search bar on cluster → bridge auto-launches within ~100 ms. Open Adjust panel, slide W/H, press Apply → Yandex window on cluster recomputes bounds. Head unit unaffected (visual proof display 0 is untouched). Banner appears on first launch. Enable → return to app → expect Toast Clavier automatique actif ✓. DL3 Seal EU (regression check) Install. Confirm ⌨ button is NOT visible in toolbar, banner is NOT shown. Resize sliders behave exactly as v1.2.7. Logcat tag ClusterImeWatcherService never logs anything past !isDiLink5 → return. DL2 (regression check) Install. Everything works exactly as v1.2.7. Install Download DashCast-v1.2.8-debug.apk below and install via: adb install -r DashCast-v1.2.8-debug.apk Or via OTA: the device's existing DashCast install will see versionCode 199 > 196 and offer the update. LinksAPK download GitHub release page

@TangTang You need to replace the built-in esim with a physical sim slot. But now there is a problem with connecting Chinese machines outside of China. A week ago, BYD updated their servers and the Chinese cars stopped connecting to the servers if cars are located outside of China. You can connect to the Telegram channel https://t.me/byd_ota They are currently trying to solve this problem

@TangTang The global firmware is not compatible with the Chinese one, do not try to install it, you will get a brick.

DashCast v1.2.7DashCast v1.2.7 — Pre-release (versionCode 196) DL5 tactile fix follow-up to v1.2.6. v1.2.6 made the cluster mirror visible on DL5 (layerStack 3→2 override let us capture the composed fission output instead of the 1×1 shadow framebuffer). v1.2.7 attempts to make the cluster mirror touchable on DL5, symmetric to the layerStack work, and instruments the daemon's input injection path so the next M7 capture reports exactly where the touch chain breaks if this fix isn't sufficient. Field test evidence (22/05/2026, v1.2.6 on DL5 testeur) ✅ Preview shows actual cluster composite content (Yandex visible in TextureView in real time). ❌ Touch does NOT reach Yandex in preview OR in fullscreen mirror. Log: ClusterInputForwarder Cluster dimensions: 1920x720 displayId=3, Daemon Binder connected — touch/key injection via uid=2000, daemon holds INJECT_EVENTS, no injectMotion failed warning in logcat, no touch → debug line (filtered from the field report). Yandex's window on WMS: mDisplayId=3 rootTaskId=79 Session{… 7775:u0a10124} → daemon was correctly targeting setDisplayId(3). BUT: WMS also exposes a separate mDisplayId=2 (visible in mWindowsForAccessibilityObserver={…, 2=…, 3=…, 4=…}) backing the fission_bg_XDJAScreenProjection 1920×720 composite — that's where the user actually sees the apps. Hypothesis: on DL5 the InputDispatcher either clips events injected on displayId=3 against its degenerate 1×1 framebufferSpace, refuses to route into PRESENTATION displays with such dims, or the WMS-side Yandex window on displayId=3 isn't actually input-eligible because it's composited away by containerservice into displayId=2's surface. Changes ClusterMirrorManager.applyDl5DisplayIdOverride(Context, int) — sibling helper to v1.2.6's applyDl5LayerStackOverride. Same shape, same DL3-safe contract: Platform.get().isDiLink5(ctx) wrapped in try/catch (any failure returns input unchanged), DL3 returns input unchanged, DL5 rewrites 3 and 4 to 2 with explicit AppLogger.i DL5 override: displayId N → 2 (touch injection on composed cluster face) log line. Wired in startMirrorViaDaemon right before data.writeInt(clusterDisplayId) — the value of sClusterDisplayId stored statically inside MirrorDaemon (and used by injectMotion for MotionEvent.setDisplayId) now becomes 2 on DL5 instead of 3. MirrorDaemon.injectMotion/injectKey — first-event + failure instrumentation via out(). v1.2.6 made setupMirror trace appear in /data/local/tmp/mirrordaemon_latest.log (the file M7 reads) but the injection paths still only logged failures to logcat. New volatile boolean sMotionFirstLogged/sKeyFirstLogged flags (reset in setupMirror so each session re-arms once) make the very first successful injection emit out("injectMotion FIRST OK displayId=N setDisplayIdAvail=true|false action=K x=X y=Y ret=R") to the file log; any subsequent exception emits out("injectMotion EXCEPTION displayId=N action=K err=ClassName: message"). Pre-check path (ev==null || sInputManager==null) also emits a one-shot diagnostic. Same instrumentation pattern for injectKey. Next M7 capture on DL5 will tell us: did the override take effect (displayId=2 in the FIRST OK line), did setDisplayId reflection survive (setDisplayIdAvail=true), did InputManager accept the event (no EXCEPTION line). Behavioural contract DL3 production (BYD Seal EU) — bit-for-bit identical: applyDl5DisplayIdOverride returns input unchanged on isDiLink5=false so clusterDisplayId written to the daemon's MIRROR_START parcel stays exactly what Display.getDisplayId() returned on DL3. Daemon out() additions are pure log writes; the Log.w calls are preserved. No public API change, no protocol bump (PROTOCOL_VERSION="2"). DL5 testeur — daemon's setDisplayId target shifts from 3 to 2 for touch injection. Mirror visual stays exactly as v1.2.6 (layerStack capture from 2 unchanged). M7 detail now contains the actual displayId/setDisplayIdAvail/ret triplet of the first injected event so we can triage further if Yandex still doesn't respond. DL2 testeur — completely unaffected (no cluster code path triggered). Validation plan DL5 in-car — install, activate cluster, launch Yandex/Maps on cluster, then tap on the in-app preview surface (or enter fullscreen via 📺 and tap there): expected — Yandex now responds to touch (map pans, buttons react). Logcat tag ClusterMirrorManager should contain DL5 override: displayId 3 → 2 exactly once per mirror session, and startMirrorViaDaemon ✓ layerStack=2 1920×720 displayId=2 (note displayId=2 instead of =3 like v1.2.6). If still not working — open Diag → Mirror → Lancer tous, M7 detail will show the first injectMotion FIRST OK displayId=2 setDisplayIdAvail=true action=0 x=… y=… ret=… line: ret=false → InputManager refused (likely needs displayId=0 + global routing, or WMS input monitor). setDisplayIdAvail=false → reflection failed on this ROM, the event went to displayId=0 by default → DashCast self-consumed it (explains v1.2.6 silent failure). No injectMotion FIRST OK line at all → the OnTouchListener never fired (layout/event consumption issue), pivot to View-tree debug. DL3 Seal EU — install, activate cluster, run any cluster app, confirm fullscreen mirror tactile still works exactly as before. Logcat should NOT contain any DL5 override: displayId line. DL2 — install, navigate UI, no cluster path triggered, zero behaviour change. Touched files app/build.gradle (versionCode 195 → 196, versionName 1.2.6 → 1.2.7) dashboard/ClusterMirrorManager.java (+22 LoC, +applyDl5DisplayIdOverride helper, +1 call site) daemon/MirrorDaemon.java (+30 LoC, +2 volatile flags, reset in setupMirror, instrumented injectMotion/injectKey) CHANGELOG.md No new permissions, no new dependencies, no new layouts, no new strings. Branch: beta/1.2.0-dilink5 (not merged to main) APK: DashCast-v1.2.7-debug.apk (14 MB) Detected as update from: v1.2.6 (versionCode 195) and earlier. LinksAPK download GitHub release page

DashCast v1.2.6DashCast v1.2.6 — Pre-release (versionCode 195) Two coordinated payloads bundled into a single OTA: a zero-behaviour proxy daemon performance pass (P1–P4) and a focused DL5 mirror investigation gated on Platform.isDiLink5 (DL3 strictly untouched). (A) Beta Engine proxy daemon — 4 perf passes (P1–P4) Lockless hot paths in the typed-verb dispatcher. Zero protocol bump (PROTOCOL_VERSION = "2"), zero public API change, zero behaviour change on DL3 reference (BYD Seal EU) or DL5 testeur. P1 — Lock-free hot-path verbs in BetaProxyClient. sBinder promoted to volatile; synchronized (LOCK) removed from setOverscan, getPidsByPackage, autoContainerSendInfo, forceStopPackage, runShell, runPhase4Probes, ping. sDaemonUid / sDaemonPid / sDaemonVer now volatile so the public getters are lockless too. connect(), the receiver and handshake() still take LOCK for publication — the only place strictly needed. Resize SeekBar (~30 setOverscan/s while dragging) and reconcile loop (getPidsByPackage every ~5 s) now dispatch in parallel through the daemon's binder pool instead of queuing behind any in-flight runShell. P2 — DeathRecipient hooked on the live binder. isConnected() now uses the cheap local isBinderAlive() flag instead of issuing a full pingBinder() IPC roundtrip on every typed verb. Per-verb latency roughly halves (~10 ms → ~5 ms). Receiver unhooks the previous death recipient before swapping a fresh binder; linkToDeath is best-effort caught for the vanishing race between stale-broadcast check and link. P3 — ThreadLocal<byte[]> scratch in Phase4Verbs.getPidsByPackage. Was allocating a fresh byte[256] per /proc/<pid>/cmdline scan iteration (~241 allocations per reconcile tick). The daemon's binder thread pool reuses threads → one buffer per thread for the daemon's lifetime, zero allocation, zero GC pressure. Loop body and matching semantics byte-for-byte unchanged. P4 — ByteArrayOutputStream in ProxyDaemonMain.runShell. Replaces the per-line BufferedReader.readLine() + StringBuilder pattern. Reads the full child stream in 4 KiB chunks into a single ByteArrayOutputStream, decodes once with toString("UTF-8"), strips trailing \r/\n to exactly reproduce the legacy line-joiner semantics. ~1000 transient allocations saved on a 300-line dumpsys SurfaceFlinger. Wire protocol: unchanged. An app-update that lands while a daemon from build 192–194 is still alive transparently talks to the old daemon until the next bootstrap kills it. No incompatibility possible. (B) DL5 mirror investigation — 3 surgical fixes First DL5 in-car test of the build 192–194 mirror path confirmed end-to-end routing works (Yandex on cluster mDisplayId=3 rootTaskId=50, daemon-side startMirrorViaDaemon ✓ layerStack=3 1920×720 displayId=3) but the in-app preview surface stays black. Root cause traced to the DL5 fission architecture: apps render on shared_fission_bg_XDJAScreenProjection_0/1 (layerStack=3/4, framebufferSpace bounds 1×1 — degenerate shadow displays), then com.byd.containerservice re-composes the selected slot into fission_bg_XDJAScreenProjection (layerStack=2, framebufferSpace bounds 1920×720 — the actual surface piped to the physical cluster panel). Mirroring layerStack=3 captures a 1×1 black buffer. B1 — DL5 layerStack override 3→2 (and 4→2) in ClusterMirrorManager. New private helper applyDl5LayerStackOverride(Context ctx, int detected) wraps Platform.get().isDiLink5(ctx) in a try/catch (any reflection failure returns input unchanged → DL3 path bit-for-bit identical). On confirmed DL5, layerStack 3 or 4 is rewritten to 2 with an explicit log line; any other value is passed through untouched. Applied inside both startMirror (app-uid direct SurfaceControl path) and startMirrorViaDaemon (daemon-uid path). Both signatures gained a leading Context parameter; sole caller MainActivity.attemptStartMirror updated. B2 — Daemon-side mirror setup logging (MirrorDaemon.setupMirror). All pre-195 mirror traces in the daemon went through Log.i (logcat-only). The on-device M7 diagnostic test reads /data/local/tmp/mirrordaemon_latest.log which only captures out() lines, so the file showed only the startup banner. Build 195 mirrors the critical-path traces to out(): setupMirror BEGIN, setupMirror createDisplay OK token=… (or FAIL createDisplay returned null), setupMirror SF dump (layerStack=N): … (or empty — token NOT in SurfaceFlinger!), setupMirror DONE ok=true, and setupMirror EXCEPTION: ClassName: message on any failure. Next M7 capture will show the full daemon chain. B3 — M10 LIVE probe fixes (MirrorTestRunner.runM10). Build 194 M10 had two known-bad hard-codings: STEP 2 / STEP 7 issued service call AutoContainer 2 … (PascalCase) but the DL5 cluster service is registered as auto_container (snake_case, confirmed by production ClusterManager), and STEP 4/5 launched com.android.settings/.Settings which BYD doesn't ship under that exact AOSP name. Build 195 replaces AutoContainer → auto_container (3×) and com.android.settings/.Settings → com.android.launcher3/.Launcher (2×). Test stays ALWAYS PASS (manual analysis of STEP 3 framebufferSpace diff and STEP 6 routing), but next run produces real sendInfo Parcel(...) output and real am start Status/TotalTime instead of two-bugs-cancelling-out. Behavioural contract DL3 production (BYD Seal EU) — bit-for-bit identical sequence of binder transactions and shell outputs as build 194. The DL5 layerStack override short-circuits via Platform.isDiLink5=false. The daemon out() additions are pure log writes. M10's diag-only changes don't touch any runtime path. DL5 testeur (BYD-AUTO) — proxy daemon perf wins apply identically. Mirror should now capture the composed 1920×720 fission output instead of the 1×1 shadow. If still black, M7 will provide the full daemon setup chain in the file log (createDisplay token state, SF dump result, projection params) — enough evidence to triage further. DL2 testeur — completely unaffected (Beta Engine disabled by default, no cluster display so mirror code path never runs). Validation plan DL5 in-car — install, activate cluster, launch Yandex/Maps on cluster, observe in-app preview during active mirror (don't open Diag first). Expected: preview now shows the actual cluster content. If still black: Diag → Mirror → Lancer tous → M7 contains the full daemon setup chain → paste in issue. DL5 in-car — re-run M10: STEP 2 should show successful Parcel(00000000 00000001) from auto_container, STEP 4/5 should show Starting: Intent { ... cmp=com.android.launcher3/.Launcher } with a real Status/TotalTime, STEP 6 still shows rootTaskId=N mSession=... now correlated with launcher3. DL3 Seal EU — install, activate cluster, launch Yandex/Waze: zero behaviour change vs build 194. Logcat tag ClusterMirrorManager should NOT contain any DL5 override line. Resize SeekBar smoothness (any platform) — open Settings → Marges, drag the slider 0 → 80 → 0: expect noticeably smoother behaviour vs build 194 (P1+P2 → ~2× faster per-tick, ~3–5 ms instead of 8–12 ms). Touched files app/build.gradle (versionCode 194 → 195, versionName 1.2.5 → 1.2.6) beta/BetaProxyClient.java (~45 LoC, no public API change) beta/proxy/Phase4Verbs.java (+6 LoC) beta/proxy/ProxyDaemonMain.java (~20 LoC) dashboard/ClusterMirrorManager.java (~30 LoC, +Context param + DL5 helper) daemon/MirrorDaemon.java (~12 LoC, out() mirrors) mirror/MirrorTestRunner.java (~10 LoC, M10 fix) MainActivity.java (+2 args in attemptStartMirror mirror startup) CHANGELOG.md No new permissions, no new dependencies, no new layouts, no new strings. Branch: beta/1.2.0-dilink5 (not merged to main) APK: DashCast-v1.2.6-debug.apk (14 MB) Detected as update from: v1.2.5 (versionCode 194) and earlier. LinksAPK download GitHub release page

DashCast v1.2.5DashCast v1.2.5 — build 194 Branch: beta/1.2.0-dilink5 · Pre-release · Not merged to main Summary New M10 — Cluster routing LIVE diagnostic test in the Diag → Mirror tab. End-to-end probe that fires sendInfo(1000, 16) on the BYD AutoContainer service, snapshots the SurfaceFlinger framebufferSpace of every XDJA-fission display before and after the call, then attempts to route com.android.settings/.Settings via am start-activity --display 3 and --display 4, dumps the resulting WindowManager root-task topology, and cleans up. All seven step outputs are concatenated into the test detail and shipped via Telegram with the existing Envoyer (.log) button. What problem does M10 solve? Build 192 (D28) visually confirmed that sendInfo(1000, 16) opens a black projection window on the cluster. Build 193 added the read-only Mirror diag suite (M1-M9) that gives full SurfaceFlinger and WindowManager snapshots. But no single field run has captured the BEFORE/AFTER framebufferSpace transition AND the activity-routing outcome together — so we still cannot say with certainty: Which of the inactive 1×1 fission slots (display 3 or 4) becomes the active 1920×720 cluster framebuffer after sendInfo(16). Whether an activity launched with am start --display N actually lands on that display (and not silently re-routed to display 0 by the XDJA fission compositor like the DL5 ROM is known to do in some cases). M10 closes that gap in one shot. Test steps (all captured in one detail blob) Step What it does STEP 1 dumpsys SurfaceFlinger | grep -E 'DisplayDevice\{|framebufferSpace=ProjectionSpace|layerStack=[0-9]' — BEFORE state of fission/XDJA displays STEP 2 service call AutoContainer 2 i32 1000 i32 16 s16 "" — opens cluster projection STEP 3 Same grep as STEP 1, 2 s after STEP 2 — AFTER state. The display whose framebufferSpace flips from Rect(0, 0, 1, 1) to Rect(0, 0, 1920, 720) is the cluster target. STEP 4 am start-activity -W --display 3 -n com.android.settings/.Settings — captures synchronous -W result (Status / TotalTime) STEP 5 Same on --display 4 STEP 6 dumpsys window | grep -E 'Display: mDisplayId=|mCurrentFocus=|mFocusedApp=|rootTaskId=' — which display actually hosts the Settings root task STEP 7 Cleanup: am force-stop com.android.settings + sendInfo 18 (close projection) + sendInfo 0 (restore Qt native video stream) Why the ADB-local shell (not direct Binder) DL5 systematically returns SIGNATURE_NO_MATCH when the app uid calls ServiceManager.getService("autocontainer") — the BYD AutoContainer service is signature-protected against third-party packages. The ADB-local relay (uid 2000 / shell) is the only Binder path that works from a non-system APK, so M10 routes the service call through AdbLocalClient.executeShellWithResult exactly like the rest of the suite. Status semantics M10 always reports PASS — the analysis is intentionally manual. A hard PASS/FAIL would have required hard-coding an expected display id, but the whole point of M10 is to discover that id. The result message reads: live routing run complete — compare STEP 1 vs STEP 3, then STEP 6 The operator analyzes the raw text in the shipped report. Side-effect contract Two non-trivial side-effects, both pre-validated as user-safe: sendInfo 16 opens a black projection window on the cluster for ~6 seconds (visually confirmed harmless in build 192 D28). Settings briefly launches on display 3 or 4 (or fails to, depending on the ROM) and is force-stopped. STEP 7 always runs even if STEPS 4 / 5 fail, so the cluster is always returned to its baseline state regardless of intermediate failures. Files changed File Change app/build.gradle versionCode 193 → 194, versionName 1.2.4 → 1.2.5 mirror/MirrorTestRunner.java +1 catalog entry, +1 dispatcher case, +runM10 (~85 LoC), +1 reused fbGrep constant CHANGELOG.md New 1.2.5-build194 entry at the top of the pre-releases table No new permissions, no new dependencies, no new layouts, no new strings, no new drawables. M10 reuses the existing runShellSync helper, the AdbLocalClient.executeShellWithResult infrastructure, and the existing include_diag_mirror.xml row layout (Mirror rows are generated dynamically from MirrorTestRunner.catalog() in DiagActivity.prepareMirrorTestRows, so no XML edit was needed). DL3 / DL2 behaviour The Mirror tab and M10 still run, but STEP 2 will likely return Service AutoContainer does not exist on DL3 (no XDJA fission compositor) or hit the DL2 single-display ROM (no cluster at all). The test still PASSES with the empty-output evidence, which is itself useful — it proves AutoContainer is DL5-only and confirms the auto-detection scope. Validation plan Install the OTA on a DL5 device. Open DashCast → Diag → swipe to the Mirror tab → tap Lancer tous. Wait ~25 s for M10 (longest test in the suite due to the 2 s + 1 s + 1 s settle waits). Tap Envoyer (.log) → Telegram. In the report look for [PASS] M10 then under --- detail --- read STEP 1 vs STEP 3: exactly one of fission_bg_XDJAScreenProjection_0/1/2 should have flipped from framebufferSpace=ProjectionSpace(start=Rect(0, 0, 1, 1) to =Rect(0, 0, 1920, 720). That display's layerStack= value is the cluster compositor's target layerStack. Then STEP 6 should show rootTaskId=... for a mDisplayId=3 or mDisplayId=4 entry hosting com.android.settings/.Settings — confirming the activity-routing side of the pipeline. Asset DashCast-v1.2.5-debug.apk — 14 MB, signed debug, ready for OTA install via the in-app updater. LinksAPK download GitHub release page

DashCast v1.2.4DashCast 1.2.4 (build 193) — Diag: dedicated Mirror tab + Telegram log export Pre-release • branch beta/1.2.0-dilink5 • versionCode 193 / versionName 1.2.4 TL;DR A brand-new Mirror tab has been added to the Diag screen, dedicated to investigating the DiLink 5 cluster mirror black-screen issue reported in build 192. It runs a 9-test read-only suite that captures the ground-truth SurfaceFlinger topology and the MirrorDaemon log directly on-device, saves the heavy artifacts under Download/dl5_mirror_diag/ (browsable from the BYD file manager), and ships everything via a one-tap Envoyer (.log) button that opens the standard Android share chooser — pick Telegram and the report is sent. Zero changes to the mirror code path. MirrorDaemon, ClusterMirrorManager, ClusterService and every touch/launch code path are bit-for-bit identical to build 192. DL3 mirror behaves exactly as before. DL5 mirror behaves exactly as before. This build is purely a diagnostic surface. Why this build exists Field log on a DL5 device (BYD-AUTO Android 12, cluster display shared_fission_bg_XDJAScreenProjection_0 1920×720 @ 320dpi) showed the cluster-mirror path completing successfully on the daemon side: startMirrorViaDaemon ✓ layerStack=3 1920×720 displayId=3 …but the cluster screen stayed black. Hypothesis: apps physically launched on display #3 are rendered by the XDJA fission compositor, not by SurfaceFlinger. SurfaceControl.setDisplayLayerStack(token, 3) therefore mirrors an empty SF layerStack. To confirm this without touching the production mirror code, we need the real SF topology and the daemon's own post-setup SF dump — captured by this build. What's new 1. New Mirror tab in Diag (position 8) DiagActivity grows from 9 to 10 tabs. TAB_MIRROR = 8 is inserted between DiLink 2 and Sniffer. New view field panelMirror, new methods bindMirrorPanel / prepareMirrorTestRows / bindMirrorRow / runMirrorAllTests / updateMirrorCounters / sendMirrorLog — follow the exact pattern of the existing DL5 panel for visual consistency (same status pill, same counters block, same per-test row layout via item_beta_test.xml). New layout include_diag_mirror.xml — clone of include_diag_dilink5.xml minus the per-app Spinner (no per-app target for the Mirror suite). The action row exposes two buttons: Lancer tous (run all tests) and Envoyer (.log) (share the bundled report). The Envoyer (.log) button calls AppLogger.shareWithReport(this, mirrorReport) which already routes through Intent.ACTION_SEND with a FileProvider URI → Android share chooser → the user picks Telegram from the chooser and the message goes through with the full report attached. 2. MirrorTestRunner — 9 tests (M1–M9) Self-contained suite under com.byd.dashcast.mirror. Same data model triplet (TestDef / TestResult / Status / Listener) and same single-thread executor pattern (mirror-test-runner) as the DL5 runner — intentionally not sharing nested types so a regression in either suite cannot affect the other. The suite writes all heavy artifacts (full SF dumps, daemon log copy) to /storage/emulated/0/Download/dl5_mirror_diag/, directly browsable from the BYD file manager. ID Test What it captures M1 Cluster display fingerprint (no shell) DisplayManager.getDisplays() + reflective Display.getLayerStack / getOwnerPackageName / getOwnerUid for every display: id, name, real size, density, flag breakdown, owner pkg/uid, layerStack. The WindowManager-side identity of the cluster surface, decoupled from SurfaceFlinger. M2 SurfaceControl.getPhysicalDisplayIds() (reflection) Reflective call to the hidden API plus getPhysicalDisplayToken(id) for each returned id. SecurityException expected from the app uid — the failure mode itself is useful evidence. M3 dumpsys SurfaceFlinger --list Compositor's view of every display/layer name (top 100 lines). M4 Full dumpsys SurfaceFlinger (head -300) Saved verbatim to Download/dl5_mirror_diag/dumpsys_sf_full.txt for offline inspection. M5 Filtered SF topology grep -E 'Display |layerStack|format|orientation|XDJA|fission|cluster|byd|projection|mirror' — extracts only the lines we need to map layerStack ↔ cluster display ↔ XDJA fission compositor. M6 dumpsys window cluster state grep -E 'Display #|mDisplayId|mCurrentFocus|mFocusedApp|cluster|fission|XDJA|imeLayerStack' — WindowManager's view of which apps live on which display, focus owner, IME layer. M7 MirrorDaemon log tail (200 lines) Reads /data/local/tmp/mirrordaemon_latest.log if present. This is the gold evidence: the daemon writes its own post-setup dumpsys SurfaceFlinger | grep byd_myapp_mirror here. WARN if the file is missing (daemon never launched in this session). M8 Copy MirrorDaemon log → Download/ Copies /data/local/tmp/mirrordaemon_latest.log to Download/dl5_mirror_diag/mirrordaemon_latest.log so it ships alongside the textual report. M9 Mirror token presence post-setup dumpsys SurfaceFlinger | grep -E 'byd_myapp_mirror|mybyd_preview_mirror'. If the token is absent the daemon's createDisplay silently failed; if present but cluster still black, the layerStack mapping is wrong (cluster pixels live in another compositor). 3. Behavioural contract Mirror tab is read-only diagnostic only. No shell command issued by the suite mutates display state, no wm overscan/size/density calls, no am start --display, no projection toggle. Zero changes to MirrorDaemon, ClusterMirrorManager, ClusterService or any cluster touch/launch path. DL3 mirror unchanged. DL5 mirror unchanged. Existing 9 Diag tabs unchanged. DL5 test D30 keeps its broader SF dump; the M-suite is a more curated mirror-focused subset. The DL2 hard-ban on display-resize shell commands (build 191) still owns that contract — none of the M-tests can bypass it. 4. Files touched DiagActivity.java — TAB_MIRROR = 8, TAB_SNIFFER pushed to 9, TAB_COUNT = 10, panelMirror field, bindMirrorPanel / prepareMirrorTestRows / bindMirrorRow / runMirrorAllTests / updateMirrorCounters / sendMirrorLog, showPanelForTab Mirror branch (~150 LoC added). New mirror/MirrorTestRunner.java — ~330 LoC, 9 tests + buildReport + runShellSync helper. New include_diag_mirror.xml — ~140 LoC, clone of DL5 panel minus the Spinner, action row with Lancer tous + Envoyer (.log). activity_diag.xml — +1 TabItem (@string/diag_tab_mirror), +1 panel <include>. values/strings.xml — +8 diag_mirror_* strings (FR default). build.gradle — versionCode 192 → 193, versionName 1.2.3 → 1.2.4. No new permissions, no new dependencies, no new drawables. How to validate On the affected DL5 device Install the OTA (versionCode 193 > 192, the car detects it as an update). Launch DashCast → tap Start projection so the cluster mirror gets attempted (this is what produces mirrordaemon_latest.log). Open Diag → swipe to the new Mirror tab → tap Lancer tous. Expected results: M1 PASS — at least 1 PRESENTATION display detected, layerStack/owner reported. M2 WARN or PASS — reflection may be blocked by SELinux on the app uid; the failure mode is evidence either way. M3–M6 PASS — local ADB shell present. M7 PASS — daemon log produced during the projection attempt in step 2. M8 PASS — copy to Download/dl5_mirror_diag/mirrordaemon_latest.log succeeded. M9 PASS if the mirror token exists in SF (the silent-success case we want to confirm); WARN if it does not (= the daemon's createDisplay is the failure point). Tap Envoyer (.log) → Android share chooser opens → pick Telegram → message goes through with the full report attached. The operator now has on-device, browsable via the BYD file manager: Download/dl5_mirror_diag/dumpsys_sf_full.txt — live SF topology Download/dl5_mirror_diag/mirrordaemon_latest.log — the daemon's own SF dump Plus the textual M1–M9 report attached to the Telegram message. On DL3 (BYD Seal EU, production reference) Install, open Diag, confirm default tab is unchanged (Beta Engine). Swipe to Mirror tab (visible at position 8). Tap Lancer tous — the same suite runs (M1 yields the DL3 cluster display fingerprint, the rest succeeds on shell). No regression on DL3 mirror behaviour. On DL2 (alps / k65v1 / API 28-29) Install, open Diag. Default tab is still DiLink 2 (per build 192). Mirror tab is reachable but irrelevant on DL2; the suite runs read-only without issuing any resize commands (the build-191 DL2 guard still owns that contract). Compatibility versionCode 193 (was 192) — OTA-eligible for every device currently on build 192 or earlier. versionName 1.2.4 (was 1.2.3). minSdkVersion 28 unchanged. targetSdkVersion 29 unchanged. compileSdkVersion 33 unchanged. No new runtime permission requested. Known limitations M2 is reflective access to a hidden API (SurfaceControl.getPhysicalDisplayIds). It is expected to be blocked by SELinux on the app uid on most stock ROMs — the WARN/error message is the useful signal. M7 / M8 require that the mirror was launched at least once in the current boot session, so /data/local/tmp/mirrordaemon_latest.log exists. If absent, the two tests cleanly WARN with "daemon log not found — launch mirror once then re-run". This build does not yet attempt a fix for the DL5 black-screen — it only collects evidence. The fix will land in a follow-up build once the M-suite output confirms the working hypothesis (layers live in the XDJA fission compositor, not in SF native layers). Full per-build history: see CHANGELOG.md. LinksAPK download GitHub release page

DashCast v1.2.3DashCast v1.2.3 — DiLink 2 diagnostics & DiLink 2 hardening Pre-release — versionCode 192. Targets DiLink 2 (k65, Android 9, API 28/29), DiLink 3 (Seal EU, API 29) and DiLink 5 (BYD-AUTO, API 32). All three platforms share the same APK; auto-detection routes each car to the right code path. Headlines Diag opens on the right tab automatically. DiLink 2 users now land directly on the DiLink 2 tab. DiLink 5 users still land on DiLink 5. All other devices land on Beta Engine. 40-test DiLink 2 diagnostic suite (was 30). Ten new shell-driven RE tests, including a dedicated APK extractor. One-tap APK extraction to /storage/emulated/0/Download/dl2_apks/. com.byd.cluster is always pulled first; the whole BYD/alps/xdja whitelist follows. APKs are then directly accessible from the BYD file manager and can be attached to bug reports. DL2 cluster-resize: total ban. Every shell command that could resize a physical display on DiLink 2 is rejected at three independent layers — AdbLocalClient, ShellGateway, SettingsActivity. No path can call wm size, wm density, wm overscan, am display-size, or settings put * display_* on a DL2 car. DiLink 3 and DiLink 5 are unaffected. Zero impact on DiLink 3 and DiLink 5 — same APK, same versionCode, only DL2-specific code paths changed. DiLink 2 — full 40-test catalog Tier L — reflection only (no ADB required, 15 tests) ID Test L1 Platform fingerprint (Build.* + 26 ro.* props) L2 ADB-local TCP port probe (5037 / 5554 / 5555 / 5556 / 4444) L3 Multi-display reflective scan (DisplayManager + DisplayManagerGlobal) L4 SurfaceFlinger physical displays via IBinder L5 DRM / framebuffer inventory (/sys/class/drm, /dev/graphics) L6 ServiceManager full inventory + BYD/cluster filter L7 Cluster service brute probe (33 candidate names) L8 IActivityManager method enumeration L9 ActivityOptions.setLaunchDisplayId smoke test L10 BYD packages dynamic scan via PackageManager L11 com.byd.cluster manifest deep dive L12 com.byd.appstartmanagement manifest deep dive L13 BYD SDK classpath probe (8 BYDAuto*Device classes) L14 /proc cluster process scan L15 Hidden-API reachability sanity (6 system binders) Tier S — ADB-TCP shell-driven (15 tests) ID Test S1 ADB shell reachable (id -u, id -un, pwd, uname -a) S2 Runtime properties (getprop, filtered) S3 Display state (wm size, wm density, wm overscan) S4 dumpsys display full inventory S5 dumpsys SurfaceFlinger physical displays S6 service list filtered BYD/cluster S7 AutoContainer probe (service call AutoContainer 1 + snake-case variants) S8 pm list packages -f BYD/alps/xdja S9 Activity stack snapshot (dumpsys activity) S10 SELinux + sepolicy state (getenforce, id -Z) S11 Daemon process scan (ps -A, filtered) S12 System settings BYD filter (system / secure / global) S13 Display launch probe (`am start --display 0 S14 Hardware fingerprint (cpuinfo + meminfo + df) S15 Filesystem inventory (BYD / DRM / framebuffer) Tier S — new in build 192 (RE-oriented, 10 tests) ID Test S16 BYD packages discovery via shell (pm list packages -f) — populates the discovery cache used by S17 S17 APK extraction → /storage/emulated/0/Download/dl2_apks/. com.byd.cluster is extracted first, then appstartmanagement, containerservice, smarttravel, commander, freedom, overdrive, windowmanagement, crosscontrol, clusterdebug, car.server, plus any package whose name contains cluster, fission, projection, dilink, magicwindow, mirror. Re-extraction is cache-aware (size check via stat -c %s). Filename pattern: <pkg>_v<versionCode>.apk S18 dumpsys window filtered (focused / displays / overscan / IME / stacks) S19 dumpsys SurfaceFlinger --list + HWComposer topology grep S20 Recent logcat tail (200 lines, BYD/cluster filter) S21 dumpsys package com.byd.cluster full (250 lines — manifest, services, providers, permissions) S22 dumpsys package com.byd.appstartmanagement full S23 BYD framework JARs + permission XMLs (/system/framework, /vendor/framework, /system/etc/permissions, /vendor/etc/permissions) S24 am stack list + am task list (API 28 only — direct evidence of multi-display task placement) S25 Crash logs (tombstones + ANR + dropbox, BYD-filtered) DL2 cluster-resize hard-ban (build 191) DiLink 2 cars must never receive a display-resize command — empirical evidence shows the cluster panel reacts unpredictably and can require a reboot. Build 191 enforces total prohibition at three independent layers: AdbLocalClient — every outgoing wm size, wm density, wm overscan, am display-size, settings put system display_*, settings put secure display_*, settings put global display_* is intercepted and dropped before being written to the local-ADB socket when the platform reports DL2. ShellGateway — same predicate enforced in the higher-level shell façade used by Beta Engine / overscan / mirror / projection paths. SettingsActivity — the overscan and resize sliders are disabled and labelled DiLink 2 — resize banned on detected DL2 devices. DiLink 3 (Seal EU) and DiLink 5 (BYD-AUTO) are unchanged: resize commands continue to be forwarded normally on those platforms. Platform detection DiLink 2 is detected when all of the following hold (cumulative AND, cached at process start): Build.BRAND.equalsIgnoreCase("alps") && Build.PRODUCT.toLowerCase().contains("k65") && (Build.VERSION.SDK_INT == 28 || Build.VERSION.SDK_INT == 29) DiLink 3 (Seal EU): Build.MANUFACTURER == BYD && Build.PRODUCT == byd_eu_* && API 29. DiLink 5 (BYD-AUTO): Build.MANUFACTURER == BYD-AUTO && API 32. The three predicates are mutually exclusive. Each platform only sees its own code path. Operator workflow on DiLink 2 Open DashCast → Diag (lands directly on DiLink 2 tab). Tap Lancer tous — 40 rows complete sequentially. S17 reports N APK(s) in Download/dl2_apks/. Open the BYD file manager → Download → dl2_apks → com.byd.cluster_v<X>.apk (and the rest of the BYD apk set) is ready to pull off the car. Tap Envoyer (.log) in DashCast → full diagnostic log goes out via Telegram. Compatibility DiLink 2 (alps / k65 / API 28–29): full feature set, 40 tests, resize banned, Diag opens on DL2 tab. DiLink 3 (BYD Seal EU / API 29): unchanged; Diag opens on Beta Engine. DiLink 5 (BYD-AUTO / API 32): unchanged; Diag opens on DiLink 5 tab. Install In-app updater: tap Vérifier les mises à jour in Settings (with Include pre-releases enabled). The car will detect this build as an update if its installed versionName is lower than 1.2.3 or if its versionCode is lower than 192. Manual install: download DashCast-v1.2.3-debug.apk below and pm install -r it via ADB. LinksAPK download GitHub release page

DashCast v1.2.2DashCast 1.2.2 (build 188) — DL5 app launch via ADB shell + wm overscan gated on DL3 Pre-release on branch beta/1.2.0-dilink5. Not merged into main. versionCode 187 → 188 — Android's package manager will detect this as a regular update of any installed 1.2.1 build. This build is the direct field-driven follow-up to 1.2.1 (build 187). The DL5 field log byd_report_20260522_132030.log showed the new projection wiring from 1.2.1 working perfectly up to the display-ready event, then crashing at the next step (app launch) with a SecurityException. Build 188 fixes that and also addresses the secondary Unknown command: overscan noise visible in the same log. What the build 187 log told us The DL5 testeur device confirmed the projection trigger and display resolution work as designed: [ClusterManager] DL5 activation path: sendInfo(16) only on auto_container [AdbLocalClient] sendInfo ADB: service call auto_container 2 i32 1000 i32 16 s16 "" 2>&1 [AdbLocalClient] sendInfo ADB(1000,16) → Result: Parcel(00000000 00000001 '........') [ClusterManager] DL5 cluster display ready: id=3 name=shared_fission_bg_XDJAScreenProjection_0 [ClusterService] Cluster display connected: id=3 [ClusterInputForwarder] Cluster dimensions: 1920x720 displayId=3 But the very next phase (launching the user's selected app on display 3) failed: [ClusterService] Launching via IActivityManager on display=3 → ru.yandex.yandexmaps [ClusterService] startActivityViaIAM → fallback context: null [ClusterService] Global launch error for ru.yandex.yandexmaps [SecurityException: Permission Denial: starting Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10008000 pkg=ru.yandex.yandexmaps cmp=ru.yandex.yandexmaps/.SplashScreen } from ProcessRecord{... com.byd.dashcast/u0a148} (pid=9647, uid=10148) with launchDisplayId=3] Our app's uid 10148 is denied cross-display launches by IActivityTaskManager on DiLink 5.0, even though INTERNAL_SYSTEM_WINDOW is granted at install time. This differs from DiLink 3.0 where the same typed-IATM reflection path works fine. The D31 diagnostic probe (build 186) had already validated the workaround: route the launch through ADB shell (uid 2000, which on this hardware has both the BYD auto_container whitelist entry and the unrestricted activity-launch privileges granted to the shell user). Build 188 ports that workaround into production. The same field log also revealed three wm overscan ... -> Unknown command: overscan errors. The wm overscan subcommand was removed in Android 11 (API 30) — DL5 is API 32, so every wm overscan shell call has been a no-op since 1.2.0. Build 188 stops issuing it on DL5. DL5 app launch — ADB shell route AdbLocalClient.isDiLink5Safe(Context) — visibility bumped Previously private static. Now package-private so ClusterService (same package com.byd.dashcast) can reuse the existing exception-safe DL5 detector instead of duplicating the try/catch around Platform.get().isDiLink5(ctx). Behavioural contract unchanged: returns true only when both Context != null and Platform.isDiLink5(ctx) returns true; any reflection failure returns false. Helper still cannot throw. New ClusterService.startActivityViaShell(packageName, displayId, launchIntent) String component = null; if (launchIntent != null && launchIntent.getComponent() != null) { ComponentName cn = launchIntent.getComponent(); component = cn.getPackageName() + "/" + cn.getClassName(); } if (component == null) { AppLogger.e(TAG, "startActivityViaShell: cannot resolve component for " + packageName); return; } final String cmd = "am start --display " + displayId + " -a android.intent.action.MAIN -c android.intent.category.LAUNCHER" + " -n " + component + " --activity-clear-task 2>&1"; AppLogger.i(TAG, "DL5 launch via shell: " + cmd); AdbLocalClient.executeShellWithResult(this, cmd, new AdbLocalClient.Callback() { @Override public void onSuccess(String out) { AppLogger.i(TAG, "DL5 am start → " + out.trim()); } @Override public void onError(String err) { AppLogger.e(TAG, "DL5 am start ERROR: " + err); } }); Component resolution reuses the getLaunchIntentForPackage(pkg) machinery that was already populating the Intent upstream — no new PackageManager queries, no new failure modes. Command pattern is bit-identical to the D31 diagnostic probe that PASSed end-to-end on the DL5 testeur on 22/05/2026. Dispatch via AdbLocalClient.executeShellWithResult: the existing dadb-based shell relay (with cached ADB key pair already accepted by the device) runs on the background executor. Errors are logged via AppLogger.e but not propagated to the LaunchCallback — consistent with the legacy IATM path which also reports onResult(true) after best-effort dispatch (the typed reflection path's RemoteException branches are swallowed there too). launchOnDashboard() — DL5 branch Right before the legacy startActivityViaIAM(launchIntent, opts) call, the method now tests AdbLocalClient.isDiLink5Safe(this): launchIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK); ActivityOptions opts = ActivityOptions.makeBasic(); opts.setLaunchDisplayId(displayId); if (displayId > 0) applyClusterFreeformBounds(opts, displayId, packageName); if (AdbLocalClient.isDiLink5Safe(ClusterService.this)) { startActivityViaShell(packageName, displayId, launchIntent); } else { startActivityViaIAM(launchIntent, opts); } The applyClusterFreeformBounds() call still runs upstream and still applies setLaunchWindowingMode(FREEFORM) + setLaunchBounds(...) to the ActivityOptions — these are inert on DL5 (the shell am start ignores ActivityOptions entirely) but cost nothing to compute, and they remain necessary for the DL3 path which falls through to startActivityViaIAM unchanged. launchOnDashboardWithBounds() — DL5 branch Same pattern as launchOnDashboard(): on DL5 the shell path takes over, on DL3 the typed IATM path runs unchanged. Caveat: the explicit split-mode bounds passed by the caller (Rect left/top/right/bottom) are dropped on DL5 since am start does not accept windowing bounds. Split mode on DL5 would need a different approach (e.g. two shell launches on display #3 and #4 simultaneously, one app per physical PRESENTATION display) — out of scope for 1.2.2, will be addressed once single-app projection is field-validated. wm overscan — skipped on DL5 wm overscan was removed from WindowManagerService.ShellCommand in Android 11 (API 30) — its semantics were absorbed by wm display-add-state and DisplayInfo overrides. DL5 is API 32, so the command has been silently failing since 1.2.0. The field log confirmed: [AdbLocalClient] executeShellWithResult: wm overscan 80,50,80,50 -d 3 -> Unknown command: overscan (three times in the build 187 log: lines 31.016, 38.820, 46.264) Build 188 gates all three call sites on !isDiLink5Safe(this): applyClusterFreeformBounds() (per-launch overscan to apply app-specific insets). On DL5 logs DL5: skipping app-specific wm overscan (cmd removed in API 30+) at DEBUG level. onDashboardDisplayConnected() (display-level overscan applied once when the cluster display first comes up). Same log line at DEBUG. stopProjectionNoAdb() (reset overscan to 0,0,0,0 on display id 1 when teardown is requested via the BYD restore path). Bonus side-fix: the reset was hardcoding -d 1 (DL3 cluster display id) even on DL5 where the cluster lives at id 3 — was already producing the same Unknown command: overscan error. Now skipped entirely on DL5. On DL3 every overscan path is unchanged — DL3 still gets wm overscan H,V,H,V -d <displayId> applied at display-connect and at each app launch, plus the wm overscan reset -d 1 on stop. DiLink 3 — behavioural contract Every DL3 code path is bit-for-bit identical to build 187: launchOnDashboard() and launchOnDashboardWithBounds() — the DL5 branch is gated on isDiLink5Safe(this) which returns false on DL3, so the existing startActivityViaIAM(launchIntent, opts) typed reflection path runs unchanged with the same ActivityOptions (display id, freeform mode, launch bounds). applyClusterFreeformBounds() — DL3 still emits wm overscan H,V,H,V -d <displayId> at every launch and logs Applied app-specific wm overscan during launch on display N. onDashboardDisplayConnected() — DL3 still emits the display-level overscan and logs wm overscan applied on display N inset=H,V. stopProjectionNoAdb() — DL3 still emits wm overscan reset -d 1. The DL5 platform detection is wrapped in the same try/catch the rest of the codebase uses (isDiLink5Safe()), so any reflection failure on Platform.get().isDiLink5(ctx) falls back to the DL3 path — the production hot path can never throw because of platform detection. Build versionCode 187 → 188 versionName 1.2.1 → 1.2.2 (second 1.2.x minor bump in 24 hours, reflecting the iterative field-driven DL5 enablement) Branch beta/1.2.0-dilink5 — no merge into main per release policy Tag v1.2.2 Pre-release status Files touched MyBYDApp/app/build.gradle — version bump (187 → 188, 1.2.1 → 1.2.2) MyBYDApp/CHANGELOG.md — build 188 entry at top of Pre-releases MyBYDApp/app/src/main/java/com/byd/dashcast/AdbLocalClient.java — isDiLink5Safe visibility bump (private static → package-private) MyBYDApp/app/src/main/java/com/byd/dashcast/ClusterService.java — new startActivityViaShell() helper, DL5 branches in launchOnDashboard() and launchOnDashboardWithBounds(), DL5 guards on the three wm overscan shell call sites No new dependencies, no new permissions, no protocol changes, no new resources, no new strings, no new layout files. Validation plan DiLink 5 testeur device Cold-reboot to ensure XDJAScreenProjection_* PRESENTATION displays are up at id 3 and id 4. Install DashCast-v1.2.2-debug.apk. Open the dashboard, tap a target app — Yandex Maps, Huawei Maps, Waze, Standard ADB, or any non-system package declaring a LAUNCHER activity. Expected logcat sequence (tags ClusterManager + ClusterService + AdbLocalClient): DL5 activation path: sendInfo(16) only on auto_container sendInfo ADB(1000,16) → Result: Parcel(00000000 00000001 '........') DL5 cluster display ready: id=3 name=shared_fission_bg_XDJAScreenProjection_0 Cluster display connected: id=3 Cluster dimensions: 1920x720 displayId=3 DL5: skipping display-level wm overscan (cmd removed in API 30+) DL5 launch via shell: am start --display 3 -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -n <pkg>/<launcher activity> --activity-clear-task 2>&1 executeShellWithResult: am start --display 3 ... -> Starting: Intent { ... } DL5 am start → Starting: Intent { ... } Visual check: the selected app appears on the cluster display. Absence check: no more SecurityException: Permission Denial ... with launchDisplayId=3 and no more Unknown command: overscan in the logs. Press Stop Projection. Expected: service call auto_container 2 i32 1000 i32 18 s16 "" 2>&1 ← from build 187 service call auto_container 2 i32 1000 i32 0 s16 "" 2>&1 ← from build 187 (no wm overscan reset line — gated out on DL5) Optional: Diag → ADAS tab → confirm pill still reads auto_container, both buttons still work (no regression on build 187 features). DiLink 3 reference device (regression check) Install DashCast-v1.2.2-debug.apk on a known-good DL3 cluster device. Trigger Start Projection. Expected logcat sequence unchanged from build 187: activation ADB(cmd=30): ... activation ADB(cmd=16): ... activation ADB(cmd=35): ... Launching via IActivityManager on display=N → <pkg> Applied app-specific wm overscan during launch on display N wm overscan applied on display N inset=H,V Regression markers — any of these lines in DL3 logs is a bug: DL5 launch via shell: (DL5 branch should not trigger) DL5: skipping ... wm overscan (cmd removed in API 30+) (DL5 guard should not trigger) DL5 activation path: (DL5 short-circuit from build 187 should not trigger) ADAS panel pill must still read AutoContainer (PascalCase, no underscore — fixed in 1.2.1) and both Afficher ADAS (12) / Masquer ADAS (13) must still light up the lamps. Telegram Post the DashCast-v1.2.2-debug.apk link plus a short note pointing field testers to the DL5 visual check (step 5 above). LinksAPK download GitHub release page

DashCast v1.2.1DashCast 1.2.1 (build 187) — DiLink 5 production projection Pre-release on branch beta/1.2.0-dilink5. Not merged into main. versionCode 186 → 187 — the car's package manager will detect this APK as a regular update of any previously installed DashCast 1.2.0 build. This build is the first production-side integration of the DiLink 5 projection sequence that the D12 and D31 diagnostic probes had only validated shell-side in build 186 (see field log byd_report_20260522_125322.log). Start Projection and Stop Projection now route through the correct AutoContainer flavour depending on the detected platform — DiLink 3 keeps the existing field-tested sequence bit-for-bit, DiLink 5 gets the minimal validated sequence. Platform dispatch — service-name routing DiLink 3 and DiLink 5 expose the cluster control binder under different names. Build 187 introduces a centralised, exception-safe dispatcher in AdbLocalClient: Platform Service name Confirmed by DiLink 3 (BYD Seal EU / Atto 3 / …) AutoContainer (PascalCase) User on production cluster, 22/05/2026 DiLink 5 (BYD-AUTO API 32) auto_container (snake_case) D11 / D12 / D31 PASS, field log 22/05/2026 New helpers in AdbLocalClient: autoContainerSvcName(Context) — returns the right name, never throws (any reflection failure on Platform.get().isDiLink5(ctx) falls back to the DL3 default). isDiLink5Safe(Context) — boolean wrapper with the same exception contract, used for gating the typed-daemon path. Three production call sites refactored to consume the helper instead of the previously hardcoded "AutoContainer" literal: AdbLocalClient.sendInfo() — the central service call … relay used by every callsite that ships an info code to the cluster. AdbLocalClient.restoreBydOnCluster() — Stop Projection (force-stop target + sendInfo(18) + sendInfo(0)). AdbLocalClient.restoreOriginCluster() — Stop Projection + restore original screen size (the sendInfo(<screenSizeCmd>) tail is a harmless no-op on DL5 since slot 30 is empty in the _Di5 clusterdebug enum). Typed daemon path — gated on DL3 BetaProxyClient.autoContainerSendInfo() resolves the binder via ServiceManager.getService("AutoContainer") — hardcoded in Phase4Verbs.AUTOCONTAINER_SVC. That name does not exist on DiLink 5, so every typed transact(2, …) would fail with IllegalArgumentException and force an extra round-trip before falling back to the shell relay. Build 187 short-circuits the typed path on DL5 in all three sites that previously gated it on BetaConfig.isProxyDaemonEnabled(context) alone: if (BetaConfig.isProxyDaemonEnabled(context) && !isDiLink5Safe(context)) { // typed daemon path — DL3 only } // shell fallback — picks svc name via autoContainerSvcName(context) DiLink 5 always goes straight to the shell with service call auto_container 2 …. DiLink 3 behaviour is unchanged: typed path tried first, shell fallback on failure with the correct AutoContainer name. Phase4Verbs itself is not touched in this build — the typed daemon remains a DL3-only optimisation. Migrating it to a DL5-aware variant (probing both AutoContainer and auto_container at startup with a cached IBinder) is out of scope for 1.2.1 because the shell path on DL5 is already fast enough (no service binary fork on DL5 — auto_container returns the Parcel in ~5 ms). Start Projection — ClusterManager.activateClusterDisplay() New short-circuit branch at the top of activateClusterDisplay() for DiLink 5: if (isDiLink5Safe()) { AppLogger.i(TAG, "DL5 activation path: sendInfo(16) only on auto_container"); AdbLocalClient.sendInfo(mContext, CLUSTER_TYPE, CMD_PROJECTION_ON, "", new AdbLocalClient.Callback() { @Override public void onSuccess(String out) { AppLogger.i(TAG, "DL5 activation ADB(cmd=16): " + out); mHandler.postDelayed(() -> resolveDl5Display(dm, callback), 500); } @Override public void onError(String err) { AppLogger.e(TAG, "DL5 activation ADB(cmd=16) ERROR: " + err); mHandler.postDelayed(() -> resolveDl5Display(dm, callback), 500); } }); return; } What changed compared to the DiLink 3 sequence: No sendInfo(30) (screen-size hint). Slot 30 is empty in the _Di5 variant of the clusterdebug enumeration documented in build 184 — the DL5 cluster Qt code never reads it. Sending it would just be a wasted round-trip. No sendInfo(35) (Di4.0 mode / VirtualDisplay creation). On DL3 this is what triggers AutoDisplayService.createVirtualDisplay() and the fission_bg_xdjaVirtualSurface PRESENTATION display appears ~280 ms later. On DL5 the equivalent XDJAScreenProjection_0 / XDJAScreenProjection_1 displays already exist at boot as persistent PRESENTATION displays (confirmed in D2 / D21 / D31 of the 22/05/2026 field log), so sendInfo(35) is unnecessary and would target an empty slot. Only sendInfo(16). This is the projection-ON trigger — the same code that D12 and D31 already validated end-to-end on the DL5 testeur device. 500 ms settle delay before resolving the display. In practice the displays are already up; the delay exists to absorb the rare case where the cluster Qt side needs a frame to react to sendInfo(16). Direct user constraint from the task brief: Le mieux maintenant c'est de câbler Start Projection pour Dilink5 qui fait uniquement la command 16 pour activer la projection avec le bon auto_container. Display targeting — resolveDl5Display() New private helper on ClusterManager. Reuses the existing findClusterDisplay(dm) which already returns the first non-default PRESENTATION display — so on the DL5 testeur device this naturally picks display id 3 (shared_fission_bg_XDJAScreenProjection_0). Display id 4 (_1) is left available for a future second-screen use. On miss, the helper polls every 250 ms for up to 3 s before calling onDisplayTimeout() — a defensive safety net that should never trigger on DL5 since the field log confirmed both XDJAScreenProjection_* displays are PRESENTATION-categorised and present from boot. Direct user constraint: on vient diffuser les applications lancé sur le display ID3 déjà pour commencer. findClusterDisplay() and isClusterDisplay() themselves are unchanged — they already accept any non-default display, so the DL5 displays #3 and #4 qualify out of the box. Stop Projection — automatic via existing path restoreBydOnCluster() was already issuing exactly the sequence the user asked for on DL5: force-stop <target package> sendInfo(1000, 18, "") // close projection sendInfo(1000, 0, "") // refresh Qt video stream The only concern on DL5 was the service name — fixed in section "Platform dispatch" above. No changes to the orchestration. Same goes for restoreOriginCluster(), where the optional trailing sendInfo(<screenSizeCmd>) is a harmless no-op on DL5 (empty slot 30 in _Di5, service call returns an empty Parcel without raising). Direct user constraint: Il faut aussi cabler le arreter projection qui fait les commandes 18 et 0 toujours avec le bon auto_container. Diagnostics — ADAS panel service-name fix DiagActivity.autoContainerSvcName() had shipped a wrong DL3 default since build 184: it returned "Auto_container" (PascalCase with underscore) — a name that does not exist on either platform. The ADAS quick-toggle panel was therefore silently issuing service call Auto_container 2 … on DL3, which the cluster ignores. Build 187 fixes the default to "AutoContainer" (PascalCase, no underscore) — the name the user confirmed in production on DL3 on 22/05/2026. DL5 keeps "auto_container" (snake_case). The pill displayed at the top of the ADAS panel now reads the correct service name on both platforms, and the Afficher ADAS (12) / Masquer ADAS (13) buttons send service call AutoContainer 2 i32 1000 i32 12 s16 "" on DL3 and the snake_case equivalent on DL5. DiLink 3 — behavioural contract Every DiLink 3 code path is bit-for-bit identical to build 186: The new DL5 branch in ClusterManager.activateClusterDisplay() is the very first statement of the method and is gated on isDiLink5Safe(). On DL3 it short-circuits to false and the existing 30 → 6 s → 16 → 6 s → 35 sequence runs unchanged, including every onError fallback branch. AdbLocalClient.sendInfo() typed-daemon path still runs first on DL3 (the isProxyDaemonEnabled && !isDiLink5Safe guard collapses to isProxyDaemonEnabled on DL3 since the negation is true). The shell fallback still emits service call AutoContainer 2 … on DL3 because autoContainerSvcName(ctx) returns "AutoContainer" when Platform.isDiLink5(ctx) is false. restoreBydOnCluster() / restoreOriginCluster() shell paths same story — AutoContainer on DL3, auto_container on DL5. User constraint explicitly stated in the task brief: Par contre on ne doit pas casser la partie Dilink3. Build versionCode 186 → 187 versionName 1.2.0 → 1.2.1 (first 1.2.x minor bump since the DL5 work started — reflects the production-side wiring being now in place) Branch beta/1.2.0-dilink5 — no merge into main in this build per the user's release policy Tag v1.2.1 Pre-release status — should be installed on testeur devices first Files touched MyBYDApp/app/build.gradle — version bump MyBYDApp/CHANGELOG.md — build 187 entry at the top of Pre-releases MyBYDApp/app/src/main/java/com/byd/dashcast/AdbLocalClient.java — helpers + 3 shell call-site refactors + 3 typed-daemon gates MyBYDApp/app/src/main/java/com/byd/dashcast/dashboard/ClusterManager.java — DL5 short-circuit + isDiLink5Safe helper + resolveDl5Display helper MyBYDApp/app/src/main/java/com/byd/dashcast/DiagActivity.java — ADAS DL3 service-name fix No new dependencies, no new permissions, no protocol changes, no new resources, no new strings. Validation plan DiLink 5 testeur device Cold-reboot to ensure XDJAScreenProjection_* PRESENTATION displays are up. Install DashCast-v1.2.1-debug.apk. Open the dashboard, select a target app (Waze, com.github.standardadb, or any non-system package declaring a LAUNCHER activity). Press the existing Start Projection control. Expected logcat sequence (tag ClusterManager + AdbLocalClient): DL5 activation path: sendInfo(16) only on auto_container sendInfo ADB: service call auto_container 2 i32 1000 i32 16 s16 "" 2>&1 DL5 activation ADB(cmd=16): Result: Parcel(...) DL5 cluster display ready: id=3 name=shared_fission_bg_XDJAScreenProjection_0 The existing app-launch path (which already uses ActivityOptions.setLaunchDisplayId) takes over and the app should appear on the cluster. Press Stop Projection. Expected: service call auto_container 2 i32 1000 i32 18 s16 "" 2>&1 service call auto_container 2 i32 1000 i32 0 s16 "" 2>&1 Open Diag → ADAS tab → confirm the pill reads auto_container. Press Afficher ADAS (12) → warning lamps should appear on the cluster. Press Masquer ADAS (13) → they should disappear. DiLink 3 reference device (regression check) Install DashCast-v1.2.1-debug.apk. Trigger Start Projection on a configured DL3 cluster. Expected logcat sequence unchanged from build 186: activation ADB(cmd=30): ... activation ADB(cmd=16): ... activation ADB(cmd=35): ... The shell path should consistently emit service call AutoContainer 2 … (PascalCase, no underscore) — any Auto_container or auto_container is a regression. Open Diag → ADAS tab → confirm the pill reads AutoContainer. Press the two buttons and verify the cluster reacts. Telegram channel Post the DashCast-v1.2.1-debug.apk link plus a one-line summary so testers can sideload. LinksAPK download GitHub release page

DashCast v1.2.0-build186DashCast 1.2.0 — build 186 (DiLink 5 enablement) Pre-release on the beta/1.2.0-dilink5 channel. Two scope items on top of build 185, both rooted in the 22/05/2026 DL5 field log (byd_report_20260522_115956.log) and the user's live testing on the DL5 vehicle: D10 APK extraction relocated to a user-visible destination, and a new D31 end-to-end cluster projection probe driven by com.byd.clusterdebug. This build is detected by the in-car OTA channel as an update over build 185. No production hot path was changed — projection lifecycle, ClusterManager, AdbLocalClient, daemon code are bit-for-bit identical to build 185. Everything in this build is opt-in via Diag → DiLink 5. D10 — APK extraction relocated to Download/dashcast_apks/ Field-tester feedback on build 185. The previous output dir was effectively invisible: getExternalFilesDir(null)/extracted_apks/ — app-private external storage, not surfaced by the BYD file manager without root. User saw "PASS, 7 APKs ready" in the report but had no way to grab the files without adb pull from a PC. Worse: every re-run added duplicate-or-cached copies into a dir the user could never empty by hand → slowly ate internal storage build after build. Fix. All filesystem ops in runD10 now go through the ADB shell (uid 2000, which on Android 10+ has unrestricted write access to /sdcard/Download/). mkdir -p /storage/emulated/0/Download/dashcast_apks at start-up. Cache check via stat -c %s '<dst>' (avoids relying on the app uid being able to read() the destination on A10+ scoped storage). Copy via cat '<src>' > '<dst>' && stat -c %s '<dst>'. At the very start of each runD10, the legacy getExternalFilesDir(null)/extracted_apks/ is wiped via rm -rf so the next install no longer accumulates dead bytes. PASS message now reads N APK(s) in Download/dashcast_apks/ (X cached), Y skipped. User-visible result. Destination is browsable by the stock BYD file manager (visible under Download → dashcast_apks). Removes the adb pull requirement entirely for users without a PC. Re-runs are zero-shell for already-extracted APKs (cache hit on versionCode embedded in the filename). D31 (new) — Live cluster projection end-to-end probe First test that drives the full visual cycle the user has been doing by hand to confirm DL5 projection works. For each DISPLAY_CATEGORY_PRESENTATION display (DL5 exposes #3 and #4 as XDJAScreenProjection_0/1): Step Action Why a sendInfo(1000, 16) Opens the projection tunnel; the shared_fission_bg_XDJAScreenProjection_* layerStack becomes visible (initially black — this is what the user confirmed seeing during D28 of build 185). b wait 1.5 s Lets Qt reposition the overlay. c am start --display N -n <pkg>/<launcher> Pushes a real activity onto the projection layerStack so the cluster shows the app, not just a black window. d wait 3 s User observes the cluster — this is the user-visible window. e dumpsys activity activities filtered on the package Snapshot of where the activity landed; correlates the visual with the stack state. f am force-stop <pkg> Clean release of the activity. g sendInfo(1000, 18) Closes the projection tunnel. h sendInfo(1000, 0) Restores native cluster video flow. i wait 1.5 s Visual separation between iterations. Target package — clusterdebug by default D31 targets com.byd.clusterdebug by default — BYD's own cluster diagnostic app, guaranteed to be installed on every DL5 head unit and designed to render on the cluster. The D8 dropdown at the top of the DL5 panel is an optional override: pick another installed package and D31 will use that one instead. PackageManager.getPackageInfo(pkg, 0) is called up front and FAILs cleanly with a clear message before any cluster touch if the package isn't installed. The report header now shows (default clusterdebug) or (D8 dropdown override) so you know exactly which path ran. Launcher resolution Reuses the existing resolveLauncherComponent(ctx, pkg) helper so am start --display N -n <ComponentName> always targets the package's declared LAUNCHER activity, whatever its concrete class name is. FAILs with Could not resolve a launcher activity for '<pkg>' if the package declares no launcher (rare — typically a service-only package). Status semantics PASS — every am start --display returned without error / SecurityException / Permission Denial. Message reads Cycle run on N display(s) — user to confirm visual rendering to keep the final go/no-go in the user's hands (this is a visual test; the shell can only say the API accepted the call, not that pixels actually reached the cluster). WARN — partial success. FAIL — every launch was refused. The full per-display sequence (commands + outputs + activity-stack snapshot) is dumped to r.detail so the user can read the report to understand which display did or did not light up. Cleanup guarantee D31 leaves the cluster in a clean state regardless of failure: am force-stop + sendInfo(18) + sendInfo(0) are always issued at the end of each per-display iteration, including on partial failure. Behavioural contract Production hot path (projection lifecycle, ClusterManager, AdbLocalClient, daemon code) is unchanged. The new D31 sequence is opt-in (Diag → DiLink 5 → tap D31 or Run all). DL5 test catalog grows from 30 to 31 entries — surfaced automatically by the existing prepareDl5TestRows() / bindDl5Row() UI code; no layout, strings, drawables, dependencies, or permissions added. DL3 / DL5 / DL2 production paths are bit-for-bit identical to build 185. Validation plan Sideload or OTA install on a DL5 vehicle. Open Diag → DiLink 5. Run D9 (discovery) then D10 → verify the 7 BYD APKs land in Download/dashcast_apks/ and that the BYD file manager sees them. Run D31 → the cluster should: Black out (sendInfo 16) for ~1.5 s. Display the clusterdebug UI for ~3 s on each PRESENTATION display. Black out again as sendInfo(18) / sendInfo(0) tear it down. Copy the report (Envoyer (.log)) and share for triage. Build versionCode 185 → 186 versionName pinned "1.2.0" per channel policy Touched files outside CHANGELOG / gradle: dilink5/DiLink5TestRunner.java (D10 body rewritten to shell-based ops + legacy dir cleanup, D31 added at the end of the file, catalog +1 entry, dispatcher +1 case). No new dependencies, drawables, strings, layouts, permissions, or protocol verbs. Download The signed debug APK is attached below: DashCast-v1.2.0-debug.apk. LinksAPK download GitHub release page

DashCast v1.2.0-build185DashCast v1.2.0-build185 — DiLink 2 reconnaissance + horizontal swipe in Diag Pre-release on branch beta/1.2.0-dilink5. No merge to main. What's new 1. New DiLink 2 reconnaissance diagnostic tab A complete recon test suite (L1–L15, 15 tests) dedicated to the DiLink 2 / Android 9 platform (alps / k65v1_64_bsp / MediaTek MT6765 / API 28). The runner is built on a completely different foundation than the DL5 suite because the DL2 environment has no working ADB-over-TCP on 127.0.0.1:5555 (confirmed ECONNREFUSED in two field reports), so the entire AdbLocalClient shell stack is unreachable. Every probe in this suite uses Java reflection or pure-Java APIs callable from the app process — no shell at all: ID Test Mechanism L1 Platform fingerprint Build.* + 26 selected ro.* / persist.sys.* / sys.* props via reflected SystemProperties.get L2 ADB local TCP ports probe Raw Socket.connect(127.0.0.1, port, 200ms) on 5037 / 5554 / 5555 / 5556 / 4444 L3 Multi-display reflective scan DisplayManager.getDisplays() + reflective DisplayManagerGlobal.getDisplayIds() (may surface IDs hidden from PRESENTATION enumeration) L4 SurfaceFlinger physical displays via IBinder ServiceManager.getService("SurfaceFlinger") + getInterfaceDescriptor() — deliberately no custom transact to avoid AOSP-fork SIGSEGV L5 DRM / framebuffer inventory /sys/class/drm, /dev/graphics, /sys/class/graphics via java.io.File (fb1/fb2 or multiple DRM connectors = hardware second display) L6 ServiceManager full inventory + filter Reflective ServiceManager.listServices() filtered on cluster|display|secondary|byd|alps|auto|mirror|magic|window|fission|xdja|projection|cross L7 Cluster service brute probe ServiceManager.getService() on 33 candidate names spanning DL3/DL5/MTK/alps conventions (cluster, byd_cluster, Auto_container, auto_container, mtk_cluster, alps_cluster, secondary_display, magicwindow, crosscontrol, xdja_container, byd_carapi, etc.) — for each present binder also dumps the AIDL interface descriptor L8 IActivityManager method enumeration Reflection on android.app.IActivityManager (NOT IATM — API 28 has IAM only) filtered on movetask|setlaunch|startactivity|moveactivitytask|settaskwindowing|getfocusedstack|attachapplication with full signatures L9 ActivityOptions.setLaunchDisplayId smoke Pure availability check (already confirmed present on DL2) L10 BYD packages dynamic scan PackageManager.getInstalledPackages(0) filtered on com.byd.* / com.alps.* / com.xdja.* / *cluster* / *dilink* with version + APK path L11 com.byd.cluster manifest deep dive Activities, services, receivers, providers, declared and requested permissions L12 com.byd.appstartmanagement manifest Same as L11 (DL2 has v1.0 vs DL5 v1.5+) L13 BYD SDK classpath probe Class.forName + reflective getInstance() on 8 BYDAuto*Device classes (Speed / Energy / Gearbox / AC / AirConditioner / Door / Light / Wiper) L14 /proc cluster process scan new File("/proc").listFiles() then <pid>/cmdline filtered on cluster|fission|projection|secondary|surface|display L15 Hidden-API reachability sanity ServiceManager.getService + descriptor on 6 core binders (window, activity, package, display, input, power) All exceptions are caught and reported as FAIL with <ExceptionClass>: <message>; a Throwable catch in the dispatcher ensures one test crashing never breaks the suite. Each test is sub-second on average — the whole 15-test pass completes in ~3 s. 2. Horizontal swipe navigation in Diag With 9 tabs (Cluster / Display / ADB local / Système / ADAS / Beta Engine / DiLink 5 / DiLink 2 / Sniffer) the tab bar is getting long. Build 185 adds a GestureDetector.SimpleOnGestureListener on the diag content frame: Clear horizontal fling (|dx| ≥ 120 px AND |dx| ≥ 1.5×|dy| AND |vx| ≥ 220 px/s) selects the next or previous tab Swipe left → next tab, swipe right → previous tab, clamped to [0, 9) The touch listener returns false so all child scrollers (NestedScrollView, RecyclerView test lists, scrollable SysInfo report) keep working untouched Reuses the existing OnTabSelectedListener (tabs.getTabAt(next).select()) so the same showPanelForTab code path runs — zero regression risk on the existing tab-click flow No animated slide between panels for now (the bascule is dry, like the current tab click); a proper ViewPager2 + FragmentStateAdapter refactor with animated slide is planned for a later build Wiring summary New file dilink2/DiLink2TestRunner.java (~580 LoC, self-contained — no shared types with DL5 / Beta runners) New layout res/layout/include_diag_dilink2.xml New tab TAB_DILINK2 = 7 in DiagActivity.java (Sniffer shifted from 7 → 8); new panelDl2 field; new bindDl2Panel() / prepareDl2TestRows() / bindDl2Row() / runDl2AllTests() / updateDl2Counters() / copyDl2Report() mirror the DL5 lifecycle with their own state lists (dl2RowViews, dl2LastResults) — no state collision with DL5 or Beta New attachSwipeNavigation(View) method called once in bindTabs() New <TabItem> and <include> in res/layout/activity_diag.xml 9 new FR strings in res/values/strings.xml (diag_tab_dilink2, diag_dl2_header_*, diag_dl2_pill_*, diag_dl2_counters_fmt) — the 12 locale files are intentionally NOT updated yet; will batch with the next translation pass once the DL2 panel labels stabilize after field testing Zero production-path changes No changes to ClusterManager, AdbLocalClient, Platform.java, BetaTestRunner, DiLink5TestRunner No new permissions, no new dependencies, no new protocol verbs DL3 and DL5 behaviour is bit-for-bit identical to build 184 DL2 signature detection in bindDl2Panel() is a UI-side hint only (reads Build.BRAND + Build.PRODUCT), no Platform.java extension Build metadata versionCode 184 → 185 versionName pinned "1.2.0" per channel policy Branch: beta/1.2.0-dilink5 (no merge to main) Tag: v1.2.0-build185 APK: DashCast-v1.2.0-debug.apk (14 MB) Validation plan DL2 device — open Diag, swipe (or tap) to the new DiLink 2 tab, confirm the signature pill reads Signature : DL2 détectée, press Lancer tous, wait ~3 s for the 15-test pass, press Envoyer (.log), share the report via Telegram. DL3 / DL5 device (regression check) — open Diag, swipe through all 9 tabs, confirm: No layout glitch, all panels render correctly DiLink 5 panel still functional (run a D1 / D11 / D23 quick sanity) ADAS panel still functional (Show / Hide buttons) Beta Engine panel still functional Sniffer panel still functional (start / snapshot / stop) The DL2 tab is visible too (we did NOT gate it behind a platform detection) — pressing Lancer tous on DL3/DL5 produces a report where L1 reports WARN ("not a DL2 signature") and the other tests still return useful data, confirming the suite is non-destructive on non-DL2 platforms. What this build will tell us about DL2 For the first time, the field report will answer: Whether any non-DisplayManager surface (SurfaceFlinger binder, DRM connectors, /sys/class/graphics) exposes the physically-present cluster screen Which binder services BYD or alps registered on this platform for cluster control What com.byd.cluster and com.byd.appstartmanagement actually contain and expose (entry points, permissions) Which IActivityManager methods are available for typed display routing on API 28 without IActivityTaskManager Whether the ADB-TCP situation can be unblocked from the device side Based on these answers, build 186 will design the actual DL2 cluster projection strategy. LinksAPK download GitHub release page

DashCast v1.2.0-build1841.2.0-build184 — DiLink 5 prerelease Continuation of the beta/1.2.0-dilink5 line. Built on top of build 183, focused on shipping the actionable findings from the first DL5 field log (byd_report_20260522_092905.log). New feature — ADAS quick-toggle diagnostic tab The previously unused Stress test tab is replaced by a dedicated ADAS tab in Diag (tab position #5). Two MaterialButtons wire the universal AutoContainer codes confirmed in clusterdebug v1.6.1.4: Show ADAS → sendInfo(12) (显示Adas) Hide ADAS → sendInfo(13) (关闭Adas) Runtime status pill shows the resolved service name: Auto_container (PascalCase) on DL3 / Di4, auto_container (snake_case) on DL5+. Service-name dispatch resolved per press via Platform.get().isDiLink5(ctx) — toggling the DL5 override in Settings is picked up without restarting Diag. Raw shell response (Parcel hex or error) is displayed in a monospace result card; error path prefixes with ERREUR:. Underlying command: service call <svc> 2 i32 1000 i32 <12|13> s16 "". DiLink 5 test suite polish (based on field-log feedback) D10 — APK extraction cache. Filename already embeds versionCode, so an existing non-empty destination file is now skipped (no cat redirect). New cached counter, log line ↻ <pkg> (cached, NN KB). Summary message reads N APK(s) ready (X cached), Y skipped — adb pull the dir. Second run on the same device produces zero shell calls when no APK version changed. D23 — rewritten as visual warning-lamp cycle. Build 183 looped over binder transaction codes 0..8 for API surface enumeration (redundant after the clusterdebug enumeration). D23 now sends sendInfo(2) (All warning lamps ON), waits 3 s, then sendInfo(3) (All warning lamps OFF). Status WARN with a message asking the user to visually confirm the lamps lit up for ~3 s. End-to-end validation of: (a) snake-case auto_container reaches the cluster on DL5, (b) sendInfo path is functional, (c) cluster Qt honours the published codes. D28 — dropped useless sendInfo(30) step. clusterdebug _Di5 variant has an empty slot at code 30 (was Set screen size on DL3 / Di4, dropped on DL5). New flow: logcat -c → sendInfo(16) (Qt standby ON) → 3 s → dumpsys display → filtered logcat (80 lines) → cleanup sendInfo(18) + sendInfo(0). Documentation New reference file doc_api/APK_com.byd.clusterdebug_CODES.md: full enumeration of com.byd.clusterdebug v1.6.1.4 (versionCode 10601004) sendInfo codes across all three infoListInit* variants (generic for DL3 / Di4, _Di5 for DL5, _R for R-series), side-by-side zh / EN translation for every populated slot. Canonical reference for ADAS panel codes (12/13) and D23 warning-lamp cycle (2/3); audit matrix for platform-stable vs platform-stripped codes. Behavioural contract Production hot path (ClusterManager.sendActivationSequence and full cluster lifecycle) unchanged. ADAS panel uses the existing AdbLocalClient.executeShellWithResult background path — no new thread, no new permission, no new system Context, no new protocol verb. Panel is read-only / write-only with respect to projection state: showing ADAS while projection is running just overlays the warning lamps; hiding ADAS does not affect projection. auto_container production fix (snake_case dispatch on DL5) still deferred pending full clusterdebug + containerservice APK reverse-engineering. Build versionCode 183 → 184, versionName pinned "1.2.0". No new dependencies, drawables (reuses ic_stethoscope), permissions, or protocol verbs. Touched files: DiagActivity.java, dilink5/DiLink5TestRunner.java, res/layout/activity_diag.xml, res/layout/include_diag_adas.xml (new), res/values/strings.xml, app/build.gradle, CHANGELOG.md. Validation plan On a DL3 device: open Diag → ADAS → confirm pill reads Auto_container, press Show ADAS (12) → expect warning lamps lit + Parcel response, press Hide ADAS (13) → expect lamps off. On a DL5 device: confirm pill reads auto_container (snake_case), repeat the cycle. On a DL5 device: Diag → DiLink 5 → run D10 twice → second pass shows all rows as cached; run D23 → confirm visual warning-lamp cycle WARN message; run D28 → confirm the report no longer contains a sendInfo(30) section. Toggle DL5 override in Settings on a DL3 device → reopen Diag → ADAS → confirm pill switches between Auto_container and auto_container and that subsequent button presses use the corresponding service name in the displayed $ command. LinksAPK download GitHub release page

DashCast v1.2.0-build1831.2.0-build183 — DiLink 5 reconnaissance probes (D21–D30) Branch: beta/1.2.0-dilink5 · NOT for merge to main. Prerelease intended for DiLink 5 field testers only. Why this build The first DL5 field log (build 182) revealed three open questions blocking projection: Service name mismatch. auto_container is reachable on DL5 (D11/D12 PASS via explicit snake_case) but our production code path hardcodes AutoContainer (PascalCase, DL3 convention) → all 17+ service call sites fail with Service AutoContainer does not exist. Fix is intentionally DEFERRED until the BYD APKs extracted by D10 are reverse-engineered offline (clusterdebug, containerservice, appstartmanagement, smarttravel, crosscontrol, providers.appstartup, car.server). Display #2 mystery. DL5 has 4 displays vs DL3's 3. Display #2 is not PRESENTATION-typed, holds a single window from PID 1326 / uid 10054 since boot. Is it the native cluster surface, the HUD, the mirror service? Windowing API absent. IATM.setTaskWindowingMode(int,int,boolean) doesn't exist on DL5's API 32 build — BYD either stripped it or renamed it. Build 183 ships 10 new diagnostic probes (D21–D30) designed to answer those questions when combined with the offline APK analysis. No production-path changes — read-only reconnaissance. New tests ID What Why D21 All displays full inventory (DisplayManager + reflective DisplayInfo) Captures non-PRESENTATION displays previously hidden by D2's filter (incl. mystery #2) D22 Display #2 owner identification (dumpsys display + SurfaceFlinger --display-id + ps -A) Identify what PID 1326 actually is D23 auto_container transaction codes scan (codes 0..8) Map the binder API surface beyond sendInfo (code 2) — find hidden capabilities D24 BYD-specific services probe (11 services: magicwindow, crossservice, mirror, BYDMgmt, etc.) Capture each interface descriptor — magicwindow is prime suspect for dual-screen API D25 IActivityTaskManager methods enumeration (reflection, HOT bucket = windowing/display/task) Find the actual replacement for the absent setTaskWindowingMode D26 am start --display N probe on each non-main display (force-includes id 2) Which displays accept arbitrary apps without sendInfo preparation? D27 BYD clusterdebug.MainActivity launch + logcat trace Watch BYD's own cluster diagnostic tool exercise the legitimate projection flow D28 Live logcat capture during sendInfo(30) → sendInfo(16) cycle Capture every BYD log line during a real projection-start attempt (with cleanup) D29 Projection-related intent filters discovery (9 candidate actions + containerservice/appstartmanagement intent-filter dump) Find the official entry-point intent for projection D30 SurfaceFlinger display topology (--display-id + filtered Layer/Display dump) Ground-truth physical/virtual display mapping (bypasses WindowManager filtering) What testers should do Install the OTA or sideload DashCast-v1.2.0-debug.apk manually. Reboot (ensures fresh state — D28 logcat capture is cleaner). Open DashCast → Diag → DiLink 5 → tap Run all → wait for the 30-test pass (~60 s). Tap Copy report → share the .log via Telegram. If you already extracted the 7 APKs from build 182, no need to re-extract — D9/D10 will just re-confirm them. The interesting new data is in D21–D30. What's still pinned versionName stays "1.2.0" (channel policy). Branch stays beta/1.2.0-dilink5 — NOT to merge to main until DL5 projection actually works on a real device. auto_container service-name fix and windowing API fix both intentionally deferred until APK RE + D21–D30 results are combined. Files app/build/outputs/apk/debug/DashCast-v1.2.0-debug.apk (~14 MB) Validation Pure reconnaissance build — no production behaviour change. If everything is broken on your DL3, that's a build regression — please report. LinksAPK download GitHub release page

DashCast v1.2.0-build1821.2.0 — DiLink 5 enablement (prerelease) Pre-release channel. This build lives on beta/1.2.0-dilink5 and is not intended for merge into main. Enable Settings → Include prereleases to receive it over-the-air on a DiLink 3 / DiLink 5 device. Why a major version bump DiLink 5 is a different platform from DiLink 3 — Android 12 (API 32) instead of Android 9, BYD-AUTO brand, and three new system components observed on the first field log (byd_report_20260521_212356.log): auto_container [android.os.IAutoContainer] is still present — our typed Phase4Verbs.autoContainerSendInfo path may work as-is. Display naming is the same shared_fission_bg_XDJAScreenProjection_N family as DL3 — same underlying mechanism. New gatekeepers: com.byd.containerservice v12 (BYD-rebranded XDJA), com.byd.appstartmanagement v1.5.0.0, com.byd.providers.appstartup v12 — these are the suspected behavioural divergence and need offline inspection. To triage this efficiently from the field, the diagnostic surface had to be expanded significantly. Bumping the minor version (1.1 → 1.2) reflects this scope change. What changed RE Sniffer restored (build 181 carry-over) The Sniffer system (continuous logcat + periodic dumpsys snapshots into a single BYD_RE_Sniffer_*.txt on external files dir) was wiped at v0.9.88 (commit 229059c) when DiagActivity was refactored into the tabbed layout. With Dilink 5 testers now in the loop, we need the Sniffer back to bind user-reported issues to ground truth. Restored as a dedicated Material 3 tab (8th tab in DiagActivity). State machine ported 1:1 from the pre-wipe revision, so Start / Stop / Snapshot / Export and crash-safe state restoration on Activity rebuild all behave exactly as before. DiLink 5 diagnostic suite — 9 → 20 tests D9 — reworked, now dynamic. Replaces the 7-package hardcoded whitelist with a shell scan: pm list packages -f | grep -iE 'com\.byd\.|com\.xdja\.|com\.dilink\.|cluster|automotive' | sort -u. Parses every match (package:/data/app/.../base.apk=<pkg>), reads versionName + getLongVersionCode() via PackageManager, and stores the result in a static sLastDiscovery list for the next test. Output now shows the full APK path for every match. D10 — RE-relevant APK extraction. Iterates sLastDiscovery, filters through a curated whitelist (clusterdebug, car.server, crosscontrol, containerservice, xdja.containerservice, appstartmanagement, providers.appstartup, smarttravel, commander, freedom, overdrive, windowmanagement, plus any package containing fission / projection / cluster / dilink5 / automotive.cluster), and cats each APK from /data/app/... to getExternalFilesDir(null)/extracted_apks/<pkg>_v<versionCode>.apk via the existing ADB-local shell relay. The report card prints the exact adb pull command to retrieve everything in one shot. D11 — AutoContainer sendInfo refresh probe. service call auto_container 2 i32 1000 i32 0 s16 "" (the harmless sendInfo(0) refresh already used in our restoreBydOnCluster sequence). PASS = service accepted from uid 2000 (confirms our typed Phase 4c path will work on DL5 without modification). D12 — Qt standby cycle probe. Active 3-step sequence sendInfo(16) (Qt standby) → 1.5 s → sendInfo(18) (close) → 0.5 s → sendInfo(0) (refresh). Validates the protocol cycle, not just binder reachability. No projection actually started — these three commands together form a complete null cycle. D13 — IATM.setTaskWindowingMode reflection probe. Resolves android.app.ActivityTaskManager.getService() then reflective setTaskWindowingMode(0, 4, true). Disambiguates the D6 FAIL line: SecurityException → WARN (expected, signature perm or proxy daemon needed); IllegalArgumentException → PASS (method is reachable, only rejected the bogus taskId — best case); NoSuchMethodException → FAIL. D14 — Window manager state dump. dumpsys window | grep -E 'Display #|mDisplayId|imeLayerStack|focused|mStackId|mCurrentFocus|mDisplayContent' | head -80. D15 — com.byd.appstartmanagement inspection. dumpsys package filtered to permission/receiver/service/activity/authority/provider/signature/version. This is the suspected DL5 launch gatekeeper. D16 — com.byd.containerservice inspection. Same filter for the BYD-rebranded XDJA. Will reveal whether transaction codes match the legacy com.xdja.containerservice we already have decompiled. D17 — Proxy daemon spawn capability. id + which app_process64 + dry-run app_process64 -Xnoimage-dex2oat /system/bin --nice-name=dl5_probe -version + ls /system/bin/app_process64. PASS = our Beta proxy daemon strategy is viable on DL5/API 32 (no SELinux denial). D18 — SELinux context. id + ps -Z -o LABEL,USER,PID,NAME | head -10. D19 — Full system services inventory. service list | grep -iE 'auto|byd|cluster|fission|display|window|projection|crosscontrol|xdja|task' | head -60 — broader than D3. D20 — IActivityTaskManager service presence. service list | grep -iE 'activity_task|activitytask'. Versioning versionName 1.1.9 → 1.2.0 versionCode 181 → 182 Validation plan Install the APK below (or enable Settings → Include prereleases for OTA delivery). Open Diag → DiLink 5 tab → tap Run all. Copy the report with the Copy button. From a PC: adb pull /sdcard/Android/data/com.byd.dashcast/files/extracted_apks/ — retrieves every whitelisted BYD/XDJA/DiLink APK for offline jadx work. Expected outcomes D9 → PASS with 10–20 packages discovered. D10 → PASS, all whitelisted APKs copied to extracted_apks/. D11 / D12 → key signal for whether our typed sendInfo path already works on DL5. D13–D20 → triage data for the next iteration. Files DashCast-v1.2.0-debug.apk — debug-signed APK, attaches below. Compatibility Min SDK 28, target SDK 29, compile SDK 33 — unchanged. No new runtime permissions, no new dependencies, no new resources beyond the Sniffer panel layout. Branch policy This release lives on beta/1.2.0-dilink5. It is not merged into main. The stable channel remains 1.0.1. LinksAPK download GitHub release page

DashCast v1.1.9-build179DashCast v1.1.9 — build 179 (Beta Engine Phase 5) Channel: beta/1.1.0 • versionCode: 179 • versionName: 1.1.9 • target: BYD Atto3 / Seal EU, DiLink 3.0, API 29 Phase 5 — proxy daemon pre-warm at BOOT_COMPLETED Kills the cold-start cost paid by the first user action after every reboot. Build-178 device log measured the very first sendInfo of a fresh session at 1916 ms, versus 3 ms warm. That 1.9 s was entirely the BetaProxyClient.connect() bootstrap: spawning app_process with our APK on the classpath, waiting for the daemon to broadcast its live binder, running the WHOAMI handshake. Build 178 already validated that the runtime cost is paid once per daemon lifetime, so moving the bootstrap to BOOT means every subsequent in-app trigger is warm. What changed 1. BootReceiver refactor. The existing BOOT_COMPLETED receiver already handled two cases (auto-start projection ON → start ClusterService; OFF → run cleanupDisplayAffinityAtBoot via goAsync()). Phase 5 adds a third orthogonal task: if BetaConfig.isProxyDaemonEnabled(context) is true, spawn beta-daemon-prewarm thread that calls BetaProxyClient.connect(appCtx). Since BroadcastReceiver.PendingResult.finish() may only be called once, the previous single-task goAsync() pattern doesn't scale to two concurrent tasks (pre-warm + display cleanup) — refactored into a shared AtomicInteger pending + releaseOne lambda that finishes the receiver only after the last task completes. The pre-warm thread name is beta-daemon-prewarm (visible in any thread dump for diagnostics). 2. Logging on the boot path. Two new log lines surface the pre-warm outcome: beta daemon pre-warm starting... at thread start beta daemon pre-warm ok (XXms) / beta daemon pre-warm FAILED (XXms) once connect() returns Expected XX is ~1500-2000 ms on the BYD Seal EU (matches the cold cost previously paid by the user). On failure the log line is beta daemon pre-warm threw: <msg> and Phase 5 silently degrades — runtime fallback in ShellGateway / AdbLocalClient still routes through legacy shell on demand, so the user's first action just pays the cold cost as before. 3. Threading correctness. The pre-warm runs on its own background thread (not the receiver thread that delivers the broadcast — that one returns immediately so the OS can move on with system boot). BetaProxyClient.connect() is internally synchronized on LOCK and is safe to call concurrently with future in-app calls from MainActivity.onCreate etc. — if the user opens the app while pre-warm is still in flight, the in-app connect() will block on the same LOCK, see the now-cached binder on entry, and return immediately. 4. Idempotent against double-trigger. BetaProxyClient.connect()'s fast-path explicitly checks isConnected() first and skips the bootstrap if a live binder is already cached (this was the v1.1.6 anti-respawn fix), so a pre-warm followed by a MainActivity.onCreate() connect is harmless — second call is a no-op. 5. Receiver-lifetime safety. PendingResult.finish() must be called eventually or Android logs a leak. The new AtomicInteger-based coordinator guarantees finish is called exactly once, on the completion of whichever task finishes last (pre-warm + cleanup typical max ~3 s). If BetaConfig.isProxyDaemonEnabled(context) returns false AND autoStartEnabled is true, pending stays at zero and finish is invoked immediately — covers the edge case where the receiver has no asynchronous work to do. 6. Permissions / manifest. No change. RECEIVE_BOOT_COMPLETED was already granted (build-178 SigDump confirms granted=true); the <receiver> declaration with the BOOT_COMPLETED action filter is unchanged from build 178. 7. Behavioural contract preserved. When the beta proxy toggle is OFF, the new if (BetaConfig.isProxyDaemonEnabled(context)) branch is skipped entirely — no extra thread, no daemon bootstrap, identical boot behaviour to v1.0.1. The existing auto-start projection path is unchanged in terms of order: startForegroundService runs synchronously on the receiver thread as before; only the cleanup branch lost its dedicated goAsync() (it's now sharing the receiver's single PendingResult). 8. What's left. Phase 5 closes the cold-start hole exposed by Phase 4c/4d logs. Toggling the proxy ON at runtime (via Settings) still requires the user to pay the cold cost on the first call — by design, since the toggle change is rare and the UI already labels it "restart required after change". A future micro-polish could trigger BetaProxyClient.connect(ctx) in the toggle handler too, but it's a deliberate non-scope of Phase 5 (boot is the dominant cold-start surface). How to validate Install the APK over build 178. Reboot the head unit. Open the in-app Diag screen → look at the head of the captured log for: BootReceiver | beta daemon pre-warm starting... BootReceiver | beta daemon pre-warm ok (~1500–2000 ms) Trigger a normal projection start (or restoreBydOnCluster). The first BetaProxyClient.sendInfo should now be warm (~3 ms) instead of the 1916 ms measured in build 178. Build metadata versionCode 178 → 179 versionName pinned at "1.1.9" per channel policy Sole touched files outside CHANGELOG/gradle: BootReceiver.java No new strings, layouts, drawables, or dependencies Roadmap context Phase 4 (typed verbs replacing shell forks on production hot paths) closed in build 178 with all four verbs live: setOverscan (4a), getPidsByPackage (4b), autoContainerSendInfo (4c), forceStopPackage (4d). Build 178 device validation: 56/56 tests PASS, restoreBydOnCluster typed ok (1578 ms), restoreOriginCluster typed ok (12012 ms). Phase 5 builds on that by removing the only remaining latency wart — the per-reboot daemon bootstrap. LinksAPK download GitHub release page

DashCast v1.1.9-build180DashCast v1.1.9 — build 180 (Phase 4d.1 — force-stop fix) Channel: beta/1.1.0 • versionCode: 180 • versionName: 1.1.9 • target: BYD Atto3 / Seal EU, DiLink 3.0, API 29 Bug fixed Build 179 field test surfaced: when the user tapped Restore BYD cluster with Waze projected, the app correctly migrated to display 0 (moveSessionAppsToMainDisplay works) but the Waze process kept running. The device log reported beta restoreBydOnCluster typed ok (Xms) — a lie: the underlying IActivityManager.forceStopPackage(pkg, -1) returned cleanly but did not actually terminate the target. Root cause BetaProxyClient.forceStopPackage(targetPackage, -1) was passing userId = -1 (UserHandle.USER_ALL). On API 29 BYD framework, the IActivityManager implementation silently no-ops on negative user IDs instead of throwing — the caller has no way to know the kill failed. Legacy shell path (am force-stop pkg without --user) targets the current user implicitly, which is why pre-Phase-4d builds did not exhibit this. What changed 1. userId fix in AdbLocalClient — both restoreBydOnCluster and restoreOriginCluster now pass userId = 0 (current user) instead of -1. The teardown report shown in the UI now reads force-stop <pkg> (typed,u=0) to make the user-id explicit. 2. Post-kill verification (verifyForceStop helper). After every typed forceStopPackage on the teardown hot path, the client now calls BetaProxyClient.getPidsByPackage(pkg) (Phase 4b verb already shipping since build 175) and: if no surviving PIDs → log nothing extra, report shows verified killed if PIDs survive → log WARN beta force-stop ineffective for <pkg> (pids=...) and append WARN: still alive, pids=… to the UI report Future force-stop failures will surface immediately in device logs instead of silently lying about success. 3. Defensive failure mode. Verification exceptions are swallowed (logged at WARN) so the teardown sequence is never broken by a diagnostic helper. Out of scope (deferred) forceStopApp(Context, String) (the in-list "✕" button) is unchanged — it's a shell-only legacy path running am force-stop directly with no userId issue, and includes its own am task remove Recents cleanup. Process.killProcess(pid) as a third escalation tier was considered and explicitly deferred. We want to see whether userId=0 alone is sufficient before adding more retry layers. Wire / protocol No change. TXN_FORCE_STOP_PACKAGE (=8) and TXN_GET_PIDS (=6) were both shipped in builds 178/175 respectively. Phase 4d.1 is a pure client-side correctness fix. PROTOCOL_VERSION stays "2". Behavioural contract preserved With the beta proxy toggle OFF, BetaConfig.isProxyDaemonEnabled(context) short-circuits before any binder touch — boot/runtime behaviour identical to v1.0.1. The legacy shell fallback inside restoreBydOnCluster / restoreOriginCluster (used when the typed path throws) is unchanged. How to validate Install over build 179, reboot. Project an app (Waze ideally) on the cluster. Tap Restore BYD cluster. In Diag → log, check for: force-stop <pkg> (typed,u=0) followed by verified killed the app is no longer running on display 0 (launcher returns to idle, not the freshly-relocated app) If WARN beta force-stop ineffective for <pkg> (pids=…) appears → capture the log; userId=0 alone wasn't enough and we need to investigate BYD framework re-launch behaviour. Build metadata versionCode 179 → 180, versionName pinned at "1.1.9" Sole touched file outside CHANGELOG/gradle: AdbLocalClient.java No new strings, layouts, drawables, dependencies, or protocol verbs Stack of fixes in this beta channel build 178 — Phase 4d (typed teardown sequence) + SDK B4/B5/B6 rewire build 179 — Phase 5 (daemon pre-warm at BOOT_COMPLETED) build 180 — Phase 4d.1 (force-stop userId fix + post-kill verify) LinksAPK download GitHub release page