DiPlay 隐私与诊断数据模型：本地优先的连接设计、报告脱敏与 Usage Access 边界

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

DiPlay 是一款面向兼容 Android 车机的独立 CarPlay 接收端，其隐私设计的核心是"本地优先"：认证与连接全部发生在车机与 iPhone 之间的本地链路上，不存在账号体系或远端认证服务，诊断数据也只有在你主动导出时才会落地。阅读本文后，你将理解 DiPlay 在头端（head unit）侧存储了哪些数据、为什么认证配对材料永远不会进入 Android 备份、诊断报告导出与脱敏的具体实现边界在哪里，以及可选的 Usage Access 权限如何被限制在四个比亚迪（BYD）原厂仪表 Activity 之内。

本地优先：无账号、无云服务的连接模型

DiPlay 的产品流程依赖本地认证与 iPhone 之间的直连 USB/Wi-Fi 通道：

• 没有账号，没有远端认证服务，也没有任何自动上传诊断信息的行为；
• iPhone 上运行的 CarPlay App 拥有各自的联网与隐私行为，这属于那些 App 的范畴，不受 DiPlay 控制；
• 所有与配对手相关的材料（配对数据、配对设备选择）都只存在于车机的应用私有存储中。

头端本地保存的内容包括：应用偏好设置、配对设备选择、配对数据，以及有界（bounded）的诊断日志。这里的"有界"不是营销措辞，源码中确实存在一个容量受限的写盘组件 BoundedDiagnosticWriter：它用单个守护线程串行写盘，队列最多保留 64 条待写入记录，过载时丢弃最旧的条目，"永不等待磁盘"（Never waits for disk. Under overload, discard the oldest pending entry）。诊断日志因此不会无限膨胀，磁盘失败也不会阻断后续写入。

认证与配对材料被排除在 Android 备份之外

隐私声明"Authentication and pairing material are kept out of Android backup（认证与配对材料被排除在 Android 备份之外）"对应的是整份备份排除规则 backup_rules.xml。该文件排除了 root、file、database、sharedpref、external 以及全部 device 域，也就是说 DiPlay 主动声明了整应用级备份排除，配对密钥与认证材料不随 Android 备份/还原流程流转。

数据生命周期上的两个事实也值得注意：卸载应用会删除应用私有数据；而你此前导出到 Downloads 的报告是独立于应用的数据，会一直保留直到你手动删除。

诊断报告：内容、脱敏与诚实的边界

诊断导出完全由你发起（"Diagnostic export is initiated by you"），没有任何自动外发通道。报告包含的内容是：

• App 与设备版本；
• 显示设置与分辨率协商过程；
• 连接状态迁移（connection transitions）；
• Wi-Fi 频段/信道与状态；
• 解码器恢复事件（decoder recovery events）。

脱敏过滤器：源码级的逐条规则

"导出器会过滤协议载荷、携带凭据的行以及常见标识符"这句话的实现是 DiagnosticRedactor，它对每一行日志做如下处理：

从源码结构看，脱敏采取的是"丢弃可疑行 + 替换地址类标识 + 截断长度"三层策略：宁可丢弃整行信息，也不在凭据上下文中做局部替换。

文档同时给出了一个诚实的边界声明：脱敏无法承诺识别所有厂商自定义的字符串。在把报告贴到公开渠道（例如 GitHub issue，它本身就是公开的）之前，应当人工复查一遍报告内容。

导出存储链：三级回退与共享授权模型

当系统的文档选择器（document picker）或 Downloads 存储不可用时，报告保存到主外置存储的Android/data/<package>/files/diagnostic-reports/，全程不请求存储权限；导出确认界面会显示实际 TXT 文件路径。这一描述对应 DiagnosticExportStore 的saveWithoutPicker三级回退：

1. Android 10（API Q）及以上：通过MediaStore.Downloads写入Downloads/DiPlay，并使用IS_PENDING机制保证"写完才发布"——写入或发布失败时会删除本次创建的半成品条目，不留残留报告；
2. 外置应用专属目录：context.getExternalFilesDir(null)下的diagnostic-reports/，即Android/data/<package>/files/diagnostic-reports/，无需任何存储权限，也不依赖 OEM 的文档选择器 Activity（部分车机系统缺失该组件）；
3. 应用私有目录：外置存储缺失、只读或写满时，最终回退到应用私有存储filesDir/diagnostic-reports。

几个与隐私直接相关的实现细节：

• 包名：发布包为com.shihab.diplay，调试构建为com.shihab.diplay.hudtest（代码注释明确要求包含调试 applicationId 的包专属目录）。新版 Android 的文件管理器可能限制访问Android/data，此时应使用 DiPlay 内置的View或Share功能，而不是用文件管理器翻找；
• 只保留最新 8 份：每个回退目录在保存新报告时，按修改时间排序、保留最新 8 份并删除其余文件（drop(7)?.forEach { it.delete() }），且永远不会清理"正在返回的那一份"；
• FileProvider 的独立身份：报告 URI 由 DiagnosticReportProvider 生成，该类是一个独立的FileProvider子类，注释写明目的是"防止合并后的应用清单扩大报告路径面"。在 AndroidManifest.xml 中，该 provider 声明为android:exported="false"、android:grantUriPermissions="true"，authority 为${applicationId}.diagnostic-reports，路径白名单仅包含 diagnostic_report_paths.xml 中的两个diagnostic-reports/目录；
• 每次导出都是新 URI：每次导出创建全新的临时文件与 URI，"earlier share grant cannot read a later report"——早前的分享授权无法读取之后的报告。分享操作只对选中的那一份报告授予读权限，不会自动发送任何东西；
• Android 9 及更早版本的已知限制：在这些系统上，拥有存储权限的其他应用有可能读取到外置存储中的报告。

权限清单：每个权限的真实用途

DiPlay 申请的权限与其实际用途一一对应，且多为可选能力：

"optional local VPN permission supports the USB link; it does not provide a remote internet VPN" 是一个关键澄清：该权限只是 Android 平台实现 USB 网络通道的技术手段，流量不会经过任何第三方。AndroidManifest.xml 中的FOREGROUND_SERVICE_MICROPHONE、FOREGROUND_SERVICE_LOCATION等声明与上表的麦克风/位置用途相对应，而PACKAGE_USAGE_STATS的注释也明确标注为 "Optional, owner-enabled Usage Access for the verified DiLink 5.1 cluster profile"。

Usage Access：被白名单锁死的四个 BYD 仪表 Activity

已验证的 DiLink 5.1 仪表 profile 会可选地使用 Android Usage Access（使用情况访问）来跟随车机主题与小地图卡片的可见性。这是 DiPlay 中唯一触碰"应用活动历史"的权限，仓库对它的约束体现在三层：

1. 白名单过滤。ClusterActivityState 的accepted方法只接受四个原厂 BYD 仪表 Activity：

   • com.byd.automap.meter.MeterActivity（全屏地图，来自com.byd.automap/com.byd.launchermap）；
   • com.byd.automap.meter.MeterSmallScreenActivity（小窗地图）；
   • com.byd.sr.cluster.ClusterActivity（场景主题，来自com.byd.sr）；
   • com.byd.cluster.SimpleClusterDynastyActivity（简约主题）。

   其他任何应用的活动事件直接return，不进入状态机；源码注释写明："head-unit apps are irrelevant（车机应用与我们的覆盖层无关）"。

2. 本地处理、最小日志。DiLink51ClusterMonitor 通过UsageStatsManager查询事件，仅处理ACTIVITY_RESUMED（type 1）与ACTIVITY_STOPPED（type 23），并对事件做去重；对系统关机/开机事件（type 26/27）则清空状态。最终输出的只是推断出的仪表主题/可见性变化，无关的活动事件既不被保留也不被上传；任何RuntimeException都会让状态回退为"无可靠信号即不显示覆盖层"。

3. 权限检查与可撤销性。hasAccess通过AppOpsManager.checkOpNoThrow(OPSTR_GET_USAGE_STATS)判断是否真正获得授权（MODE_ALLOWED）。该模式是 opt-in 的：禁用它即停止这些查询；也可随时在系统设置中撤销 Usage Access，相关说明见 BYD 导航文档的 DiLink 5.1 主题 profile 一节。

静态网站与第三方服务

DiPlay 的静态网站不包含任何分析脚本（analytics），也没有账号功能。文档同时如实提示：当你使用 GitHub Pages、GitHub 或 Telegram 这些服务时，这些平台会各自适用它们自己的隐私政策——这属于服务方行为，与 DiPlay 应用本身的数据处理无关。

小结：可验证的隐私边界

把文档声明与仓库实现对照起来，DiPlay 的隐私模型可以归纳为几条可验证的边界：

• 无外发：没有自动诊断上传，报告只在用户主动导出时生成，且分享授权只覆盖单份文件；
• 备份隔离：整份 backup_rules.xml 排除全部数据域，认证/配对材料不进入 Android 备份；
• 存储有界：诊断日志写入端有 64 条队列上限，导出目录只保留最新 8 份，卸载即清空应用私有数据；
• 脱敏有规则也有诚实声明：DiagnosticRedactor 明确列出丢弃与替换模式，但公开前仍需人工复查；
• 特权最小化：唯一的敏感系统权限 Usage Access 被白名单锁在四个 BYD 原厂仪表 Activity 上，且 opt-in、可撤销。

对于需要在车机侧长期运行的 CarPlay 接收端而言，这套"本地优先 + 有界存储 + 白名单特权"的设计，为审查同类车载应用的数据行为提供了一个具体的参照基线。

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