Android: Problem with BLE scanning stopped while screen is off on newer phones

[RobinDev]

Hello,

We're using the Scanner Compat (v1.6.0) library for Android in our app, and it has helped us tremendously.

Recently we've observed that the Xiaomi 12T has stopped delivering scan results with the screen off. This means that users cannot reliably connect to our device anymore, unless the user briefly activates the screen on their phone, in which case the scan results pop in instantly, leading to a prompt successful connection with our device as expected. This hasn't always been a problem, and I can probably trace it back to an Android 14 update.

For context, we're using PendingIntent scan strategy to scan continuously, scan filters for our devices, scan settings of SCAN_MODE_BALANCED, and we're restarting the scan every 15min via a scheduled job. We also have the batteryOptimization disabled, as well as the ACCESS_BACKGROUND_LOCATION permission.

In my investigation of the problem, I stumbled upon the reportDelay scan setting, which we havn't been using before. Re-reading the README page of the Scanner Compat library, there is a small mention of this, saying that it should be used with PendingIntent background scanning. Also, in a repo of Googles samples for working with BLE, I fould a small comment saying something along the lines of "this [reportDelay] enables scanning while the screen off"

Thinking that I've found the solution to our problems, I set up a test with the Xiaomi12T with our previously mentioned scan setup but also a reportDelay of 10000ms.

While testing, inspecting the phone log in LogCat with the filter `tag:BtGatt.ScanManager` shows that scan results - with screen off - are being "flushed" (`MSG_FLUSH_BATCH_RESULTS`) on what seems to be a strict timer of 5 minutes. I interpret this "flushing" as the phone buffering scan results, to be released after 5 minutes *only* to apps having the reportDelay (batching?) enabled.

Together with the reportDelay, when the flushing happens, we CAN actually connect to our devices from background with the screen off - unfortunately with the added inconvenience of up to 5 minutes delay from the assumed phone built-in timer.

This wouldn't be so bad if it was isolated to just one phone, but our users report what seems to be the same behavior on newer OnePlus models, running Android 15. I am hesitant to go ahead and set this reportDelay for all of our users across the board, as I have no idea how other phones react. At the very least, users will see an increased delay in bluetooth conection time, which isn't exactly an improvement.

Do you have any thoughts about or insights into this issue? Like, is this the expected behavior for newer phones? Is there some combination of scan settings, phone settings, or other settings that will mitigate this behavior?

Kind regards,

Robin

[RobinDev]

Hello

Absolutely! But let me be clear, our setup has worked - and is working - as expected on many phones that we support. What we're seeing lately, however, is a worrying trend where that this setup doesn't work anymore on certain phones, including, but presumably not limited to, the Xiaomi12T we use for testing. More precisely, we've heard complaints from Xiaomi and OnePlus customers, experiencing the same behavior: Not connecting automatically anymore with the screen off. Briefly activating the screen, however, triggers the expected instant connection.

As mentioned earlier, it seems non-batched scans with PendingIntents are being suppressed with the screen off, and even performing batched scanning via the reportDelay scan setting puts the scan results on a fixed 5 min timer. This might be fine for a smart watch that periodically syncs throughout the day, but not for our devices where an instant automatic connection is part of the core functionality.

Here's the filter definition:

private val SCAN_FILTER = listOf(
        ScanFilter.Builder()
                .setServiceUuid(ParcelUuid.fromString(<service UUID 1>)
                .build(),
        ScanFilter.Builder()
                .setServiceUuid(ParcelUuid.fromString(<service UUID 2>)
                .build(),
        ScanFilter.Builder()
                .setServiceUuid(ParcelUuid.fromString(<service UUID 3>)
                .build())

and the use site:

override fun startScan() {
    BluetoothLeScannerCompat.getScanner().startScan(SCAN_FILTER, SCAN_SETTINGS, context,
            scanningPendingIntent, RC_START_STOP_SCANNING)
}

[Simonr]

Hi Robin

Thank you for the thorough feedback. I'll run this concern by our mobile apps group and get back to you. Do you also have a list of other models that you're seeing this issue with, as I know we have various OnePlus mobiles available in office, but not too many Xiaomi's.

Best regards,

Simon

[RobinDev]

Hello

Thank you for looking into it.

One of our beta-testers has reported seeing the same behavior on Xiaomi 14 (likely also the 13), suggesting that this is a trend that Xiaomi is continuing, unfortunately. We've also heard similar story from our support department regarding the new OnePlus 12.

Regards

Robin

[Simonr]

Hi Robin

So, I talked to one of our mobile apps devs today, and as far as they know there aren't ant specific requirement for batching (delayReport). We don't have a project up to do background scanning at the moment, and we will have to take a better look at this after the Christmas holiday. 

Sorry that we couldn't provide a quick and easy solution to this, but please keep us posted if you find anything or find more mobile devices where this issue is seen too.

Best regards,

Simon

[RobinDev]

Hello,

We're glad you're taking time to look further into this issue.

I also don't belive it's a hard requirement to use scanDelay for intent scanning in the background, because, as already mentioned, we have a lot of happy customers using the product as it was designed.

However, I did manage to dig up the place where Google makes a comment on using reportDelay with intent scanning in one of their BLE samples. Also, in the background scanning guidelines of the Scanner Compat library, it is mentioned that reportDelay should be used. That's all I have to go off of. If there are nuances to this that I'm missing, please feel free to enlighten me - that's why I'm here

Please reach out if you need anything in the testing. The implementation of the Xiaomi phone is somewhat quirky, so there could be some challenges in successfully reproducing the problem. In that case I can provide som repro steps that brings out the problem for us at least.

Regards,

Robin