先看清四件事：谁负责哪部分、SDK 怎样启动、一次操作怎样交给硬件、断开后清理什么。本章是接入地图，具体参数继续查各功能章节与 API 参考。接口基线见版本与迁移。
APP、SDK、后台和你的硬件
| 部分 | 负责什么 | 你要接哪一侧 |
|---|---|---|
| 管理后台与服务端 | 登记设备与型号、签发授权、管理云端绑定及功能配置 | 确认环境、设备身份和型号；由有权限的管理员准备材料 |
| Android / iOS APP | 用户登录、设备连接、导航、权限申请和系统音频/录屏入口 | 使用配套 APP 联调；由用户完成系统授权 |
| 终端 SDK | 校验授权与会话、处理协议、分发事件、管理已接入通道 | 链接匹配的头文件和静态库，配置公开端口 |
| 你的应用与 BSP | 无线/IP、存储、屏幕、解码、音频输出、CAN/UART 和真实执行器 | 实现驱动、UI 和产品安全条件，回报真实结果 |
在本文的近场连接中，控车、HUD 和媒体直接在手机与终端之间传输，云端不是每个媒体帧的中转站。热点已连接、SDK 启动成功、owner 已认证、某个功能可用，是四个不同状态。
这里的 owner 是绑定设备的用户；SDK 所属线程是串行执行 SDK 的任务，两者不是同一个概念。BSP 指板级适配层，例如无线、存储和显示驱动。
先选 Managed 或 Core
| 产品需求 | 推荐入口 | 谁负责调度 |
|---|---|---|
| Wi-Fi 主业务、控车、HUD、导航视频、已开放的功能端口 | Managed：moto_terminal |
SDK 创建任务和队列；你持续取事件并连接驱动 |
| 在上述基础上增加 Wi-Fi 音频、独立镜像 | 继续 Managed，启动前按需 set_audio / set_mirror |
同一个 SDK 任务；镜像要求 config.network 和视频能力 |
| 当前 App 首次添加、BLE 通知、感应解锁、底图存储、同 owner 的候选连接接管 | Core：moto_sdk |
你的所有者任务串行驱动对应实例与端口 |
Managed 封装了 Core，但不能把两个句柄或事件结构互相转换。Core 仍可复用 moto_network 的网络管理，不要求重写发现、监听和背压。先按目标功能选入口，再看首次连接或参考工程。
图一：终端程序的生命周期
下面是 Managed 的启动顺序。每一步检查返回值，失败时停止推进；初始化和关闭由同一个生命周期管理任务负责。
逐步说明
- 准备 BSP 和存储
初始化存储、时钟、随机源与驱动；准备本机 License 和绑定记录读取。
- config_init → create
填写实际硬件与功能端口。create 校验配置、授权和存储，成功后得到 terminal。
- 按需设置音频与镜像
在 start 前调用 set_audio / set_mirror 并检查结果；不需要的功能保持关闭。
- start
创建 SDK 任务。成功表示任务已启动，不表示无线芯片或手机连接已经就绪。
- 启动无线与 IP，持续取事件
BSP 启动 AP / DHCP 并报告 link.ready 与 generation；一个应用任务用 next_event 取事件并分发。
- 运行与连接恢复
SDK 管理连接；驱动任务完成显示和执行。一次网络断开通常清理会话，不销毁整个 terminal。
config.network 是推荐网络入口；它与高级外部 transport_send/transport_close 互斥。Managed 已负责主连接时，不要再手动 accept 或调用 connected/receive/disconnected。BSP 报告本地 IP 是否可用；即使重连后 IP 没变，失效的链路也要更新 generation。详见Wi-Fi 与蓝牙。
Core 不自动创建应用任务。网络、SDK 和辅助实例须遵守同一个所有者线程规则；moto_network_poll 已驱动其绑定的主业务/镜像实例，不要再对这些实例重复 poll。视频重组器等独立对象按各自章节串行调用。
图二：手机连接到功能可用
以下是当前 App 的首次添加流程，需要 Core 的 BLE 辅助实例与 Wi-Fi 主业务。Managed 单 Wi-Fi 模板不提供完整首次添加；已有有效绑定的主业务重连无需重复 PIN 和云端绑定。
逐步说明
- App 通过 BLE 搜索车辆
用户登录并开启蓝牙；终端广播完整 SDK 发现标识。搜索结果不代表已经认证。
- BLE TLS 就绪，再确认 PIN
建立安全通道并输入仪表 PIN；READY 本身不代表 owner 已认证。绑定记录须先持久保存。
- 云端绑定，再引导 Wi-Fi
完成云端绑定后，通过认证 BLE 取得热点信息；用户按提示加入车辆热点。
- Wi-Fi 主业务认证
独立建立主业务 TLS 并认证 owner，应用有效型号签名配置与能力协商；加入热点不等于这一步成功。
- 目标功能就绪
硬件实现、有效授权、客户端协商和该功能运行条件都满足，才开放相应操作。
例如，Wi-Fi 认证不代表 ANCS 已订阅，A2DP 能力不代表手机已切换音频路由，收到视频不代表 LCD 已呈现。用功能配置、对应事件和实际硬件状态共同判断。
图三：一次控车操作怎样执行
下面以 APP 发起的车辆命令为例。音频回调、通知和导航动作各有自己的回执契约，不能照搬“控车执行成功”。
逐步说明
- APP → SDK 校验
验证授权、会话、命令参数和时效，生成 VEHICLE_COMMAND。
- 事件任务 → 车辆驱动任务
复制完整事件，保留 connection / session / request 与截止时间；事件读取不等待慢硬件。
- 驱动检查后执行一次
执行前复核归属、时效及车辆联锁条件，再调用实际 CAN / UART / 执行器。
- 驱动 → SDK 完成队列
使用原事件调用 complete。OK 只表示回报已入队；FULL 只重试仍有效的结果，不重做物理动作。
- SDK → APP 结果与真实状态
成功、失败或未知按驱动事实回报。状态上报仍来自实际控制器；断线后的旧请求不能套用新会话。
Managed 的 moto_terminal_event 是自持副本，可以复制给驱动任务；Core 的 moto_event 含借用数据，必须在回调返回前复制所需内容。SDK 端口回调保持有界、不得重入 SDK；需要等待硬件的工作按该端口的异步契约交接。详见车辆控制及线程与所有权。
通道各有自己的职责
| 通道 | 承载内容 | 结束时怎样处理 |
|---|---|---|
| Wi-Fi 主业务，默认 TCP 5004 | 认证、控制、状态、导航与 HUD | 清理该会话的临时状态和旧输入；普通断连保留绑定 |
| 独立 BLE 辅助 | 首次配对引导、通知、ANCS、感应解锁 | 清理自身会话；BLE 断开不等于 Wi-Fi 导航结束 |
| 视频 UDP 5001 | H.264 / MJPEG 帧 | STREAM_STOP 清理视频；仍有效的 HUD 可继续 |
| 地图 TLS 5003 | 路线周边底图 | 依地图事务和导航生命周期清理，不能只凭传输百分比判断就绪 |
| 镜像控制 TLS 5005 | 当前镜像流的授权、续期与反馈 | 主 TCP 意外失效可保留已委派且有效的租约；整网失效、显式停止或撤权则结束 |
| 音频 TLS 5006 | 系统允许采集的播放 PCM | 停止共享、失去授权或超时清理流及旧缓冲；实际听音另验收 |
各通道不是把所有数据塞进一个队列。它们共用产品身份与授权约束，但保留各自会话、流和资源归属。能力与具体接线见通知、导航、投屏、地图和音频。
图四：停止、重新启动与销毁
逐步说明
- 停止新提交与外部调用者
停外部输入生产者、事件读取者及驱动任务对 terminal 的访问；底层关闭回调和上下文仍保留。
- stop → 等待清理
生命周期任务调用 stop。返回 AGAIN 时实例仍有效，下一次调度继续 stop，不能强制释放。
- stop 返回 OK
选择 start 复用同一实例，或在所有调用者退出后 destroy；不要并发 start / stop / destroy。
- 重启或完成销毁
重启重新读取授权和绑定并建立新会话；destroy 成功后清空句柄，再释放客户驱动上下文。
普通停止与断网不擦除 License 或 owner。解绑、云端重置和本地撤权是单独流程；云端返回成功不能证明离线终端已清除旧 owner。见持久化与售后恢复。
第一次联调只需先验证“发现 → 认证 → 主题实际改变 → 重启恢复绑定”。随后按产品功能补齐真实执行、显示、声音和异常清理。继续首次连接，遇到问题按排障逐段定位。