Fw: Crash when using Bluetooth

Wed Jan 9 12:17:26 UTC 2013

This discovery process is one that I have not tested yet because I use
other approach, I do discovery and pairing with Android Settings->Bluetooth
and then inquire mac address or bound devices from Android. There inquiry
of bound devices is known important missing feature of Qt Mobility
Connectivity.
I have plan least propose it to be added in future releases. At the moment
I have implementation for Linux/Dbus/Bluez and Android/JNI/Bluez.

I have not yet tried discovery with Android QTM Connectivity for fthis
reason. Other reason is that pairing functions on QBluetoothLocalDevice are
empty,
not implemented yet.

It is very obvious that same root cause of bugs I fixed exists also on
discovery part but I have not yet had time to look them.

Kate

On Wed, Jan 9, 2013 at 12:05 PM, Dominique Rety <dominiquerety at hotmail.fr>wrote:

> **
> Hi all,
>
> To my understanding, before connecting a bluetooth device it is necessary
> to perform discovering to get the remote MAC address.
> Do you successfully go through this step when testing Bluetooth in your
> environment ?
>
> Device discovering involves the broadcast receiver, which is started from
> QBluetoothLocalDevice::startDiscovery
> Therefore it seems to me that the patch consisting in reloading the
> btAdapterClass must also be applied to the startDiscovery(),
> cancelDiscovery() and isDiscovering() methods.
>
> While trying to go further in my tests, I noticed
> that AndroidBroadcastReceiver suffers from the same syndrome.
> Then I tried to reload jQtBroadcastReceiverClass from
> "org/kde/necessitas/mobile/QtBroadcastReceiver", but without success (class
> not found).
> QtBroadcastReceiver is an extension of the BroadcastReceiver Java class
> (cf. QtBroadcastReceiver.java)
> I can successfully load jQtBroadcastReceiverClass from
> "android/content/BroadcastReceiver", but of course the program fails later
> because the class doesn't contain the expected extensions.
>
> Do you have any explanation why it is possible to find a class from
> "android/bluetooth/BluetoothAdapter" or from
> "android/content/BroadcastReceiver", but not from
> "org/kde/necessitas/mobile/QtBroadcastReceiver" ?
> More generally, why any FindClass performed during the connectivity
> library load work fine but must be repeated at program run time ? Why some
> Java classes could become no more accessible ?
> Is there a change in Qt loading logic that can explain this ? How to
> investigate in this direction ?
>
> I will be happy if I can make a contribution to diagnose these problems.
>
> Dominique Rety
>
>
> ----- Original Message -----
> *From:* Dominique Rety <dominiquerety at hotmail.fr>
> *To:* Kate Alhola <kate.alhola at gmail.com>
> *Cc:* necessitas-devel at kde.org
> *Sent:* Friday, January 04, 2013 2:52 PM
> *Subject:* Re: Crash when using Bluetooth
>
>  Hi Kate,
>
> I continue trying to operate the btchat sample, which implements
> functionalities very closed to those we have to use in our project.
>
> Before receiving your patch, I tried a solution consisting in moving the
> initialization code for the connectivity library (contained in
> JNI_OnLoad) to a separate function executed just before the first call to
> the library.
> For btchat, I execute this function just before
> QBluetoothLocalDevice().name() in the main application context.
> This solution works (I can get the device name without JNI ERROR),
> probably because the initialization code is performed in a thread context
> that remains valid.
>
> I also tried your patches, which solve the get name JNI ERROR as well.
> Your solution is probably better if it works without any constraint on the
> initialization thread context.
>
> However, all of this only partly solves the problem. When I try to connect
> through the btchat application, I got an other JNI ERROR when the device
> discovery logic starts.
> I have applied your patch to the QBluetoothLocalDevice::startDiscovery()
> cancelDiscovery() and isDiscovering() methods. This enables the code to
> continue a bit.
> But then I have similar problems into the
> AndroidBroadcastReceiver::initialize() method when calling
> env->RegisterNatives(jQtBroadcastReceiverClass).
> So I tried a similar patch to fix this issue by first issuing:
>         JNIThreadHelper env;
>         jQtBroadcastReceiverClass =
> env->FindClass("org/kde/necessitas/mobile/QtBroadcastReceiver");
> Unfortunately, this call returns a NULL and I get a FATAL EXCEPTION,
> java.lang.NoClassDefFoundError:
> org/kde/necessitas/mobile/QtBroadcastReceiver.
>
> Note that the
>         jQtBroadcastReceiverClass =
> env->FindClass("org/kde/necessitas/mobile/QtBroadcastReceiver");
> is performed once *with success* in the
> AndroidBroadcastReceiver::loadJavaClass() method, which is called at
> libQtConnectivity library loading time, from JNI_OnLoad.
> I can't understand why this call is only valid at library load time.
> I'm not sure that trying to apply a similar patch in this situation would
> be a solution to this issue.
>
> Do you have an idea to progress on this subject ?
>
> Thank you for your help.
>
> Dominique RETY
>
>
>
> ----- Original Message -----
> *From:* Kate Alhola <kate.alhola at gmail.com>
> *To:* Dominique Rety <dominiquerety at hotmail.fr>
> *Cc:* necessitas-devel at kde.org
> *Sent:* Thursday, January 03, 2013 2:59 PM
> *Subject:* Re: Crash when using Bluetooth
>
> On Wed, Dec 26, 2012 at 7:33 PM, Dominique Rety <dominiquerety at hotmail.fr>wrote:
>
>> **
>>  Hi Kate,
>>
>> Thank you for your answer.
>>
>> I tried some traces and modifications into the lib QtConnectivity without
>> success. It seems to me that functions into the library already contain
>> calls to JNIThreadHelper class that should setup the Java environment by
>> performing jvm->AttachCurrentThread(), but this doesn't solve the problem.
>>
>> At the same time, I performed some basic bluetooth tests directly through
>> Java Eclipse (BluetoothAdapter.getDefaultAdapter.getName), which work fine
>> on Nexus 7 with Android 4.2.
>> However, our project contains some legacy parts that have already been
>> developed in C, and using Qt would be the very best way to integrate them.
>> Therefore I will only envision to implement a direct bridge between Java
>> and C parts as a last resort if I can't find a viable solution with Qt.
>>
>> Consequently, I am very interested by your patches even before the next
>> release, which could be helpful for us to take a decision for our
>> development. Overriding and deploying the default Necessitas lib
>> QtConnectivity is not a problem for me, at least for test purpose.
>>
>
> Now patches are on Review board https://git.reviewboard.kde.org/r/108113/. I would be happy if you could try them.
>
> Sorry about delays publishing them
>
>
> Kate
>
>
>>
>> Regards,
>> Dominique
>>
>>
>>
>>
>>  ----- Original Message -----
>> *From:* Kate Alhola <kate.alhola at gmail.com>
>> *To:* Dominique Rety <dominiquerety at hotmail.fr>
>>  *Cc:* <necessitas-devel at kde.org> <necessitas-devel at kde.org%3E>
>> *Sent:* Wednesday, December 26, 2012 4:36 PM
>> *Subject:* Re: Crash when using Bluetooth
>>
>>  On 13.12.2012, at 16.41, Dominique Rety <dominiquerety at hotmail.fr>
>> wrote:
>>
>>   Hi,
>>
>> I am currently developing a telecommunication project involving Blutooth
>> communication between Android devices. For this purpose, I'm trying to use
>> Necessitas Bluetooth support and I experiment very similar problems that
>> are described in the "Crash when using Bluetooth" (Kate Alhola) archive
>> thread.
>>
>>
>>
>> There is several issues in current necessitas libQtConnectivity version.
>> I have hopefully fixed most of them and i have version of libQtConnectivity
>> that least works with my own applocation. I try to deliver patches to
>> necessitas project so that fixes could be included in next release.
>>
>>   Environment:
>> Java JDK 1.7.0_09
>> Qt Creator 2.5.83 Based on Qt 4.8.3 running on Linux Suze
>> Kit = Necessitas Qt 4.8.2 for Android armv7a
>> Compiler = Android GCC (arm-4.4.3)
>> Android target SDK = android-16
>> Deploy to Nexus 7 with Android version 4.2.
>>
>> I firstly tried to deploy the btchat sample and I faced the same problem:
>> JNI ERROR (app bug): accessed stale local reference 0xe680001d (index 7
>> in a table of size 4)
>> VM aborting
>> Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1), thread 13965
>> (.example.btchat)
>>
>> Setting traces in different source files of the connectivity library, I
>> also noticed that the error happens when trying to use some member
>> functions of QBluetoothLocalDevice (btchat sample requests for the local
>> device name from the main function).
>>
>> I tried to bypass this problem by only creating the QBluetoothLocalDevice
>> without requesting for the device name in the btchat application. The
>> program then starts correctly.
>>
>> In the btchat application, the "Connect" button calls the
>> QBluetoothServiceDiscoveryAgent::start function. This function randomly
>> processes the request because it relies on discoveryState and deviceAddress
>> members, which seem not to be initialized : either the discovery process
>> freezes or the program aborts with an error (if luckily discoveryState and
>> deviceAddress members get consistent values). I didn't try any further
>> investigation. It seems to me that the connectivity library is compiled
>> with qbluetoothlocaldevice_p.cpp, which just contains empty functions for
>> the QBluetoothLocalDevice class, instead of a customized source for Android.
>>
>>
>>
>> Yes, that's case. The QBluetoothLocalDevice initializes static handles to
>> java virtual machine that are then referenced by other modules. I have made
>> fixes to several parts of libQtConnectivity
>>
>>
>>   Is Bluetooth support for Android in Necessitas complete ?
>>
>>
>> Most of, some functions are still missing but there are some bugs in
>> current version
>>
>>   Is the btchat sample expected to work properly with Android ?
>>
>>
>> I have not tried that one
>>
>>   Is there any specific configuration issue I could miss ?
>>
>>
>> That's good question, what is origin of the bugs, does it work with older
>> android
>> Versions ? The source reason of bugs is JNI handles alocation that
>> conflict with
>> Current thread structure and some that handles are expired when used. I
>> have only tested with
>> Android 4.x
>>
>>   Is there any corrective or complement software I could download ?
>>
>>
>> I could make my patches avaiable before next release  but overriding
>> default necessitas libQtConnectivity requires some tricks
>>
>>   How can I progress on this issue ? What is the best way to get help
>> and advices ?
>>
>>
>> This list works fine.
>>
>> Kate
>>
>>
>> Regards,
>> Dominique RETY
>> dominiquerety at hotmail.fr
>>
>>
>>  _______________________________________________
>> Necessitas-devel mailing list
>> Necessitas-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/necessitas-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20130109/0fb6dbbb/attachment-0001.html>