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:

    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.


  • @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()
    D/BluetoothManager: getConnectionState()
    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()
    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 Note 9 yet so I'm not sure of performance on that platform at this time. Hopefully I hear from him this week.

  • @ryanbis Just got a message from our customer with the Note 9. He says that he is still experiencing the issue with the snapshot library where there is no communication when the phone is locked. Are there other Android settings that might be causing this issue? I'm not as familiar with Android's settings as I am with iOS so maybe there is something I am not aware of that may be contributing to this issue. The snapshot library did appear to correct the issue on the Pixel and Moto X4 phones so this Samsung is a mystery. Is there other information I can gather for you that might help? Do you guys have a Note 9 to test with?

  • @ryanbis I have a Samsung Galaxy S10 running Android 9. When I turn the screen off, I get this message in LogCat:

    2019-03-26 15:30:25.909 13902-13902/? W/BleService: State changed: StateEvent
    entered = [SCANNING]
    exited = [STARTING_SCAN]
    current = [ON, SCANNING, BLE_SCAN_READY]
    2019-03-26 15:30:25.910 7233-7314/? W/BtGatt.ScanManager: Cannot start unfiltered scan in screen-off. This scan will be resumed later: 7

    Is there a new API that I need to call to force the filtered scan? The snapshot build seemed to correct the issue on the Moto and Pixel, but doesn't on the Samsung and I just noticed this error. Perhaps there is still something missing? I don't know where the change is in the snapshot build, but I do see a getFilterList() call in the L_Util class that appears to return the empty ScanFilter list. Does this empty item get populated further up the call tree or should there be something else happening in the getFilterList() method when running on Oreo 8.1 or Pie 9.0?

  • Did you set the BleManagerConfig.defaultNativeScanFilterList option? If not, then it will not work. It's a List of the android ScanFilter object class.

  • @ryanbis The snapshot library doesn't have a defaultNativeScanFilterList option. It only has a defaultScanFilter setting.

  • Ok if it doesnt have that option, it doesn't have any fix in it. Sorry about that, something must have gotten screwy in the build. 0_1553796909134_sweetblue- This aar definitely has that option. That needs to be set in order for you to receive results in your scan when the screen is off.

  • @ryanbis Thanks for the quick response! This library is working well. Should I do a version check and set the defaultNativeScanFilterList only when the O/S is 8.1 or higher or can I always set it and SweetBlue will determine when to use it?

  • Just set it. They will always be used (with the post lollipop API).

  • @ryanbis heard back from our customer with the Note 9. He said things worked perfectly with the new library. So, when can we get a production release? 🙂 Thanks for all of the help on this one.

  • We're looking at around 2 weeks or so before we put out the official release.