Windows discoverServices AccessDenied #69
Comments
|
The Windows WinRT BLE APIs can be challenging to use in a non-UWP app because you can only retrieve characteristics or services once from the API on a Bluetooth device object unless you dispose of it. This means that if you call In Windows, discovering services is necessary to establish a connection. Therefore, we discover services and their characteristics when we want to connect and cache them for later use. This StackOverflow answer provides a clear explanation of this process. The BluetoothLeExplorer is a UWP app, which is likely why it can discover all the services without any issues. |
|
Well, I had a call to |
|
@Erhannis thanks for the suggestions, we will reconsider connection approach on windows to prevent these issues |
|
Ok, thanks. After a lot of further work, btw - I don't know what the solution to this is, exactly, but the process is VERY finicky. In general:
Part of the problem is that these things appear to vary between platforms - so your code will work fine on e.g. Windows but mysteriously fail on Android, and fail differently on Mac. The package may or may not tell you you've done one of these things wrong, as well - and given that a certain workflow may be valid on one platform, it's open to debate whether the one-size-fits-all approach should be enforced. Given the dozens of hours I've spent debugging it, though, I'd lean strongly towards it being made the default, at least. |
|
@Erhannis, I agree that there are behavioral differences across platforms, and the solution is to follow a consistent pattern for all. As you mentioned, the flow should be:
Once these steps are complete, you can proceed with other operations. On disconnection, it's best to repeat the above steps. For the issues you're encountering on Android, we have implemented a If needed, feel free to open a new discussion where we can dive deeper into the plugin structure. Our main goal was to simplify things so you could call any API using just the Another option would be to have the discovered This way, you'd be forced to first obtain the |
|
Re: queue, the README indicates that the queue is enabled by default, but also mentions "Keep in mind that some platforms (e.g. Android) may not handle well devices that fail to process consecutive commands without a minimum interval. Therefore, it is not advised to set queueType to none." This suggests that the default queue creates a (sufficient) minimum interval between calls. However, I had the default queue (presumably) enabled, yet needed an additional 2-second delay between calls on Android in order for them to work. (I'd previously had a 1 second delay which stopped being sufficient when I transitioned to universal_ble.) Any idea why? |
|
It’s difficult to determine whether the issue stems from your peripheral limit or the platform itself. The default queue should account for platform limits, but it may help to cross-check behaviour on other platforms to see if this is specific to Android only |
@Erhannis There are 2 potential reasons why you might need a delay between commands:
The queue is indeed enabled by default. To the best of our knowledge, the queue will prevent the first case. If your peripheral needs additional delay then this requires to be done by you. If you don't add a delay are you getting the same behavior on other Android devices and other platforms? |
|
The problem only showed up on Android - Windows, Mac, and iOS all work correctly without the delay. (I'm having separate issues with Linux, but I think even there I saw the relevant code work.) I can't guarantee it's not related to the device itself, but it seems like it must at least be compounded by something specific to Android. (Testing on a Pixel 4a, Android 13, btw.) |
|
@Erhannis there is a multitude of Android devices with different Bluetooth stacks so we cannot rule out exceptions. At least on the Android devices we tried, we didn't face issues when having the queue enabled. Do you have access to another Android device in order to cross-check its behavior without delays. A recent device from Samsung would be a good comparison. |
I'm having a problem like #64 , but in my case the example app does display the same problem, and the BluetoothLeExplorer does not. (Initially, anyway - but see after screenshots.) Windows 11. Trying to connect to a Polar Verity. I start the example app, go to Connected Devices, select my device, click Connect, and I only see 4 services, out of 9 reported by BluetoothLeExplorer. Here's the logs:
Here's screenshots of the list of services discovered in BluetoothLeExplorer:
...Though, I wondered why it was in "Connected Devices", and remembered that I had it open in the example app on the web page, while I tested both the desktop example app and BluetoothLeExplorer. After closing the web page, I tried again, and this time it worked. Logs:
Still seems like a strange failure mode, to report only certain services if you have more than one copy of the app open, particularly when BluetoothLeExplorer still reports all of them.
Also, my own app still reports AccessDenied - do you know what the key difference is?
The text was updated successfully, but these errors were encountered: