Scans with screen turned off on Android 8.1 and above fail



  • @ryanbis Hi Ryan, some of our customers running Android 8.1 and Android 9 have stated that our devices do not connect to our application when the screen is off. I know that starting with Android 8.1, unfiltered scans are blocked when the screen is turned off. I see that SweetBlue creates an empty scan filter to circumvent this issue. However, I found the following Stack Overflow post: https://stackoverflow.com/questions/48077690/ble-scan-is-not-working-when-screen-is-off-on-android-8-1-0.

    The accepted answer states that an empty ScanFilter will work in the first Edit.

    However, the second edit states the following:
    EDIT 2: On the Galaxy Note 9 with Android 8.1 and perhaps other Samsung devices with 8.1, scans are blocked with the screen off even with an empty scan filter. Scans are allowed with the screen off with a non-empty scan filter as described above.

    The customer I am working with has a Note 9 while another customer has a Motorola Moto X4 which is acting just like the Note 9.

    Bottom line, is there a way for you to add an API that would let me provide a non-empty scan filter to circumvent this problem? I would like to add the Service UUIDs that I add via my argument to the DefaultScanFilter constructor.



  • Mike,

    We'll look into it. Thanks for pointing out that post.



  • @mkurtz, it's not looking too good. So we added an option in our development branch to allow setting the native ScanFilters via the BleManagerConfig file. One of our developers has an S9 running Pie. He sees the same behavior on his phone, and setting the ScanFilter didn't make a difference. We're still trying to mess around with things, but it's looking more like there may be nothing we can do, at least on the S9 (and I have a feeling those other phones you're seeing issues on). But, we'll keep prodding away to see if we can find a workaround.



  • @ryanbis Thanks for checking so quickly. Hopefully there is something that can be done. Our product is almost unusable with this issue as 90% of connections are made with the phone locked. Fingers crossed.



  • Actually, looks like it DOES work. I think when we first tried the new changes, we had conflicting filters. It will ONLY work if you set the native filter, AND run a foreground service.



  • @ryanbis That's good to know. We do run our app with a foreground service so no issue there. It's never easy is it... 😉 I'll be happy to try the patch once it's ready.



  • @ryanbis, any idea on when a beta version might be available for me to try out?



  • @mkurtz, here's a snapshot version you can try for now. You'll have to update your build file to load this aar file, instead of pulling it from the maven repo.

    Let me know if you see any problems with it.

    0_1551795030335_sweetblue-3.0.4.9-20190226.155402-1.aar



  • @ryanbis I will test this build out and get back to you.



  • @ryanbis I tested in the office with a Google Pixel 2 XL running Android 9 and had success in the background. I will be doing further tests on the Motorola and Samsung phones over the next few days.

    I did receive this message occasionally in the logcat:
    2019-03-13 09:24:07.246 17501-20025/? E/BtGatt.GattService: App 'com.kineteksports.clubhub' is scanning too frequently

    I also saw this which seems odd:
    2019-03-13 09:28:35.792 17501-17531/? W/BtGatt.ScanManager: Cannot start unfiltered scan in screen-off. This scan will be resumed later: 6

    Also, not necessarily related to the new code, the phone explicitly disconnects at the end of a short lived protocol with the device. I see a state related error in the log (last line of this sequence):
    W/BleClubHubDevice: In-PLAY voltage: 2854
    ===== Disconnecting due to time-in-play receipt.
    ====> Disconnecting device: 60:50:C1:00:50:9E
    D/BleClubHubDevice: *** device state mask: 22315584, native state mask: 2
    D/ClubEntity: cumulativeInPlayTime is dirty: 262989 != 285274
    I/P_TaskManager: UPDATE(29031) addTask() - Adding task to queue: Disconnect(CREATED nlaaz_509E 17557741 )
    I/P_TaskManager: UPDATE(29031) print() - no current task [Disconnect(QUEUED nlaaz_509E 17557741 )]
    I/P_TaskManager: UPDATE(29031) print() - Disconnect(EXECUTING nlaaz_509E 17557741 ) []
    D/BluetoothManager: getConnectionState()
    getConnectedDevices
    D/BluetoothManager: getConnectionState()
    getConnectedDevices
    D/BluetoothGatt: cancelOpen() - device: 60:50:C1:00:50:9E
    D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=6 device=60:50:C1:00:50:9E
    I/P_BleDevice_ListenerProcessor [Native]: CAM(28927) onConnectionStateChange() [60:50:C1:00:50:9E] - GATT_SUCCESS(0) STATE_DISCONNECTED(0)
    I/P_BleDeviceNativeManager: UPDATE(29031) updateNativeConnectionState() - STATE_DISCONNECTED(0)
    D/BluetoothGatt: close()
    D/BluetoothGatt: unregisterApp() - mClientIf=6
    I/PA_Task: UPDATE(29031) setState() - Disconnect(SUCCEEDED nlaaz_509E 17557741 ) - 16398
    I/P_TaskManager: UPDATE(29031) print() - no current task []
    W/P_DeviceConnectionManager: UPDATE(29031) onDisconnected() - Disconnected explicitly and attemptShortTermReconnect=false
    D/BluetoothManager: getConnectionState()
    getConnectedDevices
    E/P_BleDeviceNativeManager: UPDATE(29031) performGetNativeState() - Tracked native state STATE_DISCONNECTED(0) doesn't match reported state STATE_CONNECTED(2).



  • @ryanbis I was able to test on the Moto x4 that was displaying the connection problem and it is working well with the new library. I haven't been able to reach our customer with the Samsung S9 yet so I'm not sure of performance on that platform at this time. Hopefully I hear from him this week.