HarmonyOS鸿蒙Next中开发蓝牙钥匙，app 打开时能正常通过ble的rssi 的强度实现走远锁车，走近解锁，但是app 杀掉后ble 就直接挂掉了
HarmonyOS鸿蒙Next中开发蓝牙钥匙，app 打开时能正常通过ble的rssi 的强度实现走远锁车，走近解锁，但是app 杀掉后ble 就直接挂掉了 【问题描述】：开发蓝牙钥匙，app 打开时能正常通过ble的rssi 的强度实现走远锁车，走近解锁，但是app 杀掉后ble 就直接挂掉了
【问题现象】：开发蓝牙钥匙，app 打开时能正常通过ble的rssi 的强度实现走远锁车，走近解锁，但是app 杀掉后ble 就直接挂掉了，鸿蒙这边是否有方案可以解决关闭app后台也可以实现通过ble的rssi 的强度实现走远锁车
【版本信息】：开发工具版本6.1.0、手机系统版本：6.1.0.117、Api语言版本：23
【复现代码】：未涉及
【尝试解决方案】：未涉及
更多关于HarmonyOS鸿蒙Next中开发蓝牙钥匙，app 打开时能正常通过ble的rssi 的强度实现走远锁车，走近解锁，但是app 杀掉后ble 就直接挂掉了的实战教程也可以访问 https://www.itying.com/category-93-b0.html
【解决方案】 尊敬的开发者，您好， 关于您的反馈的问题，可以参考[@ohos.FusionConnectivity.partnerAgent（外设互通能力）](https://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-fusionconnectivity-partneragent) 具体实现思路参考以下：
-
系统级代工扫描： 当调用 bindDevice 注册设备，并在 partnerAgent.DeviceCapability 中配置 supportBleAdvertiser: true 后，系统底层会接管该设备的 BLE 扫描任务。 App 主进程可以被用户手动清理（滑掉）。
-
按需精准唤醒： 当系统底层扫描到注册的车钥匙 BLE 广播时，系统会主动拉起 PartnerAgentExtensionAbility 进程，并触发 onDeviceDiscovered 回调。
-
进程被拉起后，系统会赋予该 Extension 进程 3 分钟的运行时间。建立 BLE 连接 -》 获取 RSSI 信号强度进行测距 -》执行加密认证 -》发送开锁/锁车指令。
在具体业务实现时，官方文档中有几个非常关键的前置条件和交互约束，需要特别注意：
- 强依赖系统级蓝牙配对：
文档明确指出：“在应用注册前，需先与该设备完成蓝牙配对。”
意味着车钥匙硬件不能仅靠匿名 BLE 广播来触发系统唤醒。必须在首次绑定时，引导用户在手机系统设置里与车辆的蓝牙模块完成一次正式的配对。
- 能力配置必须精准：
在定义 DeviceCapability 时，必须确保开启 BLE 扫描发现能力。
- 用户开关的容错与引导：
App 在每次冷启动进入前台时，都必须调用 isDeviceBound 等接口进行状态核查。如果发现能力受限，需要弹出强引导，让用户去系统设置中恢复授权。
- 进程间通信与状态同步：
PartnerAgentExtensionAbility 运行在一个独立的进程中，它与 App 主 UI 进程是隔离的。需要设计好状态同步机制。例如，当 Extension 进程在后台通过 RSSI 判断用户走远并锁车后，如果用户此时恰好打开了 App，Extension 进程需要能通过公共事件（CommonEvent）或持久化存储将“已锁车”的状态立刻同步给主进程，刷新 UI。
更多关于HarmonyOS鸿蒙Next中开发蓝牙钥匙，app 打开时能正常通过ble的rssi 的强度实现走远锁车，走近解锁，但是app 杀掉后ble 就直接挂掉了的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
先说一下你问题的原因。因为当用户通过任务管理器强制关闭应用时，应用进程会被彻底销毁，包括所有正在执行的BLE扫描、连接等操作都会立即停止。这是操作系统为了节省资源、保证系统流畅性的正常行为。因此，单纯依靠应用自身的前台进程无法实现永久后台运行。
解决方案也比较简单，你需要利用鸿蒙后台持续任务机制
鸿蒙系统为特定场景（如蓝牙外设连接、健康监测等）提供了后台持续任务（Long-term Task）的能力，允许应用在后台持续运行某些关键任务。对于蓝牙钥匙场景，你可以通过申请“蓝牙相关”的后台任务权限，使BLE扫描在应用退到后台后仍能持续工作一段时间（具体时长受系统策略约束）。但需要注意，即使用户强制杀死应用，系统也可能在条件满足时重新启动你的后台任务（例如蓝牙设备重新连接时），但这并非绝对保证，因此需要结合系统事件进行设计。
按照下面的步骤试试：
1.申请必要权限
在module.json5文件中声明以下权限（根据API 23的规范）：
ohos.permission.ACCESS_BLUETOOTH：用于BLE扫描。
ohos.permission.KEEP_BACKGROUND_RUNNING：允许应用在后台持续运行。
ohos.permission.USE_BLUETOOTH：使用蓝牙基础功能（部分接口需要）。
注意：部分高权限（如MANAGE_BLUETOOTH）仅系统应用可申请，普通应用无需关注。
2.配置后台任务类型
在module.json5的abilities字段中，为入口Ability添加backgroundModes配置，指定为bluetooth类型，表明应用需要在后台执行蓝牙相关任务：
"abilities": [
{
"name": "EntryAbility",
"backgroundModes": ["bluetooth"]
}
]
3.启动后台持续任务
在应用初始化或进入后台时，调用backgroundTaskManager.startBackgroundRunning()方法申请长时任务。你需要准备一个NotificationRequest对象，用于在后台运行时显示通知。
import backgroundTaskManager from '@ohos.resourceschedule.backgroundTaskManager';
import notificationManager from '@ohos.notificationManager';
// 创建NotificationRequest，具体参数请根据实际填写
let notificationRequest = {
id: 1,
content: {
title: '蓝牙钥匙运行中',
text: '正在通过BLE检测距离'
}
};
// 申请长时任务
try {
backgroundTaskManager.startBackgroundRunning(context, backgroundTaskManager.BackgroundMode.BLUETOOTH, notificationRequest)
.then(() => {
console.info('后台持续任务申请成功');
// 申请成功后，启动BLE扫描
startBLEScanInBackground();
})
.catch(err => {
console.error(`后台任务申请失败，错误码：${err.code}`);
});
} catch (error) {
console.error(`调用后台任务接口异常，错误码：${error.code}`);
}
注意几点：比如功耗控制：后台持续扫描BLE设备会显著增加耗电量，务必使用低功耗扫描模式（SCAN_MODE_LOW_POWER）并合理设置扫描间隔。
还有就是系统策略差异：不同鸿蒙设备厂商可能对后台任务有额外限制，请在实际目标设备上进行充分测试。
应用被系统杀死后BLE挂掉，是HarmonyOS 5/6上普遍会遇到的后台管理问题。这是系统为了平衡续航和性能而设定的规则：“无长时任务的应用退到后台不允许进行蓝牙扫描”，当应用被杀死或进入后台，系统会快速终止其蓝牙活动。
https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/standard-background-hardware
不过，通过合理使用系统提供的后台任务机制，完全可以解决这个问题。针对你的无感车钥匙场景，可以参考以下方案：
PartnerAgentExtensionAbility（APL Level 23+）
这是专为外设伙伴设备设计的进程拉起机制，可视为方案一的强力补充。该能力让应用在完全被杀死后，也能在蓝牙设备出现时被系统自动唤醒。
- 功能特点：
- 注册设备后，由系统级的
FusionConnectivity服务监听蓝牙设备。 - 当设备连接或断开时，系统会自动拉起
PartnerAgentExtensionAbility进程。 - 拉起后进程可运行3分钟，收到新通知可刷新计时器。
- 支持设备断连后重新拉起进程。
- 注册设备后，由系统级的
- 开发关键点：
- 需要实现
PartnerAgentExtensionAbility，在其中处理设备连接/断开后的逻辑。 - 在应用前台时调用
partnerAgent.bindDevice进行设备注册绑定。 - 使用前记得通过
partnerAgent.isPartnerAgentSupported()检查该能力是否可用。
- 需要实现
- 参考API版本：
@ohos.FusionConnectivity.partnerAgent从API version 23开始支持，与你的API 23版本完全匹配。
这个其实是 HarmonyOS NEXT 的后台机制导致的，不是 BLE 本身失效。
你现在：
App 在前台
→ BLE扫描正常
→ RSSI正常
→ 自动解锁/锁车正常
说明你的：
- BLE连接
- RSSI逻辑
- 扫描流程
基本都没问题。
⸻
真正的问题是：
App 被系统杀掉后
BLE能力一起被回收了
HarmonyOS NEXT 默认是不允许：
“普通三方应用”在被彻底杀死后继续长期后台 BLE 扫描的。
⸻
这里要区分几个状态：
1、应用切后台（未被杀）
这种情况下：
如果：
- Task还在
- Ability还活着
- 后台任务没被清理
BLE通常还能继续。
⸻
2、应用被系统彻底杀掉
比如：
- 手动上滑划掉
- 系统内存回收
- 一键清理
- 省电策略
这时候：
- JS Runtime没了
- Ability没了
- BLE Scanner没了
RSSI自然就停了。
⸻
3、真正的“车钥匙级后台能力”
这个其实属于：
系统级常驻能力
类似：
- 华为钱包车钥匙
- 数字车钥匙
- Find Device
- 系统IoT服务
这些不是普通应用权限。
⸻
所以：
普通三方 APP 想实现：
App 被彻底杀掉
还能持续BLE扫描
还能实时RSSI判断
目前 HarmonyOS NEXT 基本做不到。
⸻
因为这会涉及：
- 持续后台扫描
- 常驻进程
- 高功耗
- 隐私安全
- 系统保活
系统限制非常严格。
⸻
你现在能尝试的方向主要有几个：
1、前台任务（最现实）
使用：
AVSession
LiveView
Foreground Ability
或者持续前台服务化。
核心思想：
不要让系统真正杀掉
但：
HarmonyOS NEXT 目前不像 Android 那样开放传统 Foreground Service。
所以能力有限。
⸻
2、后台任务机制
可以研究：
- Background Task Manager
- 长时任务
- Efficiency Resources
但：
这些更偏：
- 上传
- 下载
- 同步
不是给你无限 BLE 扫描用的。
系统会限制。
⸻
3、与车厂系统级合作（真正车钥匙方案）
真正量产车钥匙一般不是：
普通三方 APP。
而是：
系统合作能力
比如：
- Huawei Wallet
- NearLink
- CarLink
- 星闪
- 数字车钥匙联盟
这类方案：
系统会给特殊保活能力。
⸻
4、退一步方案（行业里常见）
很多车钥匙其实并不是：
App彻底死亡还能工作
而是：
- App后台保活
- 开机自启
- 蓝牙连接维持
- 用户不手动划掉
来实现。
Android 上很多车钥匙其实也是这样。
⸻
5、API23 / HarmonyOS 6 目前现状
目前公开 SDK 下：
没有开放：
永久后台BLE RSSI扫描
这种系统级能力给普通应用。
尤其：
应用被彻底结束后继续扫描
基本属于系统应用权限范围。
⸻
一句话总结：
你现在的问题不是 RSSI 实现有问题，而是 HarmonyOS NEXT 不允许普通三方应用在被彻底杀掉后继续长期 BLE 扫描。真正的“无感车钥匙”能力通常属于系统级数字车钥匙方案，普通应用很难做到完全后台常驻。
应用进程被系统回收后，其持有的蓝牙GATT连接与扫描会话随之释放。HarmonyOS 的 BLE API 绑定进程生命周期，进程结束则蓝牙资源自动清理，故锁车失效。这是系统资源管理机制，非应用逻辑可控。
在 HarmonyOS NEXT 中，App 被杀死后 BLE 连接会断开，这是系统为省电和资源回收的正常行为。要实现后台持续监听 RSSI，需利用长时任务机制，并引导用户开启相关权限，但无法绝对防止进程被系统终止。
具体方案：
- 申请
ohos.permission.KEEP_BACKGROUND_RUNNING权限。 - 调用
requestSuspendDelay申请长时任务，reason设为bluetooth，并绑定一个前台通知。通知需要常驻，确保任务可见性。 - 在长时任务回调中维持 BLE 连接与 RSSI 监听。
- 可在首次使用时引导用户到设置页开启“允许后台活动”，减少被杀概率。
注意：若用户强制杀死应用或系统因资源紧张回收，任务仍会终止。此方案无法做到“杀掉 App 后依然运行”，仅实现退到后台时保持连接。
