范围

本文介绍鸿蒙生态设备之间文件互传发现、接入认证和文件传输规范，满足不同厂商的鸿蒙生态设备之间文件能够相互分享。本文适用于鸿蒙生态设备文件分享特性。

用词约定

规则：必须遵守的约定

建议：需要加以考虑的约定

说明：对此规则或建议进行相应的解释

参考：详细说明附带链接

特性概述

OpenHarmony L2设备（Source端）文件管理器和图库可以选择文件、图片分享给OpenHarmony L2设备。OpenHarmony L2设备 接收到文件支持保存到本地。

软件版本

OpenHarmony系统版本基线：基于 OpenHarmony-v5.0.0-Release。 图库应用版本：基于OpenHarmony-v5.0.0-Release。 文件管理器应用版本：基于OpenHarmony-v5.0.0-Release

用户历程图

设备发现

设备交互流程图

阶段1：发现设备（广播与扫描）

• 动作：用户点击【图库文件管理器(Source)】上的“分享”按钮。

• 过程：

  1. Source端开始搜索设备（搜索设备）。

  2. Source端发出广播（BLE广播发送广播），告诉周围设备“我要找设备”。

  3. 接收端（图库文件管理器(Sink)）听到广播后，回应说“我发现你了”。同时也发出BLE广播（BLE广播发现广播）。

  4. 双方通过局域网探测（探测设备），确认彼此都在线。

• 结论：Source端成功在界面上显示出了可用的设备列表。

阶段2：发起连接与权限验证

• 动作：用户在Source端点击了目标设备。

• 过程：

  1. 建立基础连接：Source请求建立连接（请求授权），Sink端响应连接建立（建立蓝牙连接）。

  2. 身份确认（PIN码）：

     • Sink端弹出输入框，要求用户输入配对码。

     • Source端同时弹出输入框（提示用户输入PIN码）。

     • 两边用户输入相同的PIN码。

  3. 授权判定：系统比对两者输入的PIN码。如果一致，Sink端告诉Source端“授权成功”。

• 结论：设备配对成功。此时Source端界面上显示“设备已上线”。

阶段3：建立“3种不同类型的会话通道”

• 关键点：成功后，不是只建一条通道，而是同时建立3条通道（分别用于消息、字节流、大文件），这在“分布式软总线”那一列有明确体现：

  1. CreateSession (message)：建立消息通道（用于控制指令、短消息）。

  2. CreateSession (bytes)：建立字节通道（用于传送小数据、缓冲区数据）。

  3. CreateSession (file)：建立文件通道（用于传送大文件）。

• 注：你可以看到这三行后面都是 session Opened，表示这三条路都修通了。两边都会同时在设备绑定了以后创建这三种通道。

阶段4：演示发送“小消息” (Message)

• 动作：Source端发起一个 sendMsg 动作。

• 过程：

  1. 消息通过“消息通道”传过去（sendMsg -> onMsgData）。

  2. Sink端收到消息后，回复一个确认信号（confirm data）。

  3. Source端收到确认（onconfirm data）。

• 结论：演示了如何通过通道发送小数据包。最后 onconfirm data 后，可能会有界面提示“已送达”。

阶段5：演示发送“大文件” (File) 并结束

• 动作：Source端准备发送一个文件。

• 过程：

  1. 数据通过“文件通道”传输（sendFile -> DFIle -> RecFile）。

  2. 文件传输完毕后，Sink端展示传输成功状态（展示传输成功状态）。

  3. 结束会话：Source端发起 CloseSession。

  4. Sink端确认结束（结束会话）。

  5. 最终结果展示在Source端（结束会话），并反馈到图库管理中（图库或文件管理显示）。 

设备发现流程

这张图完美地展示了双方在“发现阶段”扮演的两种不同角色（一侧是主动扫描，另一侧是被动广播）：

1. 左侧：主动寻找设备的角色（Source / 发起方）

• 起点：OH-share SDK Source 调用 remoteDeviceModel.startDeviceDiscovery（开始发现设备）。

• 向内调用：指令传递给 device_manager（设备管理器）。在管理器内部，它走过了 interfaces（接口层） -> napi接口（可能是JS/C++的适配层） -> services（业务层）。最终到达 DiscoveryManager.StartDiscovering（开始发现）。

• 向下递进：发现指令被传递到 dsoftbus（软总线）底层。在软总线内部，经过 sdk、core（核心层），一直下降到 disc_ble_dispatcher.c（蓝牙分发器）。

• 硬件动作：最底层物理接口执行 BleDispatchStartPassivePublish，也就是开始监听蓝牙广播（被动扫描）。

2. 右侧：被动暴露自己的角色（Sink / 接收方）

• 起点：OH-share SDK Sink 调用 remoteDeviceModel.publishDeviceDiscovery（发布设备发现，即“我要让别人发现我”）。

• 向内调用：指令传递给 device_manager，最终到达 AdvertisementManager.StartAdvertising（开始广播）。

• 向下递进：指令进入 dsoftbus，经过 sdk、core，一直下穿到 disc_ble_dispatcher.c。

• 硬件动作：最底层物理接口执行 BleDispatchStartActivePublish，也就是开始向外发送蓝牙广播信号。

3. 中间的交互（底层物理层）

• 关键线：在左右两边的底层物理接口之后，出现了一条横跨左右的虚线：BLE广播。

• 解释：右侧发广播，左侧通过蓝牙扫描收到广播。紧接着有BLE扫描发现。这说明左侧的设备已经成功“听”到了右侧的广播，发现了对方的存在。

4. 最后的数据回流（Return）

• 当底层的硬件命令执行完之后，信息开始层层向上返回。

• 右侧的 return 告诉 SDK：“广播已经发出去了”。

• 左侧的 return 告诉 SDK：“我已经开始扫描了”。（而且底层扫描到的结果也会通过类似的层层调用向上报告给界面）。

发现报文

open Harmony生态设备统一分享ADV报文

设备连接认证流程

一、 左侧：发起连接请求（Source 端）

这条长线展示了应用层如何一步步下指令给蓝牙硬件。

1. 起点（应用层）：最上方的 OH-share SDK source 发出 bindTarget 指令（意思是“我要绑定连接这个目标设备”）。

2. 层层下发（设备管理器）：

   • bindTarget 进入 device_manager。在管理器内部，它依次经过 interfaces -> napi接口 -> services（设备管理核心）。

   • 到了 services 层，执行了关键的一步：DmAuthManager::EstablishAuthChannel（建立认证通道）。这说明系统意识到，接下来要确认身份了，所以要先开一条“通道”。

3. 进入软总线底层：认证请求被下发到 dsoftbus。

   • 在 dsoftbus 内部，系统创建会话接口 (OpenAuthSession)。

   • 调用核心逻辑 (SoftBusServerStub::OpenAuthSessionInner)。

   • 关键环节：执行 ConnConnectDevice（连接设备）。图上特别备注了：“这里会有超时时间，以及连接类型选择”（连接类型指的是通过Wi-Fi连还是蓝牙连）。

4. 触达物理层：最终命令下达到蓝牙控制层 core/connection/ble/src，执行 BleConnectDevice（开始真正的蓝牙连接）。

---

二、 右侧：接收端的准备与环境（Sink 端）

你会发现右侧在左下方的请求到达之前，自己先做了一些动作。

• 右侧初始动作（最上方）：dsoftbus Sink 监听到了蓝牙开关变化 (OnBtStateChanged)。

• 动作触发：设备确认蓝牙开关已打开，于是主动启动了蓝牙服务 (ConnBleStartServer)。

• 意义：这在逻辑上非常合理，接收方必须先准备好“收听”信号的服务端程序，发起方的连接请求才能成功打进来。这是一个由底层触发，而非用户显式点击触发的自动初始化过程。

---

三、 中间：握手的瞬间（物理层交互）

这是这张图最核心的跨模块交互。

1. 连线打通：左侧底层的 BleConnectDevice 发起请求后，跨越中间的网络，直接连到了右侧底层的物理层。

2. 反馈连接成功 (OnConnected)：右侧的蓝牙硬件收到连接后，产生了一个 OnConnected（连接已建立）的信号。

3. 通知传递：这个 OnConnected 信号从右侧发回给左侧的 dsoftbus（准确地说是进入了左侧的 core/connection/ble/src 模块）。

4. 建立认证通道 (ClientAddAuthSession)：左侧收到“连接成功”的信号后，立刻执行 ClientAddAuthSession（客户端添加认证会话）。

---

四、 最后的返回（Return）

• 当左侧完成了 ClientAddAuthSession（底层连接打通，且记录下认证会话的ID）之后，这个成功的消息开始层层返回。

• 从 dsoftbus 返回给 device_manager，最后回到 OH-share SDK source。

• 返回的数据是：返回sessionId。

• 为什么返回这个？ 因为一旦底层物理连接建立好了，底层的软总线会给上层（应用层SDK）颁发一个“房间号”（Session ID）。接下来进行 PIN 码输入、文件传输时，上层应用就不需要再去管蓝牙或 Wi-Fi 怎么连了，只需要对着这个 SessionId 说话就行了。

无账号PIN认证

在上一张图刚看完底层的“物理连接建立”，这张图紧接着就是建立在那个物理连接之上的“业务逻辑认证”阶段。这里面的核心是通过“PIN码（配对码）验证”来确保两端设备是安全的，并且用户是主动同意的

1.防中间人攻击机制，左边发起认证，右边生成pin码显示在右侧UI上并且加密传到左侧设备，左侧设备看到右侧设备的pin码才能进行认证连接。

2.业务和传输分离，中间传递的都是MSG_TYPE_REQ_AUTH这种业务消息，而不是底层的Bluetooth connect消息，说明在上一张图建立好物理连接以后，这张图完全就是应用层的业务逻辑了。

3.右侧是服务员（生成密码、展示密码），左侧是顾客（输入密码、核验密码）

软件层再次初始化DM和之前系统启动时全局DM初始化区别

在成熟的操作系统（如鸿蒙、Android）中，Device Manager 是一个常驻后台的系统级服务。

• 当系统刚开机时，这个 DM 服务就已经启动了（全局初始化）。

• 但是，每当有一个新的“应用连接请求”发生时，DM 服务需要为这个特定的请求创建一个新的“会话实例（Session Instance）”。

• 图中标注的 初始化DMmanager，在实际代码中，往往对应着 new DMHandler() 或者 DmAuthManager::Init() 这种为了特定会话新建对象的操作。

结论： 图里标注的这个“初始化”，不是说把整个 DM 服务重启一遍，而是说“为了处理这一次特别的配对认证，DM 在逻辑上准备好了专门的资源和处理人员”。它是架构设计中必不可少的环节。