HarmonyOS鸿蒙Next中星闪作为服务端开始广播失败

HarmonyOS鸿蒙Next中星闪作为服务端开始广播失败 鸿蒙手机作为星闪服务端，开始广播，初次广播成功。外部设备连接上之后，广播自动停止。外部设备断开，程序主动再次调用开始星闪广播，提示code=1009700099, message=Operation failed.后续每过6s周期性调用

advertising.startAdvertising

都提示这个错误，可能这个操作连续几分钟之后可以开启广播成功一次。
如果在后台杀掉程序，再次打开程序一定能开启广播。

7 回复

code=1009700099, Operation failed，这个报错说明是旧的广播通道资源未正确释放，导致底层协议栈无法分配新的广播通道。

我的建议是在设备断开连接后，先调用 stopAdvertising释放旧通道，等待足够时间让底层资源回收，再调用 startAdvertising开启新广播。同时应取消 6 秒周期性轮询，改为仅在断开连接事件中触发重启广播的逻辑。

开发中注意几点：

  1. startAdvertising和 stopAdvertising必须配对使用

每次 startAdvertising返回一个新的 advertisingId，代表一个独立的广播通道。必须调用 stopAdvertising(advertisingId)释放该通道，否则通道资源会累积占用，最终导致 Operation failed4。

  1. 连接建立后广播自动停止是协议正常行为

官方文档明确说明：建立 SSAP 连接后，SSAP 服务端广播会自动停止。后续如果服务端期望被客户端发现，需要重新发起广播1。这不需要调用 stopAdvertising，但广播通道资源仍需在重新开启前释放。

  1. 断开连接后需要等待底层资源回收

星闪协议栈在连接断开后需要时间完成内部状态重置。建议在断开连接回调中等待 500ms~1000ms后再调用 startAdvertising，避免因底层状态未就绪而报 Operation failed。

  1. 杀掉程序能成功的原因

杀掉程序后，系统会强制回收所有星闪相关资源（广播通道、SSAP 连接等），底层协议栈完全重置为初始状态，因此重新打开程序后一定能开启广播成功。这也从侧面印证了问题是资源未正确释放导致的。

  1. advertisingId取值范围

advertisingId的取值范围为 [0, 255]3，最多支持 256 个广播通道。如果不配对调用 stopAdvertising，通道很快会被耗尽。

ssap（星闪SSAP连接能力）-ArkTS API-NearLink Kit（星闪服务）-网络-系统 - 华为HarmonyOS开发者

更多关于HarmonyOS鸿蒙Next中星闪作为服务端开始广播失败的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


官方说明是：

1009700099

PhonePC/2in1TabletTVWearable

错误信息

Operation failed.

错误描述

当系统内部处理出错，将返回该错误码。

可能原因

其他未知错误。

在设备已配对的情况下再调用startPairing发起配对，会返回该错误码。

处理步骤

进行重试操作或请通过在线提单提交问题。

可以试试：

错误码 1009700099（Operation failed）表示系统内部处理出错，属于"其他未知错误"类型的通用错误码2。在您描述的场景中，该错误最可能的原因是：

设备断开连接后，底层SSAP连接资源未完全释放，导致短时间内再次调用 startAdvertising时系统内部状态尚未恢复，从而返回操作失败的错误。

核心思路：监听连接断开事件，等待底层资源释放后，再重新发起广播，并配合广播状态监听确认操作结果。类似的问题在社区中也有其他开发者反馈https://developer.huawei.com/consumer/cn/forum/topic/0201191070661830775?fid=0109140870620153026：星闪断开后重新连接不上、重新扫描也扫描不到，只有服务端关闭广播再重新开启才能再次被发现，说明断开后底层状态需要正确处理才能恢复。

从现象看，不太像广播参数有问题，更像是上一轮广播或连接资源没有完全释放干净。

关键线索有两个：

  1. 第一次广播一定成功
  2. 杀掉应用重启后一定恢复

这说明硬件和权限基本没问题，问题大概率出在 NearLink 状态机或者资源回收上。

建议重点检查：

1. 连接建立后广播是否被系统自动停止

你提到：

外部设备连接上之后，广播自动停止

这个要先确认是不是预期行为。

如果连接成功后系统已经停止了广播，那么再次启动前最好先执行一次：

await advertising.stopAdvertising(advertisingId)

即使你认为已经停了，也建议主动调用一次，确保状态同步。

2. advertisingId 是否已经失效

很多项目会保存第一次返回的：

const advertisingId = await advertising.startAdvertising(...)

连接断开后如果广播状态发生变化，这个 advertisingId 有可能已经失效。

建议每次启动广播都重新获取并维护最新的 advertisingId。

3. 是否监听了广播状态变化事件

建议注册：

advertising.on('advertisingStateChange', ...)

打印完整状态变化过程。

很多时候看起来是：

连接断开
↓
开始广播失败

实际上是：

连接断开
↓
广播资源仍处于Stopping状态
↓
立即startAdvertising
↓
返回Operation failed

4. 不要每6秒无脑重试

如果底层还没完成资源释放：

startAdvertising()

连续调用反而可能一直失败。

更推荐：

连接断开
↓
等待disconnect回调
↓
确认广播状态结束
↓
重新startAdvertising

而不是定时器轮询。

5. 检查星闪状态

连接断开后打印：

manager.getState()

确认当前仍然是：

NearlinkState.STATE_ON

避免出现连接过程中星闪模块进入异常状态。

如果能提供：

  • startAdvertising 完整代码
  • stopAdvertising 调用时机
  • advertisingStateChange 日志
  • 设备断开回调日志

基本就能判断到底是 广播资源未释放、advertisingId 管理问题，还是 NearLink SDK 本身的状态机问题。

从你描述的“杀进程后必恢复”来看，我个人首先怀疑的是连接断开后广播实例没有彻底释放，导致后续 startAdvertising 命中了 SDK 的状态保护机制。

感觉像是 星闪底层广播资源还没完全释放导致的问题。

建立 SSAP 连接后，服务端广播会自动停止。外设断开后，应用层虽然收到了断开事件，但底层连接链路、广播资源可能还在回收中。此时立刻或周期性调用 advertising.startAdvertising()，就可能返回 1009700099 Operation failed。杀掉应用后能恢复，也侧面说明资源被进程退出清理掉了。

按以下步骤处理试试：

  1. 监听 advertisingStateChange 和 SSAP connectionStateChange，不要只靠定时器重启广播。
  2. 外设断开后延迟一段时间再重新广播，比如 2-5 秒。
  3. 重新广播前，如果保存过旧的 advertisingId，可以先尝试 stopAdvertising(advertisingId)，失败只记录，不要阻断。
  4. 避免并发或重复调用 startAdvertising()，加一个 isStartingAdvertising 状态锁。
  5. 为了避免再次报 1009700099 ，不建议固定每 6 秒硬调。
  6. 检查是否重复创建 ssap.Server、重复 addService()、重复注册监听，这些都可能导致资源状态异常。

不错，

广播失败通常因以下原因：1）未在module.json5中声明ohos.permission.USE_BLUETOOTH及ohos.permission.ACCESS_BLUETOOTH；2）未初始化星闪（NearLink）服务端实例或调用startBroadcast前未调用startService；3）广播参数（如频率、功率）超出设备支持范围。检查权限声明与API调用顺序。

错误码 1009700099 在星闪服务端广播中通常表示 操作过于频繁或广播资源被占用。您遇到的现象本质是：首次广播成功，外部设备连接导致广播自动停止，断开后立即或短间隔反复调用 startAdvertising 时，系统判定上一次广播的资源尚未完全释放或当前处于限制窗口，因此拒绝新请求。周期性每6秒调用仍失败，说明系统对重试间隔敏感；几分钟后偶然成功，可能是内部超时或资源回收周期恰好结束。杀掉进程后必然成功，因为彻底重置了蓝牙与星闪的底层状态。核心原因在于 StarLight Server 从停止广播到可再次启动广播之间存在冷却期，短时间内高频重试会触发防抖或防冲突保护。

回到顶部