Document iOS BLE device discovery cache behaviorHEADdev

On iOS the BLE device discovery results seem to be limited to just
actively advertising devices. QBluetoothDeviceDiscoveryAgent uses
scanForPeripheralsWithServices API (with nil services), but this
API only returns actively advertising devices.

CoreBluetooth does provide an additional API for querying the already
connected devices (retrieveConnectedPeripheralsWithServices). However
this API only returns peripherals that are connected to the current
central manager instance, making it unfeasible to use in a general
purpose bluetooth discovery (which has its own central manager
instance).

The original bug report mentions iOS 18 but it's hard to confirm
whether or not something has changed in that iOS version.
The CoreBluetooth documentation hasn't changed and I couldn't find
relevant entries in change logs.

In summary it would seem that on iOS we can only return BLE devices
that are advertising. It is therefore advisable to store the device
UUID when it is first discovered; with this UUID it's then possible
later quickly connect to the device (advertising or not). If the
use case allows it, this can result in a better user experience too
as the discovery phase can be omitted.

Note: this issue was reproduced with few different smart watches.
These watches force a pairing when services and characteristics
are read, and after that they always automatically connect to the
phone.

Task-number: QTBUG-136692
Pick-to: 6.10 6.9 6.8 6.5
Change-Id: If9554a60299734da05461c3009cbd543b0dded88
Reviewed-by: Ivan Solovev <[email protected]>

0 files changed, 0 insertions, 0 deletions