Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BluetoothMedic's power cycle workaround no longer works on Android 13 #1109

Open
mannodermaus opened this issue Oct 27, 2022 · 1 comment
Open

Comments

@mannodermaus
Copy link
Contributor

mannodermaus commented Oct 27, 2022

First off, this is not a bug report: I'm not positive that there's anything that can be done by BluetoothMedic on devices running Android 13 or above. Consider this more of an FYI with the potential to improve the library's API to account for shortcomings of Android!


Basically, every once in a while my Pixel 6 Pro runs into a state wherein any BLE scan yields a SCAN_FAILED_APPLICATION_REGISTRATION_FAILED error. I have BluetoothMedic's automatic power-cycles enabled on this project and the logs confirmed that this was attempted correctly, but the issue wasn't resolved for some reason. I need to turn Bluetooth off and back on by hand, and then all works well again.

Checking the Android documentation, I learnt that both BluetoothAdapter.disable() and BluetoothAdapter.enable() were deprecated without replacement in API 33. Neither method does anything when called on a device running it (source). It seems like this behavior is linked to the project's targetSdk version, but I haven't tested that myself.

In essence, BluetoothMedic.enablePowerCycleOnFailures() can no longer be relied upon for Android 13 and beyond. I was thinking about a potential replacement API, but all I can think of is to present some UI to the user and inform them about the broken Bluetooth state (setNotificationsEnabled() works, but I cannot localize the text of the notifications as they are hardcoded). I'm wondering if an optional listener interface for broken Bluetooth state should be added to BluetoothMedic. An application could hook into the checks and react to bad states. Maybe it makes sense to deprecate the current variant of enablePowerCycleOnFailures() and redirect to a version that requires this listener, allowing for some sort of fallback on newer devices.

Expected behavior

The best possible recourse to fix bad BLE states on Android 13 is provided via BluetoothMedic.

Actual behavior

On the surface, it looks like BLE power-cycling is done correctly. However, Android 13 silently fails any call to programmatically change the state of a BluetoothAdapter.

Steps to reproduce this behavior

I don't have any reliable steps to get a device into the bad state related to SCAN_FAILED_APPLICATION_REGISTRATION_FAILED. But once done, BluetoothMedic is unable to get the device out of that state if that device runs on API 33.

Mobile device model and OS version

Pixel 6 Pro, Android 13

Android Beacon Library version

2.19.4

@davidgyoung
Copy link
Member

Thanks for this report, @mannodermaus. I had not noticed this change in Android 13.

I am not super surprised that Android ultimately blocks power cycling bluetooth by 3rd party apps. But given the instability of the Android bluetooth stack, it is unfortunate for those of us using the feature responsibly.

A couple of thoughts:

  1. I think adding a listener interface is a good idea.
  2. I agree we need to document that enablePowerCycleOnFailures() won't work on Android 13+. However, it is still useful on older devices and it will be a few years before most devices are on Android 13, so I think we should have a non-deprecated replacement method that makes the limitation clear. Perhaps enableLegacyPowerCycleOnFailures() with documentation that it only work on Android 12 and prior? (It always annoys me when supporting something even slightly older than the latest operating system requires using deprecated methods.)

Regarding the underlying issue of SCAN_FAILED_APPLICATION_REGISTRATION_FAILED, my understanding is that Android has a limitation of the number of scans that can be started and not stopped, and this often indicates a leak in scans. In the event that this leak is being caused by the library, it would be good to prevent it. If you notice any possibilities for leaks that can be eliminated, please keep a look out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants