让车内灯光，变成一条可验收的工程链路
从手机侧扫描连接，到分区 RGB、灯效与跟随车灯，再到 Android 端 OTA：这不是一张效果图，而是一套围绕设备能力逐段核验的车载氛围灯闭环。
首屏抽象示意图：用于解释链路，不代表某一车型或现场照片。
BLE 连接不是“搜到就算完成”
工程上要把扫描、连接、GATT 服务发现、写特征与通知订阅拆开，才能让后续灯光控制有稳定的入口和异常反馈。
BLE 连接流程示意图
交付时要验收的细节
- 扫描入口、权限提示与超时处理是否明确。
- 连接后是否完成服务发现，而不是直接假定特征存在。
- 写入动作与通知订阅是否能形成“发出—反馈”闭环。
- 断连后由谁提示、谁重连、谁恢复当前灯效，需要提前定义。
分区 RGB：把“氛围感”拆成可测试状态
控制模型围绕区域、颜色、亮度和灯效组织。多灯效与迎宾灯效是控制能力的一部分，跟随车灯则取决于设备是否提供对应支持。
座舱分区控制图：区域是抽象模型，不对应具体车型布局。
控制面板的四个维度
前排、中控、后排等逻辑分区。
RGB 颜色选择与状态回显。
亮度调整要有边界与设备反馈。
静态、多灯效、迎宾与跟随车灯入口。
把端、设备和边界写在同一张表里
状态矩阵帮助产品、App 与固件团队在联调时对齐“已核验”“依赖设备”“不对外宣称”的边界。
| 能力 | 端侧表现 | 设备侧前提 | 公开口径 |
|---|---|---|---|
| BLE 扫描与连接 | 扫描、连接、服务发现、写入、通知 | 设备广播且提供匹配 GATT | 已核验 |
| 分区 RGB / 亮度 | 选择区域、颜色、亮度并下发 | 设备支持区域与灯光控制 | 已核验 |
| 多灯效 / 迎宾 | 选择灯效、触发迎宾入口 | 固件实现相应灯效 | 已核验 |
| 跟随车灯 | 提供控制入口与状态提示 | 依赖设备提供车灯跟随能力 | 条件支持 |
| Android OTA | 检查固件、设备就绪、分包发送、回调 | 设备 OTA 能力、版本与校验约定 | Android 已核验 |
端侧负责交互，设备侧负责可执行性
手机端 / Android
- 发起扫描、连接和服务发现。
- 把区域、RGB、亮度与灯效意图转成设备可接受的控制。
- 订阅通知、展示状态，处理断连与异常。
- Android OTA：检查固件、确认设备就绪、分段传输并接收回调。
灯控设备 / 固件
- 广播、接受连接并提供 GATT 服务与特征。
- 执行分区、RGB、亮度、多灯效与迎宾控制。
- 按能力决定是否支持跟随车灯。
- 提供 OTA 就绪、分段接收与结果回调。
说明：已核验 Flutter 侧扫描、连接和通知能力；本文不把 Flutter 描述为已完成完整 OTA UI 闭环。
OTA 是一条有前置条件的流程，不是一个按钮
Android 侧工程路径覆盖固件检查、长度与设备就绪判断、分段发送和回调处理。分段大小、异常恢复与最终结果必须与设备实现共同验收。
OTA 流程示意图：不展示协议字节、设备 ID 或内部实现细节。
真实案例也要明确“不说什么”
可以确认
BLE 扫描、连接、GATT 服务发现、写入与通知；RGB、亮度、多灯效、分区与迎宾；Android OTA 工程路径。
需要设备配合
跟随车灯、灯效种类、区域数量、OTA 恢复策略与最终表现，均以设备固件能力和联调结果为准。
不作承诺
不公开客户名、项目内名、协议字节、设备标识、密钥、现场照片；不声称所有车型均支持，也不把约 50 万业务统计写成设备、客户或车辆数。
项目评估前，先对齐边界
这个案例真实落地了哪些能力？
已核验的工程链路包括 BLE 扫描、连接、GATT 服务发现、写特征、通知订阅，以及 RGB、亮度、多灯效、分区控制、迎宾灯效和跟随车灯入口；跟随车灯依赖设备支持。
Flutter 端是否可以宣称完整 OTA？
不能。当前可对外说明 Flutter 已核验扫描、连接和通知；Android 侧已核验 OTA 流程。未有完整 Flutter OTA UI 闭环证据，因此不作完整实现承诺。
把设备能力变成可验收的交付清单
如果你正在评估车载氛围灯、BLE 控制或 Android OTA，请带上设备形态、已有 GATT 能力、灯效边界、目标端形态和验收目标。我们先确认能做什么，再讨论怎么交付。
咨询车载氛围灯方案 →