企业官网建设流程全解析

• 移动开发
• 智能硬件
• 音视频

本文基于 DiPlay 仓库的docs/COMPATIBILITY.md及其交叉引用的配套文档，系统梳理这套独立 CarPlay 接收端的官方兼容边界：哪些车机（Android/DiLink 版本）与手机组合被验证过、哪些只是社区报告，Wi-Fi 热点 / Wi-Fi Direct / Existing Wi-Fi 三种无线传输各自的适用前提，Android 9 遗留路径与 Android 10+ 的差别，以及 Smooth video、通话回声消除等实验功能默认关闭的原因与启用代价。读完你能准确判断自己车辆是否处于“已验证 / 实验 / 未验证”哪一档，知道该去哪里看源码佐证，以及出现问题时如何按官方流程产出可追溯的诊断报告。

一、先明确定位：独立接收端，不是 Apple 认证配件

DiPlay 的公开预览版（public preview）是一个独立实现的 CarPlay 接收端，并非 Apple 认证的 CarPlay 配件。这一点直接决定了整个兼容性文档的措辞方式：

• 内置的实验性配件身份（accessory identity）是可提取的，Apple 未来是否接受它没有任何保证；
• 文档中所有“支持”表述都只是对测试证据的汇总，不构成认证的支持列表；
• 社区（BYD 各代 DiLink 车机）反馈是好坏参半的，不能把某一代的结论外推到整代车型。

原文档给出的 0.2.14 版本证据边界也值得强调：该版本的“验证”来自自动化源码/构建校验与带署名的贡献者测试，没有新增的完整发布车辆实测；更早的 DiLink 5.1 HUD/热点结果只是历史证据，不能作为当前版本的保证。

二、官方兼容性矩阵

下表完整继承自docs/COMPATIBILITY.md，是判断设备组合的第一手依据：

矩阵里几个关键约束值得展开：

• “Android 7.1+”是 APK 声明下限，不等于全功能下限。7.x 缺少 local-only hotspot 能力，无线链路必须退化为车机热点、Wi-Fi Direct 或 Existing Wi-Fi 之一；7.1–8.1 区间甚至还没有实车确认。
• Wi-Fi Direct 是“两段式”兼容：Android 7.1–9 走遗留 API，申请频率无法验证（诊断里会标记为 unverified）；Android 10+ 才能验证组内实际工作频率。
• 视频编码默认保守：H.264/30fps 是基线，HEVC 属于可选开关——源码中 HEVC 的持久化键hevc_enabled默认值为false（见 AirPlayPersistence.kt 第 157 行.getBoolean(KEY_HEVC_ENABLED, false)），与“60 fps 和 HEVC 提高设备特定要求”的兼容性表述一致：开启后能否解码取决于车机，官方不做保证。

三、BYD HUD 与车机热点：历史证据与当前端点策略

原文档对 BYD HUD 与车机热点（car hotspot）的表述非常克制：

• 更早期、基于车机热点的构建，在开发车上使用**带作用域的 IPv6（scoped IPv6）**启动了 CarPlay；
• 当前的 AP 端点发现优先使用可用的 IPv4，同时保留 scoped IPv6 作为回退；
• 手机必须加入配置好的车机热点；以上任何一条结果都不保证覆盖所有固件。

精确的已验证固件清单与生命周期限制被委托给 BYD navigation 文档，其中记录了在 DiLink 5.1 / Android 13 特定固件（BYD-AUTO/IVI/IVI:13/TP1A.220624.014/...）上的实车验证结果，以及 standalone HUD 输出被限制在该固件与已验证的 stock receiver 版本上的原因。仓库中热点端点相关实现集中在 network 包（如CarHotspotTethering.kt、Ipv6NcmBridge.kt、HotspotAddressPolicy.kt等），可以看到 IPv4 优先 + IPv6 回退的地址策略是有专门实现与测试（LocalOnlyHotspotManagerTest.kt、WifiP2pGroupManagerTest.kt等）支撑的。

四、Android 9 Wi-Fi Direct 遗留路径：机制、串行化与“不可信就回退”

Android 9 路径是兼容性文档中最技术化的一段，完整机制如下（详见 Android 9 Wi-Fi Direct 文档）：

1. 使用公开的WifiP2pManager.createGroup双参重载创建或复用一个持久化系统配置（persistent system profile），再从requestGroupInfo读取系统生成的凭据。这与 Android 10 的配置重载不同——Android 9 是让框架维护组主配置文件；
2. DiPlay 关闭时只移除自己持有的活动组，绝不删除框架或别的应用的持久化 profile；
3. 隐藏的setWifiP2pChannelsAPI 会修改 supplicant 的共享工作频率限制，DiPlay 只在确认没有外部活动组之后才调用，并且串行化了 pinning/取消操作，避免误伤外来的组，只清理自己拥有的活动组；
4. 任何未知结果的 setter 响应都会停止启动流程，不重试、不创建组；补偿指令走同一回调通道发送，保证 Android 9 服务按顺序处理“选择 + 复位”；
5. Android 9 不暴露组协商后的实际频率：诊断报告里记录的是“被接受申请”并标记 unverified，系统默认模式报告为 channel 0；Android 10+ 则继续验证实际组频率；
6. 结论性建议：信道 setter 或清理行为不可靠的固件，应改用手动车机热点（manual car hotspot）。

文档同时给出证据边界：贡献者 Redmi K20 Pro / iPhone 的结果只验证了基本拉起（basic bring-up），自动化测试覆盖默认重试、关闭、迟到回调、外来替换与清理失败等场景；BYD Android 9 的取消/清理接受度没有被该评审实际跑过。相关实现可在 WifiP2pLegacyChannels.kt 与 WifiP2pChannels.kt 中查阅，对应的回归测试见 WifiP2pLegacyGroupManagerTest.kt、CarPlayBonjourDualStackTest.kt 等。

五、实验功能与 opt-in 限制：默认关闭的三条线

0.2.14 中有一组“相互独立、默认全部关闭”的实验功能，兼容性文档对其边界表述得相当清楚：

源码层面可以对上：smooth_video、hevc_enabled等键全部持久化在 AirPlayPersistence.kt；CarPlayHostActivity.kt 第 3860 行videoPacingDelayMillis = if (smoothVideo) smoothVideoDelayMillis(fps) else 0正是“自适应 pacing 延迟”的注入点；第 4715 行carPlayVideoSurfaceMode(texture.isHardwareAccelerated, smoothVideo)与 CarPlayVideoSurface.kt 中hardwareAccelerated && !smoothVideo ? TEXTURE : SURFACE的判定，印证了“Smooth video 走 SurfaceView 路径且画面调节不可用”的文档表述。

另外两条兼容性文档单独点名的边界：

• DiLink 4 casting/picture 修复只描述 2022 款 Seal 的测试设置，不是 Qin/Seal 全系保证；
• **Android 13+ 热点加入助手（hotspot join helper）**要求严格的前置门槛：用户配置、5 GHz、API 级别、ADB 四道关卡加显式确认，全部满足才会生效。

六、Setup 向导：从系统构建名识别 DiLink 世代

首次启动且没有已保存的 iPhone 时，DiPlay 会打开Setup guide（可跳过，之后从Settings → Overview重新打开）。它的行为在源码里能一一对应：

• 读取 DiLink 世代：解析系统构建名（如DiLink3.0）。DiLinkGeneration.kt 第 19 行的正则DiLink\s*([345])(?:\.\d+)?依次匹配Build.PRODUCT、Build.FINGERPRINT、Build.DISPLAY；对 DiLink 5.1 这类产品名是通用IVI的 Android 13 车机，回退到“fingerprint 以BYD-AUTO/IVI/开头且 SDK ≥ 33 则推测为 DILINK_5”的启发式（Source.LIKELY），否则记为UNKNOWN；
• 允许驾驶员纠正：confirmed()优先读取用户确认值，current()才回落到检测结果；
• 只呈现该世代适用的功能，并标注Tested on some cars或Experimental，需要 ADB 的条目带 ADB 徽章。SetupGuide.kt 第 22 行注释直接写明“Claims follow docs/COMPATIBILITY.md: community reports, not a certified support list”——即功能标注是兼容性文档里那些报告的代码化，不是认证支持列表；
• 世代冲突保护：在 DiLink 3 上车机会隐藏 DiLink 4 的 cluster 路由并主动提示关闭，因为hasConflictingClusterRoute()（同文件第 39 行）判定该路由会停掉 DiLink 3 的仪表盘地图。

这个设计把“兼容性声明”从文档同步到了运行时 UI：用户看到的每个Tested/Experimental标签背后，都是docs/COMPATIBILITY.md中对应证据行的代码映射。

七、设置区结构与职责划分

兼容性文档同时承担了“设置地图”的角色，各分区职责如下：

• Settings → Display：分辨率、帧率、图标/文字大小、外观（appearance）与Interface size。注意 Interface size 只放大 DiPlay 自身的控件，不改变 CarPlay 画面几何；
• Audio：音频路由与常规音乐缓冲（ordinary music-buffer）选择；
• Navigation：定位与 BYD 导航引导；
• Vehicle：手势、方向盘按键、车机按钮控制；
• Connection：传输方式、启动行为、权限；
• Advanced：实验性显示/媒体与车辆数据；
• Diagnostics：导出诊断报告。

一个值得注意的实装细节：0.2.14 中已被观测到的1280×480 DiLink 3 投影视口已被现有 cluster-map 路径识别，但实测的 1920×720 标定不会套用到更小的面板上；实际地图输出仍需车上复测。对应的 USB 帧排队/队列修复与蓝牙接收修复有回归覆盖，但文档明确“不证明修复了所有连接问题报告”。另外一条硬约束：纯充电 USB 口无法提供数据传输。

八、已知限制：每一条都有证据边界

原文档的 Known limitations 一节是排障时的对照清单，完整整理如下：

1. 热点自动加入失败：iPhone 离开当前 Wi-Fi 网络后没有加入车机热点时，先检查该热点的 Auto-Join 是否开启。如果手动选择热点就能无密码启动 CarPlay，请在诊断报告中记下这一区别——AP 广播信息元素（IE）可能影响自动加入，即使凭据和后续 CarPlay 传输本身是好的。Apple 的文档化要求与受控对照实验见 WIRELESS_HOTSPOT_JOIN.md（其中记录了“加入 Apple vendor IE 后自动加入成功、移除后失败”的三组对照），但文档强调这不构成对所有车机或 iOS 版本的已支持修复。
2. 卡顿（stutter）：部分车机有卡顿，尤其在高视频负载下。仅凭 2.4 GHz 链路无法定位原因——干扰、固件、解码器停顿都可能贡献。官方建议：先试 Default icons、30 fps 和更低分辨率，再附诊断报告。BYD 唐（Tang）上最平滑的 Wi-Fi 信道与画面尺寸组合及其原因，见 SMOOTH_WIRELESS.md。
3. 周期性无线卡顿（2023 款汉 / GCC DiLink 3 的具体案例）：贡献者报告，当车机 Wi-Fi 客户端断开时，每 10 秒一次的扫描会把射频从 CarPlay 信道夺走 3–6 秒。在 Android 10 上，若网络 ADB 已授权且框架事务可用，DiPlay 会为热点/P2P 会话暂停连通性扫描；Same LAN 被排除，站点重连与漫游保持可用。实现上的可靠性设计在 WifiScanPauseSession.kt 可以逐条对上：控制器租约共享一个串行 worker（owners集合 + 单线程语义）；持久化标记先于抑制写入（“Persist before the write”注释，第 31 行）；最后一个租约关闭后扫描才恢复（recover()）；恢复失败时只要 app 在运行就每 30 秒重试（见 WifiScanPause.kt 与启动恢复路径）；force-stop 可能把恢复推迟到下次打开 app。缺少批准或事务支持时，扫描保持原样不动。文档同时注明：更新后的应用内生命周期需要驻车复测；在没有 ADB 的测试中，把车机加入热点同样减缓了扫描。
4. 图标/文字大小不生效：部分 iOS/车机组合不会可视化地应用 icon/text size；重连逻辑已实现，但不保证 iPhone 会选用请求的布局。
5. 5 GHz 能力标志的误导：射频支持“加入” 5 GHz 网络，不代表能接受 5 GHz Wi-Fi Direct 组；能力标志只是诊断信息，不是 group-owner 支持的证明。
6. 自动启动依赖车机固件与启动权限；USB要求数据口与正确的主机/设备角色行为。
7. 待扩大测试：通话、Siri、后台重连、长途行驶与未来 iOS 版本。

九、问题反馈流程：0.2.14 + 诊断报告

官方给出的报告流程是兼容性结论的输入端，原文档要求：

1. 在0.2.14上复现问题；
2. 打开Settings → Diagnostics → Save diagnostic report；
3. Android 10+ 通常保存到Downloads/DiPlay；Android 9 使用文档选择器（document picker）；确认框会指出回退存储位置，并提供View report与Share；
4. 把审阅过的.txt附到项目 issue 跟踪器中匹配的问题或新建 issue，内容需包含：车机/头单元、Android/DiLink/固件、iPhone/iOS、连接方式、复现步骤与故障时间；
5. 没有任何内容会自动上传。

报告内容本身也划了明确的隐私与证据边界：记录请求频率、站点关联状态（station association state）、回退失败与已记忆配置事件；Android 10+ 可验证实际组频率，Android 9 把已接受信道申请报告为 unverified、系统默认报告为 channel 0；Wi-Fi 凭据与协议载荷被排除。最后一条原则尤其重要：“热点成功”本身不等于“CarPlay 会话成功”——排障时必须把 Wi-Fi 链路建立与 CarPlay 会话两个阶段分开判定。

十、给维护者的一句话总结

docs/COMPATIBILITY.md的写作风格是“证据分层”：每条结论都标注了它是实车验证（development car / 指定固件）、贡献者单点报告（Redmi K20 Pro、2023 汉、2022 Seal），还是自动化回归覆盖，并且反复声明“回归覆盖 ≠ 全量支持”。仓库源码（setup/的世代识别与功能标注、network/的 P2P/扫描暂停实现、AirPlayPersistence.kt的实验开关持久化）与这套声明是一一对应的。判断自己的车机是否可用时，正确姿势是：先查第二节矩阵确认 API/固件档位，再对照第四、五节确认无线路径与实验功能边界，最后按第九节流程用 0.2.14 产出报告，而不是直接外推社区结论。

• 移动开发
• 智能硬件
• 音视频