diff options
author | Jan Mulder <jlmulder@xs4all.nl> | 2017-06-12 09:36:26 +0200 |
---|---|---|
committer | Dirk Hohndel <dirk@hohndel.org> | 2017-06-12 10:58:57 -0700 |
commit | a43cafa515f339b2a10069e7ebe926964449d447 (patch) | |
tree | c596d6ab15e7f6d0f74ad5f41537444e98525a3d /smtk-import | |
parent | ca59dbd40dd30694a114f0196f113b9b2ee111db (diff) | |
download | subsurface-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 'smtk-import')
0 files changed, 0 insertions, 0 deletions