Minor changelog clarification and other "nice-ifications"

Change-Id: I1eee55a970a7ed5e1813d70ec254ed0348d1e567
Reviewed-by: Oleg Shparber <trollixx@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
Fix uncategorised usage of qWarning().

Change-Id: Iee8b8e619f1679fe9b6e8aed47d05f7414417043
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Merge remote-tracking branch 'origin/release' into stable

Change-Id: Ia3c8079ad2c35f9573d8a59347af281275232e30
Add a few Qt 6 TODO entries

Change-Id: Ic169d907b872fd277df4f32be1270d7bceabac32
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Process Bluez5 URLs during SDP scan

Bluez5 advertises the following SDP attributes
- QBluetoothServiceInfo::DocumentationUrl
- QBluetoothServiceInfo::ClientExecutableUrl
- QBluetoothServiceInfo::IconUrl

They come as <url> xml tag but otherwise follow the <text> syntax.
So far this type of xml tag was unknown, a warning was printed
and the service info didn't contain the relevant info.

Although Bluez5 seems to be the first to advertise this attribute,
Bluez4 has to be able to deal with it too. Hence this patch goes
to Qt 5.3/stable.

Change-Id: I216fdaee23c75b1ed86702086be2d95a0efe109e
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Bluez4: Ensure QBluetoothLocalDevice becomes invalid if adapter disappears

The DBus object disappears when the dongle is removed. Once a
QBluetoothLocalDevice instance is invalid it remains invalid.
The patch further ensures that an invalid instance does not
initiate pairing activitiy.

Last but not least this patch fixes a memory leak in case
a DBus error occurs during the adapter initialization.

Task-number: QTBUG-38399
Change-Id: I2e13e393060c77fab5f79d5451dd6fe9a2a6e3bb
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Compare the NDef records without using qHash

It seems Windows produces a different hash value compared to
other platforms.

Change-Id: I73669894d63ffca08dbc6ed010e923050a0c8e8f
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Bluez5: QBluetoothLocalDevice becomes invalid if adapter disappears

Bluez5 supports org.freedesktop.DBus.ObjectManager interface which
permits monitoring of removal/addition of Bt adapters. This permits
the invalidation of the current QBluetoothLocalDevice instance. Once the
instance is invalid, it will remain invalid. Otherwise we could have a
switch of the adapter without the developer noticing it because the next
Bt dongle could get the same interface path. This would
violate the sense of identity that is attached to a
QBluetoothLocalDevice instance.

Task-number: QTBUG-38399
Change-Id: I007278ff1f94c48d6e6902959132088858b0d011
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Don't stop processing of Bluez services if one service is invalid

This is a regression introduced during the Bluez5 port. During the
service xml parsing we may encounter an invalid service info. This does
not mean the next one is invalid too. This bug caused the service
discovery to abort.

Change-Id: If51e0f898d83e99ba0a279c13ccaa3e5947bb6bf
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Bluez5: Add service (un)registration support

The Bluez5 DBus API does not permit the selection of the
local Bt adapter when registering a service. This means that
if the local device has two Bluetooth adapters the service will be
advertised by both adapters. This leads to cases where
the QBluetoothServer::listen() call binds the socket on one adapter
but the remote device tries to connect to the other adapter.

For now this is an acceptable behavior since it is rather rare to
have two local adapters at the same time. A potential future fix is
tracked by QTBUG-39012.

Task-number: QTBUG-32085
Change-Id: Ibb24edc5b9d1c25a005aedd98f6fc5d0d11b60f8
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Bluez5: Simplify lookup of default adapter

Change-Id: I59aa5241d33191a8ca8cc167263b63b024f52754
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
Avoid empty service names

Bluez doesn't seem to know the service class uuid 0x1200 which seems
common on BB10 devices. Ensure that we set a name if Bluez did not
provide a name. This was made possible by the recent addition of
QBluetoothUuid::serviceClassToString(..).

[ChangeLog][QtBluetooth][QBluetoothServiceDiscoveryAgent] Fixed
cases where Bluez doesn't provide service names for given Bluetooth
service class uuid.

Change-Id: Ife56ab878f70ca6226e907f59972368c79318bec
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Add changelog for upcoming Qt 5.3.1 release.

Change-Id: I8343a3a474e3b6378b24c08182d767262111ec19
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
Properly deal with pairing errors in btfiletransfer example

Pairing error signals were ignored which lead to a situation in which
the UI remained in the "attempting to pair" state.

Change-Id: I66f8855cf5ab72d608650b36a844c53e27624452
Reviewed-by: Oleg Shparber <trollixx@gmail.com>
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Bluez5: Add Object-Push support

Task-number: QTBUG-32085
Change-Id: Ied7ffeac768dc65c44cc74112cdebaaf9bb2bc46
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Bump version

Change-Id: I98350110680ee20cd9a2fa55b57b390e66969b65
Fix crash in bttestui when using default backend

The cause are uninitialized pointers.

Change-Id: I4ba5f79dbda3e20361fc1127fa08e93a2b7ce80e
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Merge branch '5.3' into dev

Conflicts:
	.qmake.conf
	src/bluetooth/qbluetoothlocaldevice_bluez.cpp
	src/bluetooth/qbluetoothlocaldevice_p.h
	src/bluetooth/qbluetoothservicediscoveryagent_bluez.cpp

Change-Id: Ifb0c01eb8bffbffcd2416ea8d7bf1d36eb1c70f2
Remove usage of QObject::tr() in qbluetoothsocket_bluez.cpp.

Change-Id: I72703aac0676e6474f2c40ac37b8ee8b00830690
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
Merge "Merge branch '5.3' into dev" into refs/staging/dev