本文汇总 Miracast Source 应用侧两类问题：取消连接对话框后无法再搜到设备、对端断开后控制中心再次点开无线投屏无响应。两案对端均为投屏器；Source 经控制中心「无线投屏」操作，未单独限定 Source 板型号。

Miracast Source 是镜像投屏的发屏端：负责发现 Sink、发起会话、在控制中心/通知栏展示投屏状态。应用层通过 CastSession 等 API 与投播框架（castengine_cast_framework）交互，底层再落到 WFD（castengine_wifi_display）与 Wi-Fi P2P。应用问题往往要联合框架层一起看，建议先确认 API 参数与调用顺序，再在调用入口/出口打 cast-> 类日志便于对照。

设备环境

案例疑难分析:取消连接对话框后再次扫描发现不了设备

1. 问题描述

使用环境与设备： Source 端 Wi-Fi 已打开，经控制中心「无线投屏」搜索并连接 Sink；对端为可投屏的 Sink（如投屏器），Source 板型号未单独限定。

问题现象： 连接投屏设备（如投屏器）过程中手动取消对话框；因当时拿不到 MAC 地址，应用只能调用 CastSession.release。取消后再次扫描异常（通知栏仍像投屏中、控制中心无线投屏再点开无搜索弹窗）。

一句话概括：取消连接的收尾不完整，会话/发现状态没清干净，导致后续扫不到。

2. 分析过程

关闭投屏存在多种路径，需先对齐测试步骤再定根因，例如：

• Source 主动关闭
• Sink 主动关闭
• Source 从控制中心 / 通知栏关闭

正常关闭顺序一般是：若正在广播则先停广播 → 停止投屏 → 释放会话。

对照本场景日志：取消对话框后没有调用停止投屏接口（removeDevice）。

与框架层确认：removeDevice 需要 MAC 地址。取消对话框时应用侧尚未拿到 MAC，只能走 release，于是停投屏步骤被跳过，发现/会话状态残留，再次扫描异常。

应用层在调用框架接口前会打以 cast-> 开头的日志，便于核对调用链是否缺步。

3. 解决方案

1. 框架层：在连接阶段尽早向应用提供 MAC 地址，使取消路径也能调用 removeDevice
2. 应用层：按框架方案补齐关闭流程——取消连接时同样走「停投屏再释放会话」，避免只 release

修完后，取消对话框应能清掉会话与发现状态，再次点开「无线投屏」可正常弹出搜索。

案例疑难分析：对端断开后控制中心无线投屏入口无响应

1. 问题描述

使用环境与设备： Source 端 Wi-Fi 已打开；对端为投屏器。Source 经控制中心连上投屏器并投屏成功后，在投屏器侧管理设备中主动断开 Source；再回 Source 控制中心点「无线投屏」。

问题现象： 控制中心点击无线投屏后，未弹出设备搜索弹窗；再次点击仍无响应（恢复方法：重启 Source）。

一句话概括：对端断开后的释放链路被前序异步 API 卡住，界面入口失效。

2. 分析过程

先看状态日志，发现会话/设备状态异常：

回溯前一次关闭流程：关闭后看不到 removeDevice 成功回调：

cast-> CastSession.removeDevice callback succ

与框架确认：Sink 主动断开时，Source 不必再调 removeDevice。按此修改后问题仍在。

继续查日志：调用 releaseSession 后没有正常返回。再与框架对照，定位到前一个异步调用 CastSession.off('deviceState') 出错，拖死后续异步返回（off('deviceState') 与 releaseSession 均为异步，前者异常会影响后者）。

因果链：

Sink 主动断开 → 应用释放会话 → off('deviceState') 异常 → releaseSession 挂住 → 控制中心再次点开无响应。

3. 解决方案

框架层按 API 文档规范修复 off('deviceState') 等参数/状态场景，保证异常入参或重复注销时也不阻塞后续 releaseSession 等异步调用返回；应用侧保持关闭路径日志完整，便于回归确认回调顺序。

修完后，对端主动断开再点「无线投屏」，应能重新弹出设备搜索界面，无需重启 Source。