BLE Battery Drain on Android: Profiling and Optimization for Wearable Apps

DEVSFLOW Neuro ยท April 2026

Battery life is the single most common complaint from users of BLE-connected wearable apps. A neurotechnology headband that drains a phone from 80% to 40% during a 30-minute session will get uninstalled, no matter how good the data is. Working with neurotechnology and medical device companies across Toronto and throughout Canada, our team at DEVSFLOW has seen this pattern repeat: the BLE integration works, the data streams correctly, but battery consumption kills the user experience.

The challenge is that BLE battery optimization on Android is not one problem. It is a collection of interrelated problems: scanning strategy, connection parameters, wake lock hygiene, notification handling, and OEM-specific quirks that interact in ways that are difficult to predict from documentation alone. This guide covers the profiling tools and optimization strategies that actually move the needle for production wearable apps.

Using Battery Historian for BLE Analysis

Before optimizing anything, you need to know where the power is going. Android's Battery Historian is the most underused tool in the BLE developer's toolkit. It provides a timeline view of every wake lock, scan event, and radio state change on the device, broken down by app.

To capture a useful bugreport for BLE analysis, reset the battery stats first, then run your target scenario:

// Reset battery stats before profiling
adb shell dumpsys batterystats --reset

// Run your BLE scenario for a fixed duration (e.g., 15 minutes)
// Then capture the bugreport
adb bugreport bugreport.zip

Upload the resulting zip to the Battery Historian web tool (or run it locally via Docker). The key lanes to focus on for BLE apps are:

One pattern we see repeatedly: an app starts a BLE scan to find a device, connects successfully, but never stops the scan. On Battery Historian, this shows up as a continuous blue bar in the Bluetooth scanning lane that runs for the entire session. Stopping the scan immediately after connection can reduce BLE-related battery consumption by 30-50% on its own.

Scan Duty Cycle and Its Impact on Battery

BLE scanning is the single most expensive operation your app performs in terms of battery, often more expensive than the actual data transfer over an established connection. Android provides three scan modes through ScanSettings, and the differences in power consumption are dramatic.

SCAN_MODE_LOW_LATENCY runs the radio at nearly 100% duty cycle. It finds devices faster, but it will consume roughly 150-200 mW continuously on most hardware. SCAN_MODE_LOW_POWER runs at approximately 10% duty cycle (scanning for about 500ms every 5000ms on most chipsets), consuming around 20-30 mW. SCAN_MODE_BALANCED sits between the two at roughly 25% duty cycle.

For a wearable neurotech app, the scan strategy should adapt to context:

class AdaptiveScanner(
    private val bluetoothLeScanner: BluetoothLeScanner,
    private val targetDeviceAddress: String?
) {
    private var scanCallback: ScanCallback? = null

    fun startUserInitiatedScan() {
        // User just tapped "Connect" - use low latency for fast discovery
        val settings = ScanSettings.Builder()
            .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
            .setMatchMode(ScanSettings.MATCH_MODE_AGGRESSIVE)
            .build()

        startScanWithTimeout(settings, timeoutMs = 10_000L)
    }

    fun startBackgroundReconnectScan() {
        // App is trying to reconnect to a known device
        val settings = ScanSettings.Builder()
            .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER)
            .setMatchMode(ScanSettings.MATCH_MODE_STICKY)
            .setCallbackType(ScanSettings.CALLBACK_TYPE_FIRST_MATCH)
            .build()

        // If we know the device address, filter for it specifically
        val filters = targetDeviceAddress?.let {
            listOf(
                ScanFilter.Builder()
                    .setDeviceAddress(it)
                    .build()
            )
        } ?: emptyList()

        startScanWithTimeout(settings, timeoutMs = 30_000L, filters = filters)
    }

    private fun startScanWithTimeout(
        settings: ScanSettings,
        timeoutMs: Long,
        filters: List<ScanFilter> = emptyList()
    ) {
        stopCurrentScan()

        scanCallback = object : ScanCallback() {
            override fun onScanResult(callbackType: Int, result: ScanResult) {
                // Handle result, then stop scanning immediately
                stopCurrentScan()
            }
        }

        bluetoothLeScanner.startScan(filters, settings, scanCallback)

        // Always enforce a hard timeout
        scope.launch { delay(timeoutMs); stopCurrentScan() }
    }

    fun stopCurrentScan() {
        scanCallback?.let {
            try {
                bluetoothLeScanner.stopScan(it)
            } catch (e: IllegalStateException) {
                // BT adapter may have been turned off
            }
            scanCallback = null
        }
    }

    private val scope = CoroutineScope(Dispatchers.Main + SupervisorJob())
}

The critical detail here is the hard timeout on every scan. Without it, a scan that never finds its target will run indefinitely. We have debugged production apps where a failed reconnection scan ran for hours in the background because the timeout was missing.

Opportunistic and Batched Scanning

Android 8.0+ introduced SCAN_MODE_OPPORTUNISTIC, which is one of the most valuable and least-documented scan modes for battery optimization. An opportunistic scan piggybacks on scan results from other apps on the device. Your app does not trigger the radio at all. If another app (or the system) is already scanning, you receive their results filtered through your scan filters.

fun startOpportunisticScan(targetServiceUuid: ParcelUuid) {
    val settings = ScanSettings.Builder()
        .setScanMode(ScanSettings.SCAN_MODE_OPPORTUNISTIC)
        .build()

    val filters = listOf(
        ScanFilter.Builder()
            .setServiceUuid(targetServiceUuid)
            .build()
    )

    bluetoothLeScanner.startScan(filters, settings, scanCallback)
}

Opportunistic scanning is ideal for "ambient discovery" scenarios where you want to detect a nearby device without actively draining battery. The tradeoff is that you have no control over when or whether results arrive. Combine it with a periodic low-power scan as a fallback:

// Start opportunistic scan immediately (zero battery cost)
startOpportunisticScan(targetServiceUuid)

// Every 2 minutes, run a brief low-power scan as fallback
val workRequest = PeriodicWorkRequestBuilder<BleScanWorker>(
    repeatInterval = 2,
    repeatIntervalTimeUnit = TimeUnit.MINUTES,
    flexInterval = 1,
    flexTimeUnit = TimeUnit.MINUTES
).build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "ble_reconnect_scan",
    ExistingPeriodicWorkPolicy.KEEP,
    workRequest
)

Batched scanning (setReportDelay()) is another useful lever. Instead of delivering each scan result immediately (which wakes the CPU each time), you can batch results and deliver them at intervals. For a reconnection scan where latency is not critical, a report delay of 5-10 seconds significantly reduces CPU wake-ups:

val settings = ScanSettings.Builder()
    .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER)
    .setReportDelay(5000L) // Batch results every 5 seconds
    .build()

When using batched scanning, results are delivered to onBatchScanResults() instead of onScanResult(). Make sure your callback handles both paths.

Wake Lock Management for BLE Apps

Wake locks are a frequent source of hidden battery drain in BLE apps. The Android BLE stack itself does not require you to hold wake locks for most operations, but many developers add them defensively out of concern that the system will suspend the process during a critical GATT operation.

The reality is more nuanced. BLE callbacks (onCharacteristicChanged, onConnectionStateChange, etc.) are delivered on the Binder thread and will wake your process if it has been put to sleep. You do not need a wake lock to receive BLE notifications while your app is in the foreground or running a foreground service.

Where wake locks become necessary is in the brief window between receiving a BLE callback and completing your processing of that data. If you receive an EEG data packet and need to write it to disk or run a signal processing pipeline, the system could suspend your process before that work completes. For this narrow case, use a partial wake lock with a strict timeout:

class BleDataProcessor(context: Context) {
    private val wakeLock: PowerManager.WakeLock =
        (context.getSystemService(Context.POWER_SERVICE) as PowerManager)
            .newWakeLock(
                PowerManager.PARTIAL_WAKE_LOCK,
                "devsflow:ble_data_processing"
            ).apply {
                setReferenceCounted(false)
            }

    fun onDataReceived(data: ByteArray) {
        // Acquire wake lock with a hard timeout
        // 500ms is enough for most data processing tasks
        wakeLock.acquire(500L)

        try {
            processData(data)
            writeToLocalStorage(data)
        } finally {
            if (wakeLock.isHeld) {
                wakeLock.release()
            }
        }
    }

    private fun processData(data: ByteArray) {
        // Signal processing, feature extraction, etc.
    }

    private fun writeToLocalStorage(data: ByteArray) {
        // Persist to Room/SQLite
    }
}

The acquire(timeoutMs) overload is essential. A wake lock without a timeout that is never released (due to an exception, a missed code path, or a race condition) will keep the CPU awake indefinitely. Battery Historian will show this as a flat wake lock bar spanning hours, and users will see your app at the top of the battery usage screen.

One pattern to avoid: holding a wake lock for the entire duration of a BLE connection. We have seen this in codebases where the developer was concerned about missing notifications during Doze mode. A foreground service with an ongoing notification is the correct solution for keeping your process alive during an active session, not a wake lock.

Connection Keep-Alive and Parameter Optimization

Once a BLE connection is established, the connection interval becomes the primary driver of power consumption. The connection interval determines how often the phone's radio wakes up to exchange data with the peripheral. Android's default connection interval for BLE is typically 30-50ms (depending on OEM), which is far more aggressive than most wearable apps need.

You can request a different connection priority through requestConnectionPriority():

// During active data streaming (e.g., EEG recording)
gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH)
// Connection interval: ~11.25ms - 15ms. High throughput, high power.

// During idle periods (device connected but not streaming)
gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER)
// Connection interval: ~100ms - 500ms. Minimal data exchange needed.

// Default balanced mode
gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_BALANCED)
// Connection interval: ~30ms - 50ms.

The key insight is that connection priority should change dynamically based on what the app is doing. When a neurotechnology device is actively streaming EEG data at 250 Hz, you need CONNECTION_PRIORITY_HIGH to avoid filling the peripheral's buffer. But when the user is reviewing results and the device is idle, switching to CONNECTION_PRIORITY_LOW_POWER reduces radio wake-ups by 5-10x.

class ConnectionManager(private val gatt: BluetoothGatt) {
    enum class SessionState { STREAMING, IDLE, CONFIGURING }

    fun onSessionStateChanged(newState: SessionState) {
        val priority = when (newState) {
            SessionState.STREAMING -> BluetoothGatt.CONNECTION_PRIORITY_HIGH
            SessionState.CONFIGURING -> BluetoothGatt.CONNECTION_PRIORITY_BALANCED
            SessionState.IDLE -> BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER
        }
        gatt.requestConnectionPriority(priority)
    }
}

Note that requestConnectionPriority() is a request, not a command. The actual connection parameters are negotiated between the phone and the peripheral. If the peripheral firmware does not accept the requested parameters, the connection interval will remain unchanged. Always verify the actual parameters through the onConnectionUpdated() callback (API 26+) or by monitoring the HCI log.

Measuring BLE Power Consumption Across OEMs

One of the most frustrating aspects of Android BLE development is that power consumption varies significantly across manufacturers. A scan configuration that draws 25 mW on a Pixel 8 might draw 40 mW on a Samsung Galaxy S24 and 60 mW on a Xiaomi device. This is because each OEM uses different Bluetooth chipsets, different firmware, and different power management policies.

For accurate power measurement, there are three approaches ranked by reliability:

  1. Hardware power monitor (Monsoon/Otii Arc): The gold standard. You remove the phone's battery, connect the power monitor in its place, and measure actual current draw at the milliamp level. This gives you real numbers, not estimates.
  2. Android's on-device power profiling (API 31+): The PowerStats API and the adb shell dumpsys batterystats output provide per-subsystem power estimates based on the device's power profile. These are estimates, but they are consistent enough for A/B comparisons on the same device.
  3. Battery percentage delta over time: The least precise method, but sometimes the most practical. Run your scenario for a fixed duration on a fully charged device and measure the percentage drop. You need at least 15-20 minute sessions for meaningful results due to the granularity of the battery fuel gauge.

When building apps for Canadian clients like RE-AK Technologies and CLEIO, we maintain a test matrix of at least four devices representing different chipset families: Qualcomm (most Samsung and OnePlus devices), Google Tensor (Pixel), MediaTek (many mid-range devices), and Samsung Exynos (international Galaxy variants). The BLE stack behavior differs enough across these chipsets that testing on only one family will miss real-world problems.

Some OEM-specific behaviors worth noting:

Balancing Data Freshness with Battery Life

The fundamental tension in any BLE wearable app is between data freshness and battery life. A neurotechnology device streaming EEG data needs real-time delivery with minimal latency. But a fitness tracker that reports heart rate every few minutes does not need a persistent high-priority connection.

The most effective strategy is to define explicit "power profiles" for your app and switch between them based on user activity:

sealed class PowerProfile {
    abstract val scanMode: Int
    abstract val connectionPriority: Int
    abstract val notificationBatchingMs: Long
    abstract val useWakeLock: Boolean

    // Active session: user is recording EEG data
    data object ActiveRecording : PowerProfile() {
        override val scanMode = ScanSettings.SCAN_MODE_LOW_LATENCY
        override val connectionPriority = BluetoothGatt.CONNECTION_PRIORITY_HIGH
        override val notificationBatchingMs = 0L // Real-time delivery
        override val useWakeLock = true
    }

    // Monitoring: device connected, periodic data checks
    data object PassiveMonitoring : PowerProfile() {
        override val scanMode = ScanSettings.SCAN_MODE_LOW_POWER
        override val connectionPriority = BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER
        override val notificationBatchingMs = 5000L
        override val useWakeLock = false
    }

    // Standby: app open, device not connected, ready to reconnect
    data object Standby : PowerProfile() {
        override val scanMode = ScanSettings.SCAN_MODE_OPPORTUNISTIC
        override val connectionPriority = BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER
        override val notificationBatchingMs = 10000L
        override val useWakeLock = false
    }
}

class BleSessionManager {
    private var currentProfile: PowerProfile = PowerProfile.Standby

    fun transitionTo(profile: PowerProfile) {
        if (profile == currentProfile) return

        currentProfile = profile

        // Reconfigure all BLE parameters atomically
        updateScanSettings(profile.scanMode)
        updateConnectionPriority(profile.connectionPriority)
        updateNotificationBatching(profile.notificationBatchingMs)
        updateWakeLockPolicy(profile.useWakeLock)

        logProfileTransition(profile)
    }

    private fun logProfileTransition(profile: PowerProfile) {
        // Log transitions for debugging and power analysis
        Log.d("BleSession", "Power profile: ${profile::class.simpleName}")
    }

    private fun updateScanSettings(scanMode: Int) { /* ... */ }
    private fun updateConnectionPriority(priority: Int) { /* ... */ }
    private fun updateNotificationBatching(batchMs: Long) { /* ... */ }
    private fun updateWakeLockPolicy(useWakeLock: Boolean) { /* ... */ }
}

This approach makes power behavior explicit and auditable. When a user reports excessive battery drain, you can examine the profile transition log to see whether the app was stuck in an active recording profile when it should have been in standby.

Practical Optimization Checklist

After working on dozens of BLE wearable and neurotech projects, here is the checklist we apply to every new project:

  1. Stop scanning after connection. This is the single highest-impact change. Verify with Battery Historian that no scan is running during an active connection.
  2. Set hard timeouts on every scan. Never start a scan without a corresponding timeout that will stop it. 10-30 seconds is typical for user-initiated scans; 5-10 seconds for background reconnection scans.
  3. Use scan filters. Filtered scans (by device address, service UUID, or manufacturer data) consume less power than unfiltered scans because the filtering happens in the Bluetooth chipset firmware, not in your app's process.
  4. Switch connection priority dynamically. Use HIGH only during active data transfer. Switch to LOW_POWER during idle periods.
  5. Audit wake locks. Search your codebase for every PowerManager.newWakeLock() call. Ensure each has a timeout and is released in a finally block.
  6. Use a foreground service, not wake locks, for long sessions. A foreground service with an ongoing notification keeps your process alive without preventing the CPU from sleeping between BLE events.
  7. Request battery optimization exemption carefully. Use REQUEST_IGNORE_BATTERY_OPTIMIZATIONS only if your app genuinely needs it (medical devices often do). Guide users through OEM-specific settings where the standard API is not enough.
  8. Profile on at least three OEMs. What works on a Pixel may fail on Samsung or Xiaomi. Include at least one device with aggressive background app killing in your test matrix.
  9. Measure before and after. Every optimization should be validated with a before/after measurement using Battery Historian or a power monitor. Intuition about what saves power is often wrong.

Battery optimization is not a one-time task. Every new feature that interacts with BLE (new data streams, background sync, firmware updates) should be profiled for its impact on power consumption. The teams that ship wearable apps with good battery life are the ones that treat power as a first-class metric, measured and tracked alongside latency and throughput.

Struggling with BLE battery drain in your wearable or neurotechnology app? Talk to DEVSFLOW Neuro. We build BLE-connected mobile apps for neurotechnology and medical device companies across Canada.

Related Reading