[PATCH] Bluetooth support for Android

Claudiu Olteanu olteanu.vasilica.claudiu at gmail.com
Wed Jul 15 12:08:48 PDT 2015


Hi Thiago,


> Is this method supposed to work elsewhere too? Is there a reason not to
> use it
> everywhere?
>

This method should work on every supported platforms but
I cannot obtain the correct result using it on Linux.
I mentioned before that I believe there is a bug on the
QtBluetooth library because when I start a full SDP
discovery agent I cannot find the SPP service from my
HW OSTCs device. The same thing happened on Rick's
environment with his Petrel2 device.

I sent some e-mails on the qt-interest list but I didn't
receive any response to the last one.

That is why I decided to use directly the port number
on Linux platforms.

It would be interesting to test whether this happens on other Android
> devices
> too, especially those using BlueZ instead of Bluedroid.
>

I tested the application on two different devices
(Nexus 5 and Nexus 8) but unfortunately both have
the same Android version (5.1.1).
If I don't wait for the scanning process to finish,
the download gets stuck.

Also I tried to install the application on a device
with Android 4.3 but I cannot use any buttons and
cannot access the one with the "Import" functionalities.
You can find some links with two screenshots([1], [2])
from Android 4.3 and one from Android 5.1.1 [3].
I don't know why, but on Android 4.3 the header is missing.

I am not sure how the Bluetooth will work with the
Android Emulator tool and I don't know how to
test if this issue persists on Android versions
with BlueZ stack.


By the way, the pair/unpair functionalities are not
available on Android because we cannot access the
context menu :). I will change the UI after I will
finish the support for Windows platforms.



> What's the use for this? How likely is answering in 20 seconds when in 5 it
> didn't answer? If 25 seconds is better, why not always wait for 25 seconds?
>

If the device is in Connecting state or in ServiceLookUp
it means that the connection step took more than expected
and maybe we should give it another try and wait longer.
This can happen when it is the first time when you try
to connect to that device.
I didn't want to always wait for 25 seconds because if
somehow the Bluetooth from the dive computer was stopped
before I started the download, then the application can
freeze for 25 seconds. Therefore I decided to let a timeout
for 5 seconds to receive a feedback from the remote BT device.
If I don't receive anything it means that there is something
wrong with the device.

These values are not final and we can make them smaller.

Please add a simple comment to the source code why this is done, in addition
> to the commit. Something like "// on Android, the device gets stuck in if
> we
> try to use it before discovery is done"
>

I will do that. Thanks for the feedback!


Claudiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150715/a16c6801/attachment.html>


More information about the subsurface mailing list