summaryrefslogtreecommitdiffstats
path: root/core/btdiscovery.h
diff options
context:
space:
mode:
authorGravatar Jan Mulder <jlmulder@xs4all.nl>2017-06-12 09:36:26 +0200
committerGravatar Dirk Hohndel <dirk@hohndel.org>2017-06-12 10:58:57 -0700
commita43cafa515f339b2a10069e7ebe926964449d447 (patch)
treec596d6ab15e7f6d0f74ad5f41537444e98525a3d /core/btdiscovery.h
parentca59dbd40dd30694a114f0196f113b9b2ee111db (diff)
downloadsubsurface-a43cafa515f339b2a10069e7ebe926964449d447.tar.gz
Mobile: do not BT Discover on Android (Q_OS_ANDROID vs Q_OS_LINUX)
This seems a very trivial commit, but it is not. It appears that on an Android build, with defined(Q_OS_ANDROID) the Q_OS_LINUX variable is also defined. This results in a very tricky discovery process: 1) the JNI stuff pulls the paired devices from the local BT controller, and 2) The QT discovry agent gets active BT devices. 1) is a static list, that is, not dependent on actual visual/discoverable BT devices; it is just cached data from the phone. 2) On Android, this results in a list of actively visible (paired and not paired) devices. On desktop, however (with QT/bluez BT stack) the QT discovery agent just gets the list of paired devices, so more or less equivalent to the situation described under 1) for Android. Ok, a long story, but just do not do a discovery on Android at all. Basically, we need the BT address, device name, and possibly a specific SPP service UUID. This are fixed and known for HW and Shearwater at this point, so there is no need for a (lengthy) discovery process, and making sure the the dive computer is discoverable at the moment the app wants to construct its data to show in the UI. So, the static list of paired devices is all we need. Signed-off-by: Jan Mulder <jlmulder@xs4all.nl> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Diffstat (limited to 'core/btdiscovery.h')
0 files changed, 0 insertions, 0 deletions