CarDeck 0.1.12

0.1.12

修复：部分华为手机（EMUI 12）仪表盘没有地图

EMUI 对 shell 侧虚拟屏创建会静默失败（不报错、直接返回空），此时 CarDeck 回退到应用侧虚拟屏模式——但回退模式此前不创建地图屏，仪表盘永远没有地图卡片。

• 回退模式现在同样创建地图屏，仪表盘地图 tile 恢复
• 受信屏创建失败时逐屏记录日志（此前只剩「回退」两个字，无法定位）
• 分屏/全屏切换在回退模式下改用应用侧接口（此前静默失效）

建议华为/EMUI 用户升级（首次实测反馈来自 Mate 30 Pro + 吉利车机；顺带包含 0.1.10/0.1.11 的 plist 修复与宝马 iD9 支持）。

---

• APK SHA-256：a7d1bac8b9fc01eab560898b0a98377ebb536dc13bc9ab8e81474c6a9d0f99d2
• 签名证书 SHA-256：9457d04d2709094404a534ba06d7ecbc53cb1406224ec7c53c05a9c67ccc4970（CN=CarDeck, O=shaonialife）

CarDeck 0.1.11

0.1.11

新增：宝马 iD9 支持

来自社区 PR #10（感谢 @rja-1998），在 BMW iD9 车机（BMW92438）实测调到画面 + 触摸 + 音频全通：

• 两代 WiFi 协议自动分派：iD9 走新协议——识别帧（0x1D01）里不声明 0x5702/0x5703，热点信息由 0x4301 自带；旧代码在新协议车机上对 0x5703 死等 10 秒每轮拆链。现在按车机声明的收/发能力清单分派，0x5703 等待降级为非致命（到不了自动转 0x4300/0x4301 路径）
• plist 解析再修两处：UID 长度改由 marker 决定（此前错用对象引用宽度，refSize>1 时对象指针读歪）；新增容错解析——报文在 Content-Length 之外带尾随字节时裁尾重试
• forceKeyFrame 立即响应：车机解不出画面请求关键帧时立即编 I 帧，不再等下一个周期帧（此前可能一直卡在等帧状态，表现为「连上了但没画面」）
• 可观测性：/info 失败不再静默（带旁路连接复探）、displayUuid 兼容 16 字节 UUID/UID、未识别命令带全参数、未命名 CSM 带全量 hex——失败路径从「静默」变「可诊断」

已知问题

• 60fps 档在链路/GPU 余量不足时可能出现画面冻结（推流在独立线程，非 ANR；自动降档保护在下一个版本）

---

• APK SHA-256：a01c1a81e5f071b43f00b6a1b18c04513f7f4c399f3effd57de43a8b84f45d40
• 签名证书 SHA-256：9457d04d2709094404a534ba06d7ecbc53cb1406224ec7c53c05a9c67ccc4970（CN=CarDeck, O=shaonialife）

CarDeck 0.1.10

0.1.10

新增：本田 HFT（十一代雅阁）支持

来自社区 PR #9（感谢 @ml2483343808-hue），在该车型实测打通：

• 音频走 AAC-LC 通路：本田车机的媒体音频档只声明 AAC-LC 44.1k（type=102），推 PCM 时收包不消费、约 6.5 秒拆会话——新增 MediaCodec AAC-LC 编码通路，音频档位按车机持久化记忆（AudioProfileMemory）
• 方向盘媒体键：HID 报告补上「位图（Variable）」语义（此前只支持 Array 下标语义，位图报告一个键都点不出来）
• bplist 整数按无符号解析：采样率 44100 曾被读成 -21436，符号扩展还会污染音频格式位图协商
• 事件通道握手升级：车机只发探测 marker、迟迟不回 SYN 时，自动升级为主动发起握手（marker + 会话表）
• 隧道身份收发清单解析：连接日志直接列出车机支持收/发的消息类型，判断车型能力不再靠猜

修复：≥128 字节的命令整条被当「无法识别」丢弃

bplist 扩展长度字段被按有符号解读——DiPlay 下发 NowPlaying 订阅（0x5000，data 182 字节）时长度 0xB6 被读成 -74，整条命令丢失。与上一条整数负号扩展是同族问题，一个在数值路径、一个在长度路径。

加固与优化

• 事件通道命令解析异常不再可能杀死读线程（此前畸形报文可致触摸/保活全丢、会话随后被拆）；无法识别命令的十六进制留痕 16B → 96B，便于离线定位
• 自动模式下只对确认提供 iAP2 服务的设备断开蓝牙音频（经 SDP 探测）——耳机/手表不再被误伤；选定目标车机时行为不变

---

• APK SHA-256：43a6beaee33af868dc879ab0a08d1a3013aed2cb7717a0b04e8e2b71781d997b
• 签名证书 SHA-256：9457d04d2709094404a534ba06d7ecbc53cb1406224ec7c53c05a9c67ccc4970（CN=CarDeck, O=shaonialife）

CarDeck 0.1.9

0.1.9

修复：奥迪 MIB3「连上约 10 秒被整链拆除」

AirPlay 会话建立后，车机还要求手机在事件通道上建立**第二条 iAP2 链路（WiFi 隧道）**并重跑完整控制会话——此前只回链路 ACK，车机等满 ~10 秒判定无线栈失败后整链拆除（推流/心跳全部正常也无济于事，极易误判为网络或心跳问题）。

• 屏幕流 SETUP 成功后主动经控制通道发一次 DETECT → 车机 SYN → SYN|ACK → 识别/认证/突发消息/订阅应答，时序对照越狱 iPhone 的 Frida 真机抓包（感谢 AADisplay 的协议参考）
• 链路引擎四处修正（发起方对 SYN|ACK 的采纳与有序水位、响应方回显即完成、SYN|ACK 声明自己的发送窗口 0x7F）
• MFi 挑战长度在隧道侧同样按车机持久化记忆（与蓝牙链路独立），首次自动试出后永久生效
• 订阅应答为仪表盘媒体/歌词数据通路打了地基（后续版本接媒体卡数据源）

修复：会话断开后暗幕仍会自动弹出

自动暗幕此前在应用启动时排程，车机侧主动断开不经过会话退役路径，导致「会话已断、过一会儿手机仍变暗」。现在暗幕严格由会话生命周期驱动。

---

• APK SHA-256：c0da3846414d13700f0de271ed8dae329f91ede9702c0c9bbfcfa064395a0a50
• 签名证书 SHA-256：9457d04d2709094404a534ba06d7ecbc53cb1406224ec7c53c05a9c67ccc4970（CN=CarDeck, O=shaonialife）

CarDeck 0.1.8 — 修复 0.1.7 在奥迪车机连不上

本次更新

修复：0.1.7 在部分奥迪车机上"连不上"（车机不启动 CarPlay 窗口）

这是 0.1.7 引入的回归，建议所有 0.1.7 用户升级。

同一台 Audi MMI 3315、同一部手机：0.1.6 能正常连接，0.1.7 出现
「iAP2 全部走通、车机却始终不开 AirPlay 窗口」——0x4301 启动会话、车机的
ctrl-int 探测、mDNS _airplay._tcp 三项全为零，兜底连网关 7000 端口持续
Connection refused，而车机在 iAP2 层仍在正常发消息。

根因：0.1.7 把手机侧 ctrl 广播的 TXT srcvers 从 950.7.1 改成 566.25.21、
服务实例名从 sender 改成 iPhone（对齐参考实现），车机因此连发现探测都不再发起。
这两个字段是车机在 WiFi 上唯一能看到的"这是哪台手机"，改掉等于换了台设备。
现已回退到 0.1.6 的实测值。

其他修复

• 真实蓝牙 MAC 解析：会话启动时强制重新解析。此前在 Shizuku 刚就绪的瞬间
  首次解析失败后，10 秒内都会回落到占位地址 02:00:00:00:00:00，而车机会拿它
  与蓝牙连接的对端核对，占位值被静默丢弃。
• 移除 _device-info._tcp 广播：Android 的 NsdServiceInfo 不接受端口 0，
  每次注册都必然失败，属无收益噪音。
• 兜底期持续重新公告：等不到车机邀请时会周期性重播 ctrl 广播，并在日志里
  记录"车机邀请次数 + mDNS 是否发现"，便于排查。
• 诊断日志补全：ctrl 广播注册时打印 name / id / srcvers；BT 会话打印解析到的
  本机蓝牙 MAC。

上一版本（0.1.7）已包含但本次一并生效的内容

• 修复车机黑屏：屏幕流 VideoConfig 帧头补齐「加密标志 + 画布宽高」
  （此前 app 显示已连接、车机屏全黑）。
• 修复 iAP2 链路协商卡死：SYN-ACK 改用新序号、每条 SYN 都回 SYN|ACK
  （此前部分车机 14 轮会话全部卡在链路层）。
• 老车机（CarPlay 210.81 / 奥迪 4xxx）兼容：bplist 根对象置首、et=NONE 明文
  会话 + AES-128-CTR、控制帧 MTU 对齐、IPv6 地址支持等。

安装说明

• 直接覆盖安装（与之前版本同一签名）。首次使用需完成 Shizuku 授权。
• 从 0.1.6 诊断到问题再回到 0.1.8 的用户，无需任何额外操作。

升级后自查

连接后日志里应能看到：

CTRL: 已监听 :xxxxx，广播 _carplay-ctrl._tcp name=sender id=<真实蓝牙MAC> srcvers=950.7.1
BT: 本机蓝牙 MAC=<真实蓝牙MAC>（0x4300/0x4E0E 与 ctrl 广播 TXT id 同源）

若 id= 仍显示 02:00:00:00:00:00 并带 ⚠ 标记，说明 Shizuku 的 MAC 解析尚未打通，
请检查 Shizuku 是否已启动并授权。

校验

• 版本：0.1.8（versionCode 108）
• SHA-256：eb4e27f2ab3f0e01377f0f50d27086bc717c542de7403d4f76c4afc5e9a3523a
• 签名证书 SHA-256：9457D04D2709094404A534BA06D7ECBC53CB1406224EC7C53C05A9C67CCC4970
  （CN=CarDeck, O=shaonialife）

CarDeck 0.1.7 — 修复车机黑屏与老车机连接

本次更新

修复：车机屏黑屏（app 显示已连接、车机没反应）

根据车友提供的奥迪 4851（Audi_MMI_3315 / AUDI 5163 / DELPHI）实车日志定位：
配对、会话建立、视频推流、触摸回传全部正常，但车机屏幕全黑、日志无任何错误。

根因是屏幕流 VideoConfig 帧头缺少两个字段（对照 catplay ScreenFrame::config）：

字段	偏移	值	缺失后果
small_param[1]	6	Encrypted (0x04)	后续加密帧被当明文 NAL 解析 → 解码失败
params[1]	16	宽、高两个 f32 LE	车机无法建立解码器画布
params[0]	8..16	0（config 不带 PTS）	—

测试台（DiPlay / WinPlay）只读 body 与 avcC、不校验这些头字段，因此长期未暴露。

若你之前用的是 0.1.4 及更早版本，还叠加了「约 10 秒自动断开」问题（缺屏幕流
keepAlive 帧 + UDP 心跳与车机看门狗等长），该问题已在 0.1.6 修复。

修复：老车机（CarPlay 210.81 / 奥迪 4xxx 固件）连不上

六处与 catplay 发送端不一致的地方，均已对齐：

1. bplist 根对象必须在字节 8 —— CarPlay 210.81 不读 trailer 的 topObject，
   直接按偏移 8 取根；我们的编码器默认根在末尾 → 车机解析不出 SETUP 字典。
2. 初始 SETUP 改用相对 URI /setup。
3. 未配对会话显式带 et=1（NONE），屏幕流走 AES-128-CTR + 全零会话密钥
   （密钥流跨帧连续），事件通道明文。
4. 控制密文帧 MTU 对齐 1440 → 单帧明文上限 1422（旧值会被严格车机判协议违规）。
5. 用 _airplay._tcp 的 features 位图（bit38 HK_PAIRING_AND_ENCRYPT）识别车机
   年代：未声明即判 pre-HomeKit，跳过注定失败的 120s 配对窗口，直接走明文会话；
   TXT 缺失/解析失败按「未知」保留旧路径，不会误降级。
6. 不再用「是否含点号」判断有没有地址：奥迪 4xxx 常只发 IPv6 链路本地地址。
   现统一按 IPv4 → 全局 IPv6 → 链路本地 IPv6 排序，并让视频/音频/事件通道复用
   配对时真正连通的地址。另修正 mDNS 结果的网段过滤（原先只认 IPv4）。
   日志新增「端点诊断」一行，直接显示地址类型与配对能力声明。

其他

• ctrl 广播 TXT srcvers 改为发送端版本（此前误写车机侧版本）、服务名 iPhone；
  补发 _device-info._tcp；GET /info 带空 bplist 字典体 + plist Content-Type。
• 重连时重置控制通道加密状态（否则新连接的明文应答会被当密文解）。
• VideoConfig 日志新增 flags 与头部前 24 字节 hex，便于反馈定位。

安装说明

• 直接覆盖安装即可（与之前版本同一签名）。首次使用需完成 Shizuku 授权。
• 从任何 0.1.6 之前的版本升级后建议断开重连一次。

已知情况

• 本次针对 4851 的修复尚未收到实车复测反馈。若仍黑屏，请导出日志
  （应用内「日志导出」），重点看 VIDEO: ✓ VideoConfig 已发送 … flags= 及其下一行
  头部 hex。
• 音频通道在「未配对（明文）会话」下会自动跳过（无共享密钥可派生流密钥）。

校验

• 版本：0.1.7（versionCode 107）
• SHA-256：b8fff924dc063aa14379456830555c9b063fe50ac617fdf6dbd09a19ff8ff29a
• 签名证书 SHA-256：9457D04D2709094404A534BA06D7ECBC53CB1406224EC7C53C05A9C67CCC4970
  （CN=CarDeck, O=shaonialife）

CarDeck 0.1.0 — 首个公开版本

CarDeck 0.1.0 — 首个公开版本

让一台未 root 的 Android 手机扮演 CarPlay 发送端（iPhone 角色），
自绘车机桌面 + 推流到车机，车机触摸回注到手机侧虚拟屏。

⚠️ 非官方项目：与 Apple Inc. 及任何汽车厂商无关联，未获授权或认证，不是 MFi 产品。
CarPlay / AirPlay 是 Apple Inc. 的商标，仅用于说明兼容目标。
⚠️ 驾驶安全：仅限停车时配置；行驶中断连可能导致导航中断，请以原厂导航为安全冗余。
完整条款见 DISCLAIMER.md。

安装前请确认

• Android 14+（SDK 34）：应用横屏 功能依赖平台 ChangeId，Android 13 及更早不可用
• 需要安装并启动 Shizuku（无线调试激活，免 root）
• 首次启动会显示免责声明，需阅读到底并等待 10 秒后才能接受

已测试范围

角色	设备
发送端	荣耀 Magic7 Pro（Android 17）
接收端	奥迪 MIB3 车机（真车）
接收端	Redmi K40 上的 DiPlay 测试台（Android 13）

其他手机 / Android 版本 / 车型均未验证，可能无法工作。

本版功能

• 蓝牙 iAP2 → 车机热点 → mDNS → AirPlay 完整发送端链路（配对/控制/事件/流）
• 隐形屏启动器：dock + 应用网格 + 地图屏，第三方应用跑在受信虚拟屏上
• 车机触摸经 Shizuku 回注虚拟屏（含仪表盘地图卡点按全屏）
• H.264 视频推流 + 可选音频通道（需投屏授权）
• 强制应用横屏（Android 14+），未生效时在黑边给出提示卡并支持一键重启
• 音乐卡片（通知使用权 → 媒体会话），播放位置锚点外推
• 常亮 + 暗幕（替代息屏）、车机壁纸、默认地图选择
• 首页横屏双栏（英雄卡固定左栏）
• 免责声明（首次强制阅读，底部可随时重看）

安装

1. 下载下方 CarDeck-0.1.0.apk
2. 允许「安装未知来源应用」
3. 安装后先启动 Shizuku 并授权本应用
4. 打开 CarDeck，接受免责声明，按「连接准备」逐项完成

校验（可选）：

SHA-256: d65c374f711fb92f6de26754bc15f466d9593a616a86f29887a9e95c969fa6b0

签名指纹（SHA-256）：9457d04d2709094404a534ba06d7ecbc53cb1406224ec7c53c05a9c67ccc4970

本 APK 由正式 release 密钥签名。后续版本沿用同一密钥，可直接覆盖升级。