| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
At the same time we fix up some cases where the ProtocolDescriptorList
was not a list within a list.
Change-Id: If0ec6cf6374902a47a905edd08523906be9fd86b
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3 & LICENSE.GPLv2
- Removed LICENSE.GPL
Change-Id: I7a8b8b787fcae9a178794364efdefe1021d10b1b
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
| |
Change-Id: I00701e9103a6acfdfc2697949280f8a7de8bcdfe
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
|
|
|
|
|
|
| |
This avoids unnecessary code duplication.
Change-Id: I9e49cf3c5e524cf7b3ef811b4640d5248c2ba1b0
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
|
|
|
|
|
|
|
|
| |
At the same time we shift the ServiceClassUUID to service name mapping
to QBluetoothUuid. It was used by Android and now Bluez 5 uses it too.
Task-number: QTBUG-32085
Change-Id: I9f2d4dc4e2997683485f2ba7aaefb646cb72fb75
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The discovery of services happens in a sequentiali per-device order.
Once the first device's services were found, the results are processed
and the discovery is started on the next device. Unfortunately
if the search didn't create any results due to the remote device
refusing the SDP discovery or because the given remote Bluetooth
address was not valid, the discovery agent didn't continue with
the next device.
Now the error handling ensures that the discovery process is continued
with the next device (if there is any).
Task-number: QTBUG-38362
Change-Id: Ie27bbc5327eadc4bcc31b589227c51dc4fa2c7c1
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1.) If we find a custom and SPP uuid we create only on service
using custom uuid as service uuid and SPP as service class uuid.
THis is the recommended way. Any remote service should really
advertise a custom uuid. Unfortunately this is not always the
case on some embedded devices. Hence we need to cover the cases
below.
2.) If we find a custom uuid only we create a service which uses
the custom uuid as service uuid but we do not set a service class.
3.) If we find a SPP uuid only, we create a service which uses SPP
as service uuid and as service class uuid. This is no problem as
Android's connectToRfcommService() call explicitly permits an SPP
uuid as connection parameter.
4.) We find none of the above the problem doesn't exist in the
first place and no service was found.
Task-number: QTBUG-38140
Change-Id: I2e9080f65b98db23782264ef9e62a410ab9f91f1
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
|
|
|
|
|
|
| |
Change-Id: I01e867cb5efb231e7c85b0d106897b2f31448977
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BroadcastReceiver.onReceive() is executed in the main thread whereas
the Qt classes are in a different thread. This created issues whereby
Java's qtObject pointer was reset by the Qt classes/thread but
onReceive still trying to access the same object later on.
In most cases the Qt classes using BroadcastReceiver were half way
through their object tear down. This patch fixes the problem by
guarding qtObject against concurrent thread access and ensures that
the qtObject pointer is reset before the object tear down starts.
Change-Id: Iab97b0af8e10686d97419ac8504f2fe69e9536f3
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
serviceClassUuids were not correctly written and hence only ever one
service was found per device. The deviceInfo and serviceUuid were the
same anyway as we are talking about the same remote device and the
absence of custom service uuids.
Change-Id: I2d8dad2d38381b1c171afb236ee56822e62ffee3
Reviewed-by: Nedim Hadzic <nedimhadzija@gmail.com>
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BtLE related uuids will be added by the BTLE feature branch.
This change adjusts the docs such that it becomes obvious whether
a UUID is a service, profile or both.
Task-number: QTBUG-36123
Change-Id: I487471c9227a0fe11f443c54d21a29b23a11e076
Reviewed-by: Nedim Hadzic <nedimhadzija@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
| |
Fo far it was using the GNSS profile uuid.
Change-Id: Ifbe51353a6355d260c42d870656a78059e440181
Reviewed-by: Nedim Hadzic <nedimhadzija@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
| |
Change-Id: I81fd5cc89d88e4527778c6aed4cddeb0648dd812
Reviewed-by: Nedim Hadzic <nedimhadzija@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
| |
This includes unification of error messages, fixes for spelling
mistakes, hints for translators and other forms of simplifications.
Change-Id: Idd0e01614b24ff2d19133f0d19d49649d59e3f57
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
|
This is a feature merge to dev targeting Qt 5.3.
Known issues:
-QTBUG-36754: QBluetoothServer::close() crashes
-QTBUG-36763: QBluetothTransferManager port to Android not possible
-QTBUG-36764: Improve QBluetoothLocalDevice::connectedDevices()
-QTBUG-36810: Remove direct use of Android action strings
The above issues and some other minor TODO's will be addressed
until final release time.
Task-number: QTBUG-33792
[ChangeLog][QtBluetooth][Android] QtBluetooth has been ported to
Android.
Change-Id: I31ba83e3b7d6aa68e7258b7e43235de7d1a6e68a
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|