If the APP is killed, the task cannot be executed.

[zhujianguo]

I have a requirement that when the APP is manually swiped away, it should be able to perform some network tasks in the background, such as synchronizing Google health data to the server.
It's fine to go back to the background now. If you close the app, the task won't be triggered.

[vietnguyentuan2019]

Hi @zhujianguo, thanks for reaching out.

To help us diagnose the issue more accurately, could you provide a bit more context?

1. Are you testing this on iOS or Android?
2. If Android, which device brand/model are you testing on (e.g., Pixel, Xiaomi, Samsung)?
3. Are you using a custom DartWorker to synchronize the Google health data?

In the meantime, please note that this behavior is generally not a bug in the plugin, but rather an OS-level restriction imposed by both iOS and certain Android manufacturers when an app is manually force-killed (swiped away from the recent apps list).

1. iOS Behavior (Apple's Policy)
If a user manually force-quits an app by swiping it away in the App Switcher, iOS completely stops the app and will not trigger any scheduled background tasks (BGAppRefreshTask or BGProcessingTask) until the user manually launches the app again. This is a strict Apple privacy/battery policy, and no background Dart code can run in this state.
(Note: The only exception is using HttpUploadWorker/HttpDownloadWorker with useBackgroundSession: true which is handled entirely by the OS outside the app process, but this won't help with custom Dart logic like Health data sync).

2. Android Behavior (OEM Battery Optimizations)
On stock Android (like Pixel), WorkManager tasks survive swiping the app away. However, on most custom Android ROMs (Xiaomi, Huawei, Oppo, Vivo, Samsung, etc.), swiping an app away is treated by the OS as a Force Stop. When an app is Force Stopped, the OS cancels all its pending WorkManager tasks and alarms.
To make it work on these devices after swiping away, you need to instruct your users to:

• Enable "Auto-start" (or "Allow background activity") for your app in the device settings.
• Change the Battery Optimization setting for your app to "Unrestricted".

Recommendation for your use case:
For synchronizing Health data, the best practice is to design your app to sync opportunistically. It will sync perfectly fine when the app is simply sent to the background (pressing the home button without swiping it away). When the user opens the app again, you can immediately trigger a foreground sync to catch up on any missed data.

For more details on background restrictions, please check our documentation:

• iOS Background Limits Guide
• Troubleshooting Android Battery Optimizations

[zhujianguo]

你好@zhujianguo感谢您的联系。

为了帮助我们更准确地诊断问题，您能否提供更多背景信息？

1. 您是在iOS还是Android 系统上测试？
2. 如果是安卓系统，请问您测试的设备品牌/型号是什么（例如，Pixel、小米、三星）？
3. 您是否使用自定义方法DartWorker同步 Google 健康数据？

同时，请注意，这种行为通常不是插件的错误，而是 iOS 和某些 Android 制造商在手动强制关闭应用程序（从最近使用的应用程序列表中滑动关闭）时施加的操作系统级别的限制。

1. iOS 行为（苹果政策） 如果用户在应用切换器中手动滑动关闭应用，iOS 会完全停止该应用，并且不会触发任何计划的后台任务（BGAppRefreshTask例如setTimeout 或 setTimeout BGProcessingTask），直到用户手动再次启动该应用。这是苹果严格的隐私/电池政策，任何后台 Dart 代码都无法在此状态下运行。 （注意：唯一的例外是使用HttpUploadWorker``setTimeout``HttpDownloadWorker或 setTimeout useBackgroundSession: true，这完全由操作系统在应用进程之外处理，但这对自定义 Dart 逻辑（例如健康数据同步）没有帮助。）

2. Android 系统行为（OEM 电池优化） 在原生 Android 系统（例如 Pixel）中，即使用户滑动关闭应用，WorkManager 任务仍然会继续运行。然而，在大多数定制 Android ROM（例如小米、华为、OPPO、vivo、三星等）中，滑动关闭应用会被操作系统视为强制停止。当应用被强制停止时，操作系统会取消所有待处理的 WorkManager 任务和提醒。 为了使应用在这些设备上滑动关闭后仍能正常工作，您需要指导用户：

• 在设备设置中为您的应用启用**“自动启动” （或“允许后台活动”）。**
• 将应用的电池优化设置更改为**“无限制”**。

针对您的使用场景的建议： 同步健康数据的最佳实践是将应用设计为按需同步。当应用被切换到后台（例如，按下主屏幕按钮而不是滑动关闭应用）时，同步功能可以正常使用。当用户再次打开应用时，您可以立即触发前台同步，以补齐任何遗漏的数据。

有关背景限制的更多详情，请查阅我们的文档：

• iOS后台限制指南
• Android电池优化故障排除

Thank you. I've found the problem. However, I discovered that it occurs when triggering background tasks in flutter_reactive_ble, and this can result in the Bluetooth connection being disconnected.

[zhujianguo]

I made this adjustment and it will prevent the Bluetooth connection from being disconnected when the Flutter engine is being destroyed.

[vietnguyentuan2019]

Hi @zhujianguo 👋

Great investigation — this is confirmed as a real bug, and it's been fixed in v1.1.2 (releasing today).

---

Root Cause

FlutterEngineManager was creating the background Flutter engine with the default constructor:

val flutterEngine = FlutterEngine(context.applicationContext)

Flutter's default constructor calls GeneratedPluginRegistrant.registerWith(engine), which registers every plugin in the host app — including flutter_reactive_ble, camera, audio, and any other plugin — into the background engine.

When that background engine was later destroyed (after 5 minutes idle, or when the task completes with autoDispose: true), each plugin runs its onDetachedFromEngine() cleanup. BLE plugins call things like gatt.disconnect() / gatt.close() / unregister Bluetooth callbacks against the same Android BluetoothManager system service that your main engine's plugin is actively using — which disconnects your active BLE connection.

---

Fix in v1.1.2

The background engine is now created with automaticallyRegisterPlugins = false:

val flutterEngine = FlutterEngine(
    context.applicationContext,
    FlutterInjector.instance().flutterLoader(),
    FlutterJNI(),
    emptyArray(),
    automaticallyRegisterPlugins = false,  // ← the fix
    waitForRestorationData = false
)

The background engine only needs the single dev.brewkits/dart_worker_channel MethodChannel, which is wired up manually. No BLE plugin, no camera plugin, nothing else gets initialized or cleaned up.

---

Dart-level mitigation (for any version)

If you can't upgrade immediately, set autoDispose: true on your DartWorker to minimize how long the background engine lives:

worker: DartWorker(
  callbackId: 'health-sync',
  input: {'userId': userId},
  autoDispose: true, // engine is destroyed immediately after task completes
),

This reduces the window during which the background engine exists and could interfere with BLE resources.

---

The fix is included in v1.1.2 — please upgrade and let me know if it resolves the issue for you. Thanks again for the detailed report! 🙏

[zhujianguo]

你好@zhujianguo👋

调查结果非常出色——这已被证实是一个真正的漏洞，并且已在v1.1.2 版本（今天发布）中修复。

根本原因

FlutterEngineManager正在使用默认构造函数创建后台 Flutter 引擎：

val flutterEngine = FlutterEngine(context.applicationContext)
Flutter 的默认构造函数GeneratedPluginRegistrant.registerWith(engine)会将宿主应用程序中的每个插件（包括flutter_reactive_ble摄像头、音频和任何其他插件）注册到后台引擎中。

当后台引擎稍后被销毁（闲置 5 分钟后，或任务完成时autoDispose: true），每个插件都会运行其onDetachedFromEngine()清理程序。BLE 插件会调用类似gatt.disconnect()`` gatt.close()// unregister Bluetooth callbacks 这样的函数，针对的是主引擎插件正在使用的同一个 AndroidBluetoothManager系统服务——这会断开你当前的 BLE 连接。

v1.1.2 版本已修复

后台引擎现已创建完成automaticallyRegisterPlugins = false：

val flutterEngine = FlutterEngine(
context.applicationContext,
FlutterInjector.instance().flutterLoader(),
FlutterJNI(),
emptyArray(),
automaticallyRegisterPlugins = false, // ← the fix
waitForRestorationData = false
)
后台引擎只需要一个dev.brewkits/dart_worker_channel手动连接的 MethodChannel。无需 BLE 插件，无需摄像头插件，也不会初始化或清理其他任何东西。

Dart 级别的缓解措施（适用于任何版本）

如果无法立即升级，请autoDispose: true尽量DartWorker缩短后台引擎的运行时间：

worker: DartWorker(
callbackId: 'health-sync',
input: {'userId': userId},
autoDispose: true, // engine is destroyed immediately after task completes
),
这会缩短后台引擎运行的时间窗口，并可能干扰 BLE 资源。

v1.1.2版本已修复此问题，请升级并告知我是否解决了您的问题。再次感谢您提供的详细报告！🙏

Thank you!!!