🐛 Android – Delay in Data Fetching When Reconnecting Using Stored Device ID (Connection Persistence)

[rrubankumar-ctrl]

Prerequisites

• I checked the documentation and FAQ without finding a solution
• I checked to make sure that this issue has not already been filed

Expected Behavior

Description

We are using react-native-ble-plx and implementing BLE connection persistence on Android.

Our current approach:

Scan and connect to BLE device.

Store the device.id after successful connection.

On next app launch, directly call connectToDevice(deviceId) without scanning.

Current Behavior

connectToDevice(deviceId) takes longer when reconnecting without scan.

Sometimes fetching services and characteristics is delayed.

Checking manager.connectedDevices() also introduces delay.

Data read operations are slower compared to scan + connect flow.

Library version

latest

Device

android

Environment info

Platform: Android

Library: react-native-ble-plx (latest version)

Architecture: React Native

Steps to reproduce

1. …Previously, we were:

Scanning for the device

Connecting after scan

Maintaining connection globally

That architecture works much faster and more reliably on Android compared to direct reconnection using stored deviceId.
2. …

Formatted code sample or link to a repository

Observed Behavior

connectToDevice(deviceId) takes longer when reconnecting without scan.

Sometimes fetching services and characteristics is delayed.

Checking manager.connectedDevices() also introduces delay.

Data read operations are slower compared to scan + connect flow.

Relevant log output

Is reconnecting directly using stored deviceId expected to be slower on Android?

Is there any recommended pattern for Android-only persistent connection?

Is scanning before every reconnect the recommended approach for better performance?

Is there any optimization available to avoid delay when validating connection on multiple screens?

Additional information

Is reconnecting directly using stored deviceId expected to be slower on Android?

Is there any recommended pattern for Android-only persistent connection?

Is scanning before every reconnect the recommended approach for better performance?

Is there any optimization available to avoid delay when validating connection on multiple screens?

[aliberski]

@rrubankumar-ctrl Thanks for reporting — this behavior can be expected on Android.

Direct reconnect by stored device.id may be slower than scan + connect, and connectedDevices(...) is not a discovery/reconnect check (it only returns devices already connected in the current manager lifecycle).

Recommended pattern:

• use one shared BLE session manager (avoid reconnect checks from multiple screens)
• reconnect
• run discoverAllServicesAndCharacteristicsForDevice(...) once
• if startup speed is critical, do a short targeted scan before connect

If you can share a minimal repro + timing logs, we can check whether there’s a library-level optimization needed.