[PATCH] Bluetooth support for Android

[Rick Walsh]

Hi Claudiu,

On 16 Jul 2015 5:09 am, "Claudiu Olteanu" <
olteanu.vasilica.claudiu at gmail.com> wrote:
>
> 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.

I can test on my Galaxy s6, which apparently run on Android 5.02. Well I
could test it if I knew how.

>
> 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
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150716/cb3d20ad/attachment-0001.html>