Android 13: discoverServices() seems to be required before getServices()

[Arxi]

Describe the bug
I have a BLE peripheral which doesn't change its services and characteristic at runtime (at least I think so, is there a way to test that?). When I connect to this peripheral from Android 11, from iOS 15 or from Chrome, getServices() seems to work as it should.

When I try it from Android 13, getServices() returns an empty array.

If I call discoverServices() first, then getServices()returns all the services as it should, returning 7 services I expect.

If I then rebuild the app and try to do getServices() again without doing discoverServices() first, I again get an empty array. The peripheral wasn't restarted in the meantime and its services should be the same.

One thing to note: I do not provide any services nor optionalServices to requestLEScan() - can this be an issue?

To Reproduce

1. requestLEScan(). For options, I use justallowDuplicates = true
2. connect to a specific peripheral found in scanning
3. call getServices() for that peripheral on Android 13
4. empty array is returned
5. retry the same process but with calling discoverServices() before getServices()
6. array with services is returned from getServices()

Expected behavior
getServices() should return the existing services of the peripheral

Plugin version:

• @capacitor-community/bluetooth-le: 3.0.0-1

Desktop:

• OS: MacOS Ventura 13.3.1 (a)
• Browser: Chrome
• Version: 112.0.5615.137 (arm)

Smartphone:

• Android 11 device: Xiaomi Redmi Note 8 Pro, MIUI 12.5.7
• Android 13 device: OnePlus Nord CE 5G, OxygenOS 13
• iOS device: iPhone 7, iOS 15.7.5

[pwespi]

Service discovery is automatically run as part of the connect call. Can you check the logs in Android Studio when you connect to the peripheral and see if there is a difference between your Android 11 and Android 13 device?

The options of requestLEScan shouldn't matter.

[Arxi]

Thank you for the suggestion! Here are the logs from Android 11 device:

and here's Android 13 device:

They look a bit different, I'm not sure what's relevant though. Is there anything else I can check?

edit: in both of these, I do await BleClient.connect() and then await BleClient.getServices(), without manual discovery

[pwespi]

Do you call getServices immediately after connect? What happens if you add a delay before you call getServices?

[Arxi]

Yes, immediately after connect resolves. So I tried inserting 5 seconds of delay before getServices and sure enough, it now works:

I guess this means connect resolves before its internal discoverServices finishes - is that intended behavior? if so, I'll just await discoverServices manually just to be sure :)

[pwespi]

I guess this means connect resolves before its internal discoverServices finishes - is that intended behavior?

No, this is not intended. In fact the connect call waits for the onServicesDiscovered callback from Android before it resolves. Seems like your OnePlus device somehow behaves differently. I have never seen this, but it could be that this is specific to the device, and not the fact that it is Android 13.

Not sure if there is anything that can be done about this in the plugin.

[Arxi]

I see. Well, I'm at a loss - maybe it's somehow connected to that eattSupport : false that is shown on the connect() line in the log?
For my purposes, I'm fine with awaiting discoverServices every time after connect to know the precise moment I can call getServices, so this issue can be closed or just mentioned in docs/discussion.