How to Build a Reliable BLE Reconnection State Machine

A Bluetooth Low Energy connection is temporary by nature. A device may move out of range, reboot, stop advertising, enter a low-power mode, lose power, or terminate the connection intentionally. The mobile operating system may also suspend the application, terminate its process, disable Bluetooth, revoke a permission, or delay background work.

At the Bluetooth link layer, a connection can also be lost when the supervision timeout expires because valid packets are no longer received. The application therefore needs to treat disconnection as an expected operating condition rather than an exceptional event.

A fragile implementation often follows this pattern:

Connect → Receive disconnected callback → Immediately call connect again → Repeat forever

This approach creates several problems:

• Multiple connection attempts may overlap.
• A stale GATT object may remain active.
• The device may not yet be advertising after a reboot.
• Services and notifications may not be restored.
• Aggressive scanning can increase battery consumption.
• The user interface may report “connected” before the application is operational.
• Temporary failures may become permanent retry loops.

A reliable BLE reconnection state machine solves these problems by making every step explicit.

A BLE reconnection state machine is a connection manager that represents the current Bluetooth Low Energy workflow as a defined state.

Instead of allowing screens, services, callbacks, and timers to call Bluetooth APIs independently, every event is sent to one central connection controller. That controller decides which transition and action are allowed.

A production-ready state machine may contain the following states:

• Idle
• WaitingForBluetooth
• Scanning
• Connecting
• DiscoveringServices
• ConfiguringConnection
• Ready
• Disconnecting
• RetryBackoff
• Stopped

The important distinction is that Connected and Ready are not the same state.

A mobile operating system may report that the physical GATT connection has been established, but the application may still need to:

• Discover GATT services.
• Validate required service and characteristic UUIDs.
• Enable characteristic notifications or indications.
• Restore the negotiated MTU or connection settings where applicable.
• Authenticate with the device.
• Synchronize application state.
• Verify that the device is ready to accept commands.

Android’s official BLE workflow similarly performs service discovery after the GATT connection callback reports a successful connection. Only after these steps succeed should the state machine enter Ready.

Idle

The application is not currently trying to communicate with the peripheral.

Typical entry conditions include:

• No device has been selected.
• Automatic reconnection is disabled.
• The user intentionally disconnected.
• The application has completed a short communication task.

Allowed transitions:

• Idle → Scanning
• Idle → Connecting
• Idle → WaitingForBluetooth
• Idle → Stopped

WaitingForBluetooth

The target device is known, but a prerequisite is unavailable.

Possible reasons include:

• Bluetooth is disabled.
• Required permissions are missing.
• The Bluetooth adapter is unavailable.
• The operating system has restricted background execution.

On Android 12 and later, applications generally need the appropriate BLUETOOTH_SCAN and BLUETOOTH_CONNECT runtime permissions for scanning and communication. Permission state should therefore be treated as an input to the state machine rather than as an unrelated UI concern.

Do not count time spent waiting for a user permission or Bluetooth activation as a failed reconnection attempt.

Scanning

The application is looking for the intended peripheral.

The scan should use the strongest available identity filter, such as:

• A known service UUID.
• Manufacturer-specific data.
• A stable application-level device identifier.
• A previously stored platform identifier.
• A combination of advertisement fields.

Do not rely only on the visible device name. Device names may be duplicated, changed, truncated, or absent from some advertisement packets.

Scanning should also have a defined timeout. Android recommends stopping a BLE scan after finding the target and avoiding continuous scan loops because scanning consumes battery power.

A practical scanning policy might be:

• Foreground scan: 10–15 seconds.
• Retry delay: controlled by the backoff policy.
• Stop immediately after the intended device is found.

Connecting

The state machine has selected a device and started a connection attempt.

Only one connection attempt should be owned by the connection manager at a time. Each attempt should have:

• attemptId
• deviceId
• startTime
• timeout
• connectionMode
• cancellationReason

The attemptId prevents a delayed callback from an older attempt from changing the state of a newer connection.

For example:

1. Attempt 17 starts.
2. Attempt 17 times out.
3. Attempt 18 starts.
4. A delayed callback from Attempt 17 arrives.
5. The callback is ignored because Attempt 17 is no longer active.

This is particularly important when Bluetooth callbacks arrive asynchronously.

DiscoveringServices

After the link connects, the application performs GATT service discovery and validates the expected profile.

The application should check that all required elements exist:

• Primary service UUID.
• Command characteristic.
• Response characteristic.
• Notification or indication characteristic.
• Configuration characteristic.
• Firmware or protocol version characteristic.

A connection should not enter Ready merely because some services were discovered. Missing required characteristics may indicate:

• The wrong device was selected.
• The peripheral is running incompatible firmware.
• The GATT database has changed.
• The service discovery result is incomplete.
• The application is using an outdated protocol definition.

Android exposes service discovery and characteristic access as separate steps after connection.

ConfiguringConnection

This state prepares the connected session for real application traffic.

Tasks may include:

• Enabling notifications or indications.
• Writing the Client Characteristic Configuration Descriptor.
• Negotiating protocol version.
• Authenticating the application.
• Reading initial device status.
• Restoring subscriptions.
• Synchronizing time or configuration.
• Confirming that the device is not busy with another client.

Each task should have its own timeout and error result.

Link connected ≠ application ready.

Ready

The BLE connection is fully initialized and the application can safely exchange business data.

When entering Ready, reset the consecutive retry counter:

retryAttempt = 0

Do not reset it immediately after the low-level connection succeeds. A device that repeatedly connects but fails during service discovery or subscription setup is not a successful recovery.

RetryBackoff

The connection attempt failed, but automatic reconnection is still allowed.

The state machine waits before trying again. The delay should increase after repeated failures to avoid:

• Rapid battery drain.
• Continuous radio usage.
• Duplicate GATT requests.
• Repeated connection pressure on the peripheral.
• Excessive logs and error callbacks.

Stopped

Automatic reconnection is disabled.

Typical reasons include:

• The user selected “Disconnect.”
• The user removed or forgot the device.
• The device is no longer assigned to the account.
• The application detected an incompatible protocol.
• A security or authentication failure requires user action.

Stopped must be different from an unexpected Disconnected state. Otherwise, an intentional disconnect may immediately trigger another connection attempt.

States describe the current condition. Events describe what happened.

Useful BLE state machine events include:

• StartRequested
• StopRequested
• BluetoothEnabled
• BluetoothDisabled
• PermissionGranted
• PermissionDenied
• DeviceDiscovered
• ScanTimedOut
• ConnectionSucceeded
• ConnectionFailed
• Disconnected
• ServicesDiscovered
• ServiceDiscoveryFailed
• NotificationsEnabled
• ConfigurationFailed
• RetryTimerExpired
• AppEnteredForeground
• AppEnteredBackground
• DeviceIdentityChanged

A transition matrix can then define deterministic behavior:

• Idle + StartRequested → Scanning: Start filtered scan.
• Scanning + DeviceDiscovered → Connecting: Stop scan and connect.
• Scanning + ScanTimedOut → RetryBackoff: Schedule retry.
• Connecting + ConnectionSucceeded → DiscoveringServices: Discover services.
• Connecting + ConnectionFailed → RetryBackoff: Release session.
• DiscoveringServices + ServicesDiscovered → ConfiguringConnection: Validate profile.
• ConfiguringConnection + NotificationsEnabled → Ready: Publish ready state.
• Ready + Disconnected → RetryBackoff: Record cause and retry.
• Any active state + StopRequested → Stopped: Cancel timers and disconnect.
• Any active state + BluetoothDisabled → WaitingForBluetooth: Release connection.

This structure makes BLE connection behavior easier to test because every transition has a known input and expected output.

A fixed one-second retry delay may work during development, but it behaves poorly when a device remains unavailable for several minutes.

A better approach is exponential backoff:

delay = min(maxDelay, baseDelay × 2^attempt)

Example delays:

• Attempt 0: 1 second.
• Attempt 1: 2 seconds.
• Attempt 2: 4 seconds.
• Attempt 3: 8 seconds.
• Attempt 4: 16 seconds.
• Attempt 5: 30 seconds.
• Further attempts: 30 seconds.

Add a small random jitter so multiple phones or gateways do not retry at exactly the same moment:

actualDelay = delay × random value between 0.8 and 1.2

Not every failure should use the same retry policy.

Retry quickly

Use a short retry when:

• The signal disappeared briefly.
• The device rebooted during a firmware operation.
• A transient connection timeout occurred.
• The user is actively waiting on the connection screen.

Retry slowly

Use a longer delay when:

• The device is repeatedly not found.
• Bluetooth communication has failed many times.
• The application is in the background.
• The peripheral may be powered off.

Do not retry automatically

Stop automatic BLE reconnection when:

• The user intentionally disconnected.
• Bluetooth permission was permanently denied.
• Device authentication failed repeatedly.
• The firmware or protocol is incompatible.
• The selected device identity is invalid.
• The account is no longer authorized to use the device.

A reliable BLE reconnection state machine should not always start from a full scan.

A recommended decision flow is:

Do we have a known platform device reference?
  → Yes: Can the platform reconnect directly?
  → No: Is the target already connected at system level?
  → No: Perform a filtered scan.
  → Connect after discovery.

On iOS, Core Bluetooth supports reconnecting by retrieving previously known peripherals, retrieving peripherals already connected to the system, or scanning again. Apple recommends considering the retrieval options before repeating discovery every time.

On Android, connectGatt() supports two modes. A direct connection uses autoConnect = false and attempts to connect immediately. An auto-connect request uses autoConnect = true and can reconnect when a known peripheral becomes available. The correct choice depends on the product workflow and background requirements.

Do not assume that autoConnect removes the need for a state machine. The application must still handle:

• Bluetooth being disabled.
• Missing permissions.
• Process termination.
• GATT initialization.
• Authentication.
• Service changes.
• User-requested disconnection.
• Retry cancellation.
• UI state.

When a connection attempt fails or is cancelled, the connection manager should clean up resources before starting a fresh attempt.

A safe cleanup sequence is:

1. Mark the current attempt as cancelled.
2. Cancel connection-related timers.
3. Ignore callbacks belonging to the old attempt.
4. Stop any active scan.
5. Request disconnection where appropriate.
6. Close or release the old GATT client.
7. Clear the active session reference.
8. Enter RetryBackoff or Stopped.

Cleanup should be idempotent. Calling it twice must not crash the application or create another connection attempt.

Avoid placing Bluetooth cleanup only inside a screen or view lifecycle. The BLE connection often outlives an individual page, and reconnection logic should belong to an application-level service, repository, connection manager, or device session controller.

After connecting, do not launch every setup operation simultaneously.

Use a controlled sequence:

Discover services
→ Validate required UUIDs
→ Enable response notifications
→ Wait for notification configuration result
→ Read protocol version
→ Authenticate
→ Read initial status
→ Enter Ready

Each operation should complete, fail, or time out before the next dependent operation begins.

This prevents a partially initialized connection from being presented as usable and makes it possible to identify exactly which initialization stage failed.

The same principle applies after reconnection. Do not assume that notification subscriptions, application authentication, cached device status, or unfinished commands remain valid across a new GATT session.

A connection may drop while a command is being sent.

Before automatically retrying the command, decide whether it is idempotent.

Usually safe to retry:

• Read current status.
• Read battery level.
• Read configuration.
• Set an absolute target value.
• Request the latest measurement.

Potentially unsafe to retry:

• Dispense one item.
• Unlock once.
• Start a motor cycle.
• Increment a counter.
• Submit a payment-related action.
• Trigger a firmware step.

For non-idempotent commands, use an application-level transaction ID and acknowledgement protocol:

Mobile app sends command with transactionId
→ Device records or processes transactionId
→ Device returns acknowledgement with transactionId
→ App checks whether the transaction completed before retrying

Reliable BLE reconnection is not only about restoring the radio link. It must also preserve the correctness of the product workflow.

Android applications should explicitly model:

• Bluetooth runtime permissions.
• Bluetooth adapter state.
• Foreground and background execution.
• The lifetime of the application process.
• Direct connection versus auto-connect behavior.
• GATT connection and service-discovery callbacks.
• Long-running notification requirements.

For long-running connected-device communication, current Android guidance includes options such as CompanionDeviceService and an appropriately declared foreground service. A connection owned only by an application process is lost when that process is killed.

A simplified Android-oriented flow is:

Check BLUETOOTH_CONNECT permission
→ Check Bluetooth adapter
→ Resolve known device or scan
→ Call connectGatt()
→ Receive onConnectionStateChange()
→ Discover services
→ Configure notifications
→ Validate application protocol
→ Ready

The connection manager should remain the single owner of the active BluetoothGatt instance.

On iOS, store the peripheral identifier assigned by Core Bluetooth after the device is discovered.

A practical reconnection order is:

1. Retrieve the known peripheral by identifier.
2. Check peripherals already connected to the system.
3. Scan using the required service UUID.
4. Connect when the intended peripheral is found.

Apple documents these as the primary Core Bluetooth reconnection approaches.

When the product requires Bluetooth activity in the background, configure and test the appropriate Core Bluetooth background mode. Background behavior should still be treated as system-managed rather than as unlimited application execution.

The state machine must also handle central manager state changes, including:

• poweredOn
• poweredOff
• resetting
• unauthorized
• unsupported

A connection request should only start when the central manager is ready.

The following language-neutral pseudocode focuses on four production concerns:

• one owner for all connection operations
• explicit state transitions
• timeout handling for every transitional state
• rejection of stale asynchronous callbacks

state = Idle
retryAttempt = 0
activeAttemptId = null

function handle(event):
    if event is StopRequested:
        stopEverything()
        transitionTo(Stopped)
        return

    if event.attemptId exists
       and event.attemptId != activeAttemptId:
        recordIgnoredStaleEvent(event)
        return

    switch state:
        case Idle:
            if event is StartRequested:
                if prerequisitesAvailable():
                    beginScan()
                else:
                    transitionTo(WaitingForBluetooth)

        case WaitingForBluetooth:
            if event is PrerequisitesAvailable:
                beginScan()

        case Scanning:
            if event is DeviceDiscovered:
                stopScan()
                activeAttemptId = newAttemptId()
                transitionTo(Connecting)
                startStateTimeout(Connecting)
                connect(event.device, activeAttemptId)
            else if event is StateTimedOut:
                scheduleRetry("scan_timeout")

        case Connecting:
            if event is ConnectionSucceeded:
                transitionTo(DiscoveringServices)
                startStateTimeout(DiscoveringServices)
                discoverServices(activeAttemptId)
            else if event is ConnectionFailed:
                scheduleRetry(event.reason)
            else if event is StateTimedOut:
                scheduleRetry("connection_timeout")

        case DiscoveringServices:
            if event is ServicesDiscovered:
                if requiredProfileExists(event.services):
                    transitionTo(ConfiguringConnection)
                    startStateTimeout(ConfiguringConnection)
                    configureConnection(activeAttemptId)
                else:
                    failPermanently("incompatible_gatt_profile")
            else if event is ServiceDiscoveryFailed:
                scheduleRetry(event.reason)
            else if event is StateTimedOut:
                scheduleRetry("service_discovery_timeout")

        case ConfiguringConnection:
            if event is ConfigurationSucceeded:
                cancelStateTimeout()
                retryAttempt = 0
                transitionTo(Ready)
            else if event is ConfigurationFailed:
                scheduleRetry(event.reason)
            else if event is StateTimedOut:
                scheduleRetry("configuration_timeout")

        case Ready:
            if event is Disconnected:
                scheduleRetry(event.reason)

        case RetryBackoff:
            if event is RetryTimerExpired:
                retryAttempt += 1
                beginScan()

function beginScan():
    activeAttemptId = newAttemptId()
    transitionTo(Scanning)
    startStateTimeout(Scanning)
    startFilteredScan(activeAttemptId)

function scheduleRetry(reason):
    cancelStateTimeout()
    invalidateActiveAttempt()
    releaseSession()

    if shouldRetry(reason):
        delay = calculateBackoff(retryAttempt)
        transitionTo(RetryBackoff)
        startRetryTimer(delay)
    else:
        failPermanently(reason)

function transitionTo(nextState):
    recordTransition(state, nextState)
    state = nextState

This is an architectural model rather than drop-in platform code. In a production implementation, stopEverything() must cancel scanning, retry timers, state timers, and the active connection. Every scan, connection, discovery, and configuration callback must carry the attempt identifier that created it. A callback from an older attempt is diagnostic data, not a valid state transition.

Never allow the connection manager to remain indefinitely in:

• Scanning
• Connecting
• DiscoveringServices
• ConfiguringConnection
• Disconnecting

Suggested starting values are product-specific, but an initial policy might be:

• Foreground scan: 10–15 seconds.
• Direct connection: 10–20 seconds.
• Service discovery: 10 seconds.
• Notification setup: 5–10 seconds.
• Application authentication: 10 seconds.
• Graceful disconnect: 3–5 seconds.

These values should be adjusted using real-device data rather than treated as universal BLE limits.

A reliable BLE connection manager should produce structured diagnostics.

Record fields such as:

• deviceId
• platform
• OS version
• Phone model
• App version
• Firmware version
• Previous state
• Next state
• Event
• Failure reason
• Attempt number
• Scan duration
• Connection duration
• Initialization duration
• Time to Ready
• Signal strength
• Background state
• Permission state

Useful production metrics include:

• First-attempt connection success rate.
• Median time to Ready.
• Reconnection success rate.
• Reconnect attempts per session.
• Service discovery failure rate.
• Notification setup failure rate.
• Unexpected disconnections per hour.
• Failures by phone model.
• Failures by firmware version.

Without these measurements, “BLE is unstable” remains too broad to diagnose.

A state machine should be tested both with automated transition tests and with real Bluetooth hardware.

Core reconnection scenarios

Test the following cases:

• Move the device out of range and bring it back.
• Power off the peripheral and restart it.
• Disable and re-enable Bluetooth on the phone.
• Deny and restore Bluetooth permission.
• Put the mobile application in the background.
• Terminate and restart the application.
• Reboot the phone.
• Reboot the peripheral during service discovery.
• Disconnect during notification configuration.
• Disconnect while a command is awaiting acknowledgement.
• Change the device firmware or GATT profile.
• Keep the peripheral unavailable for several minutes.
• Trigger repeated rapid disconnects.
• Disconnect intentionally from the user interface.
• Test multiple peripherals with similar names.

Device coverage

Test across:

• Multiple Android manufacturers.
• Several Android OS versions.
• Current and previous iOS versions.
• Low and high battery levels.
• Weak and strong signal conditions.
• Foreground and background operation.
• Different peripheral firmware versions.

A BLE reconnection implementation that works on one development phone is not yet production-ready.

Retrying immediately forever

This drains battery and may keep both the application and peripheral in a failure loop.

Treating connected as ready

The physical connection may exist while services, notifications, or authentication are incomplete.

Starting overlapping scans and connections

Every scan, timer, callback, and connection attempt should belong to one state-machine session.

Identifying the device by name only

Names are not guaranteed to be unique or stable.

Reusing stale session state

A new connection should rebuild the required GATT and application-level state.

Automatically retrying every command

A command may already have completed before the connection was lost.

Reconnecting after an intentional disconnect

User intent must override the automatic retry policy.

Hiding every failure from the user

Automatic recovery is useful, but the interface should explain when Bluetooth is disabled, permission is missing, the device is incompatible, or manual action is required.

Before releasing a connected product, confirm that the BLE reconnection state machine:

• Has explicit states and events.
• Has one owner for BLE connection operations.
• Distinguishes Connected from Ready.
• Uses bounded scanning.
• Uses exponential backoff with jitter.
• Cancels outdated connection attempts.
• Handles Bluetooth and permission changes.
• Restores services and notifications.
• Validates the expected GATT profile.
• Protects non-idempotent commands.
• Stops retrying after user-requested disconnection.
• Records transition and failure diagnostics.
• Works after application and device restarts.
• Has been tested on real Android and iOS devices.

Reliable BLE reconnection is not achieved by repeatedly calling a connection API. It requires a deterministic state machine that coordinates device discovery, connection attempts, GATT service discovery, notification setup, application authentication, retry backoff, command recovery, and user intent.

By separating Scanning, Connecting, DiscoveringServices, ConfiguringConnection, Ready, and RetryBackoff, a connected-device application becomes easier to debug, test, maintain, and extend.

A well-designed BLE reconnection state machine does more than restore a wireless link. It restores the complete product session and returns the application to a verified, usable state.

Building or repairing a BLE-connected application? YUNJI provides BLE app development, device protocol integration, GATT troubleshooting, real-device testing, and inherited IoT project takeover services.