| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
tqtc/lts-5.15-opensource
Change-Id: I6f5b5789b64c033f10223c2147ce7a312d868230
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
At least on Linux the QIODevice parent class reads and buffers a
large chunk of data when readLine() is called. This call effectively
empties the private linear data buffer, and subsequent canReadLine()
calls to the private buffer returns false. This is problematic if
the data contained several lines of data; the
QBluetoothSocket::canReadLine() returns false but readLine() returns
valid lines of data.
This commit adds a parent class call so that it's buffers are also
taken into account as per QIODevice documentation.
Fixes: QTBUG-101690
Change-Id: I8130aff217e9e6c5525101901ed55721430b6dd0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 393fd47ab64ce80fb0e852027591840aef8e135d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Newer bluetooth devices may trigger (only) a
HCI_LE_Enhanced_Connection_Complete instead of
HCI_LE_Connection_Complete.
This commit adds handling of this so we get a proper bluetooth handle.
Task-number: QTBUG-101309
Change-Id: Ibb5cf8ca063df9345a0ef0bcb12ae0dd780bab78
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 12afa962ebb5a6eac4b598bdd1b1804c9a3ca089)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
tst_QBluetoothDeviceDiscoveryAgent::tst_discoveryMethods was broken
on Android because devices with unknown core configuration are found,
while the test tested that every device found has either
LowEnergyCoreConfiguration or BaseRateCoreConfiguration.
Change-Id: I4dc9f50dba989f7827842169dbd06c847a019505
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit ab7b1ec29f6cc1c8490fa71116a82e18789c4ee3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The bluezdbus and bluez socket are initialized to different security
flag values. Adjust the test according to which backend is in use.
Change-Id: I05f7c10743de8b02e701bcee891fa3be12d4975f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit bc83b98295c36c28367a64722188164cde1f796b)
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QBluetoothSocket::connectToService(QBluetoothServiceInfo) should
extract the socket protocol info (rfcomm/l2cap) from the provided
service info.
Fixes: QTBUG-101018
Change-Id: Ibbf4daef28a2661e4699759d6f834779d27ac750
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 29b51e28a961a09fb25d668da5a5e3c9d89390b9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The application code may call stop() for the service discovery agent
when it has detected the service-of-interest.
The crash occurs because the stop() will clear the list of discovered
devices, but the service discovery result handling loop may still be in
the middle of processing the services. If the loop accesses
the by-now cleared device list on its next iteration, it will cause a
list access violation assert.
Fixes: QTBUG-100894
Change-Id: Ica300cd8461543b533800ca06551b21d9b256613
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 2de33f78ec374ce6963b9c1715e4942c8cf70bb0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The original problem is that on macOS Monterey the service discovery,
and subsequent usage of the services, is unreliable. This commit
improves the situation a bit by checking the connectivity status
of the device instead of relying on IOBluetooth callbacks which
quite often don't arrive.
Also there was a crash due to stray callbacks from IOBluetooth.
These seem to cease when we now close the connection we have
established for SDP inquiry purposes. The crash happened especially
if the remote device got paired during the service scan.
In addition this commit introduces more event logging which helps
when debugging these issues.
Fixes: QTBUG-100303
Change-Id: Id063401390b141cff412cbb47d20d441cc394d3f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 2e09bf6c57c8cb0c1069b562ab2451ec8b68c27a)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit guards against creating multiple client sockets if multiple
services are found. In addition the service scanning is stopped when
a service has been found and we start connecting a bluetooth socket.
Fixes: QTBUG-100289
Change-Id: Iac2e7eaca17a186ac2d2f62e338be16911f08032
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 788c4980e67386d2407c4c7bc7182430fc9054c3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Connection monitor: instead of asserting on 'monitor != nullptr' -
issue a warning and bail-out early. Despite of us unregistering from
connection notifications and trying to release the monitor,
IOBluetooth seems to keep references and sometimes it's possible to
trigger this assert in our autotests.
2. IOBluetoothDeviceInquiry - stop reporting errors completely, they are
not mapped to any error in QtBluetooth and give nothing but failing
auto-tests.
Change-Id: I8fc2e23d3685b912759df91c65b02537f39d1b5f
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit ba38f64e22c98ba6b0d3bdccbd00ea5a643404f8)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch amends bf69c830419a7cda87d6aa71c962804a946011ea.
After fixing the thread affinity issue, Qt is using QueuedConnection
for the charListObtained signal. As a result, the signal's arguments
need to be registered for the metatype system.
This patch provides such registration.
This is a 5.15-only change, as Qt 6 is does not require to register
the types explicitly.
Fixes: QTBUG-99767
Change-Id: I50e6314669bd6e779b85373f417c92b57f23a7e9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For example the "Bt Chat Server" example application service
would always show up as a "Custom Service".
Change-Id: If73423d90d5681ee0c3655ef7ee3ad6cd7638755
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit e27c6600eca2c9b704c73a0b6d28780eb236cefb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit fixes four SDP record issues
1. The nested sequences were created too "shallow", missing one layer
of depth
2. The attribute keys are expected to be in hex format but were
given as decimals
3. The matching with variant.canConvert<QString> results in too
broad acceptance, and for example ushort was interpreted as a
string
4. With fix for "3" above in place, the UINT16 attributes were put in
as UINT32 because of how macOS by default interprets the NSNumbers
as part of SDP dictionary
Without these fixes Windows client does not find the service, and
Linux client misses some of the details.
Fixes: QTBUG-100445
Change-Id: I4f063e49bd8832d0e97bdf69acbd1ee7dacf0f87
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 119ef898806d8f67f13877a655b7e2c6b6eb168b)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
-performSDPQuery:self - does not open a baseband connection anymore to a
device, if not connected yet (despite it's documented to do so). Now we
have to ensure isConnected == true first. An attempt to connect is not guaranteed
to ever complete (with/out errors), so we need a timeout logic in place.
-performSDPQuery:self uuids:filter is simply a noop function on Monterey,
we have to filter services manually, after SDP query finished.
In addition, it was discovered that service class ID list attribute
(its id is 0x0001) as reported by Apple may have a non-sequence type,
but UUID itself instead.
Fixes: QTBUG-99673
Change-Id: I5464faa0a2eb350f738be0531e726f464c6f2caa
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit f00ea686c841e14a89bd776ac3b86766a4980bb3)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Windows IDataReader::ReadGuid function, which is used to read long
128 bit UUIDs from the SDP results, gives the last 8 bytes of the UUID
in reverse order. This commit reverses the byte order.
Without the correct byte order the UUIDs of the services are
reported wrong, and for example the uuidFilter does not work reliably.
The original bug was that the "pingpong" Windows client never finds a
Linux pingpong server. It turned out that it finds it, but interprets
the UUID wrong. The same interpretation error can also be seen against
an Android server. Running the pingpong client against an Android server
however works for the reason below.
This issue has gone undetected so far because the serviceID field is
read differently using different interface and method, and as a
consequence has made the uuid filters to work against some platforms.
Fixes: QTBUG-99689
Change-Id: I71ab44264579f9eb46461ed8fdd7a49dbf402531
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 0dd124498e91308eb7ac16e976049b431770f7ef)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes: QTBUG-99410
Change-Id: I600a861821b87978b9bbcd425d30f49ba6b1aeea
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 6224fee61f0e8a77031dbd7edbb87bd77c43d710)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The m_pendingPairedDevices variable keeps track of if there are more
devices which should be discovered. The counter was decrement twice
instead of once leading to possibly non-ending discovery or missing
a discovered device.
This patch also introduces a helper method to decrement-and-check
the amount of pending paired devices.
Using this method in classicBluetoothInfoFromDeviceIdAsync allows
to properly finish device discovery in case of an async operation
error for the last device in the list.
Task-number: QTBUG-99685
Done-with: Ivan Solovev <ivan.solovev@qt.io>
Change-Id: Iaa36b212e8754940d9d574a60379fa0c32fdad2c
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 0c76617b0cbb7ad4903c2573c206e00bfb6add59)
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The service scan is split in two phases. First we discover the available
devices and then we scan each discovered device for their services.
The problem was that the Windows bluetooth backend scanned only the
device that was discovered the last and then stopped. This patch
addresses this by making the scanning logic to follow that of the
other backends (Bluez, macOS, and Android).
The change required also some adjustments to the stop() logic where
the Windows backend did not send the canceled() signal. The worker
"cancel logic" is nonexistent and does not produce the signal. A related
issue was that the stop() function is called both by
the baseclass and the windows specialization itself for slightly differing
purposes => needed to be split in two: releaseWorker() and stop().
Fixes: QTBUG-99687
Change-Id: Ie9e25cf0261c5259125dd0f4c6305ef1a99051e7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 30390a1285c631b766d98fc8dd79d9d9ec6a5eb0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The m_timer and m_serverInfo instances are created using 'this' as a
parent, so we do not need to explicitly delete them in the destructor,
but let the parent object deal with them.
This also prevents a crash at application close.
Change-Id: If91f01e1ab6dc8e839a06773464eeb9858d2fd36
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 4d2df2461f304eb7e1db5030e1c63d17bc2bac85)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Android implementation uses timers to check for services with a delay.
At some point it could lead to a state, when all discovered devices are
handled, but the timers for service discoveries were still active.
Before the patch, a finished() signal was emitted in such case, and
later, when the timer expires, the services got populated and we
received a serviceDiscovered() signal.
With this patch, we do not emit a finished() signal when the timers
are still pending. Instead the signal is emitted from the slot (which
was done anyway).
Change-Id: I55485ed842ff45f8aedfdca92b3fb1ee0adbae37
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit c24a04ba4beb719ed423f69f80850d0bea5903b9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The service info returned by the QBluetoothServer::listen() overload
that returns it needs to be stored or otherwise it will be destroyed.
The consequence was that the SDP "advertisement" didn't properly
include the added pingpong service record on Windows.
Task-number: QTBUG-100042
Change-Id: I79cbd0f574e35bbc1c9c3123ce8382f3aad296d4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit debf0fd212b232bcd83c8bb8f51ba2bad2f57a1c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To register a service record 'bluetoothd' now (on Monterey) wants us
to have ServiceClassIDList. This fixes the test from RfcommProtocol,
but not L2CAP (which we consider non-working in such form).
Task-number: QTBUG-98955
Change-Id: I4c8c9e4ca38f0ac86b7fb6cb039b430688b4b359
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit b4621669c7bff244ad490a21e3faf1ec51ba28a4)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Normally, we set it to 15 s. when creating inquiry instance, since Monterey
our 15 s. are ignored and we had a timer to stop the scan in 30 s. Now that
tests are runing on CI a painfully long timeout is not needed. Make it 17 s.
in case IOBluetooth will be able to stop in 15.
Change-Id: I8e07c2a3f3c46bed3780f3287e637b5324660305
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit 24674633ecebc85f09fe8bd5babeba9abe0ee3e0)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Android BT LE Client is a threaded feature; the Java-side callbacks
from Android execute in different threads and JNI calls from Qt/C++
execute in the Qt thread.
This commit augments the existing protection by synchronizing the
accesses to shared variables on the client object.
Task-number: QTBUG-98351
Change-Id: Icb39499c42bbdeec5e65ed5368294e1c631d3bfa
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
(cherry picked from commit a8e6de3863c89db251e6420a70351860c375b3f3)
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The last onReadyRead callback can come after the object is destroyed.
Protect against it by wrapping 'this' in a QPointer, and checking
the QPointer in the callback.
Fixes: QTBUG-98719
Change-Id: I3d5200e29744012815cd168a340bc617f85c6540
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 79a1523ed6262ccd148173ec8732865c0721063a)
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is needed to run the test cases on macOS 12. Also enable
the tst_qlowenergycontroller test to run even if the sensor tag
device is not found; the test contains functions that don't use it
(the ones that do use it will skip).
Task-number: QTBUG-98817 QTBUG-98816
Change-Id: I41369b7bfcea4de6c47428657881d9bab05a093e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The m_initialReadOp member of the SocketWorker class is used only once,
to perform initial read. After that m_readOp is used for all other
reads.
I see no reason why we need a separate variable for the first read, so
this patch uses m_readOp instead. This allows to simplify the code by
removing some duplication.
Change-Id: If4dd57c9f080d90c975cef676c1bf84cedf44178
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 54a856d8f654fb6183c772b4eaacd92703d22062)
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QLowEnergyController connection helper object was calling CoInitialize()
in connectToDevice() and CoUninitialize() in its destructor.
This was working fine on Windows 10, but on Windows 11, in case when
the connection attempt is interrupted by a disconnect request, it was
crashing.
The stack trace showed that Windows 11 is trying to do more COM-related
calls after CoUninitialize() is called. Specifically, it was calling
CoIncrementMTAUsage(), and some others.
This patch replaces CoInitialize(), which uses a single-threaded
apartment model, to CoInitializeEx(NULL, COINIT_MULTITHREADED) that
uses multi-threaded apartment. It also explicitly clears the
ComPtr-based class members before calling CoUninitialize().
These two measures help to prevent the crashes. Although I do not
completely understand why it helps.
Fixes: QTBUG-98582
Change-Id: I6fe5a877dbc2c0518ba97fddb132c2f87fc397c2
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 6b910367d859504a0bb48b82e6a2400f76e35241)
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
|
|\ \
| |/
| |
| |
| |
| | |
tqtc/lts-5.15-opensource
Change-Id: I4d53774cfe0783f50a123158d8bac7a02c382968
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we try to query local or remote socket info (name, address, port)
before the connection is actually established, WinAPI will return
a null instance of HostInfo for both local and remote hosts.
This patch adds checks that these objects are not nullptrs before
extracting data from them.
Change-Id: I137f1270c1c7d95a1935cc8565cda6c9f7814292
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 45f9e9fcb054c28bc59f6cc480eb08e9b13e5f0f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Java-side callbacks and the Qt-initiated JNI calls execute
in different threads. This commit introduces safeguards on these
potentially concurrent activities.
The thread protection is done by synchronizing the methods on the BT
LE Server object, which owns the shared variables.
Task-number: QTBUG-98351
Change-Id: I908cc395c705b21cbebe64fbce6874e351b6ef13
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit e0ee1dc44e57b220f6e9fc628b6f56d4b4d870a5)
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
WinAPI returns the address with parentheses around it. QBluetoothAddress
constructor does not understand such form, so we need to explicitly
remove the parentheses.
Change-Id: Ie2665b3dbe7bd001160ba01aa1db9beb1b8d4d86
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit aba20224710bf66c23909ef1d1f542eaeeeedbce)
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this patch we were querying local port for both localPort() and
peerPort() calls. This patch fixes it.
Change-Id: Iac1689ab22a010539c27c4890137cab8f7be5e10
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 973f8c6225016fe57d9e62946292f856f369561a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since Android 12 it's mandatory to specify the mutability of each
pending intent. In NFC we require a mutable intent, so we need to
conditionally use FLAG_MUTABLE. This was a default value for an
intent before Android 12, so no adjustment is required for earlier
versions.
Fixes: QTBUG-98073
Change-Id: I9a478db016bf9646d84d6e458647614785005977
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 3753c53fc810c292db93fcfbafffbc097afb0ed1)
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise word in line join without space in between.
Change-Id: I558daa0a26358d435d6000f73c65fb9a0054f53e
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
(cherry picked from commit 819629896fe080bdd79c96a5eb75eec6c368e563)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Windows implementation of QLowEnergyController is using helper threads
to perform device connection and characteristics read for services.
In both cases a new QObject-derived class instance is created and moved
to a helper QThread. A QThread::finished signal was used to destroy both
the helper thread and the object. This was creating a situation when the
order of destruction for a thread and a nested object was not specified.
In practice that could lead to hangs when reading multiple service
characteristics, which is specially seen on Windows 11.
This patch uses QThread::finished signal to destroy only the nested
object. Later on, the object's QObject::destroyed signal is used to
destroy the thread itself.
Task-number: QTBUG-97578
Change-Id: Ic973b835496b6098d47cd1e124315903c143e3e1
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 981e3f10f48580641f5e2365953ec8a17b5c96a2)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
or not having proper entries that required on iOS and (starting from
Monterey) on macOS (but LE only). Without them, app crashes due to
exception thrown by the framework.
Task-number: QTBUG-97900
Task-number: QTBUG-96557
Change-Id: Ia1463fa4361884936594780312586eb17f8fe075
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit dfa20ef097459587ef9086dd6f4edd313123676b)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The connection between QWinRTLowEnergyServiceHandler::charListObtained
and a corresponding lambda was established using a 3-argument version
of QObject::connect, which is implying Qt::DirectConnection.
This means that the lambda was actually executed on the same helper
thread that was responsible for reading characteristics.
This is not the intentional behavior, because it could result in a
concurrent access to serviceList. Also registerForValueChanges()
could be called from multiple threads.
This patch uses the 4-argument version of QObject::connect, so that
Qt::AutoConnection is used. It means that the lambda will be executed
on the main thread.
This patch also removes a duplicated call to thread->exit() from the
lambda. The original call is already performed in a method that emits
the signal. It was not an issue with Qt::DirectConnection, but can be
a problem with the fixed behavior.
Task-number: QTBUG-97578
Change-Id: Ia363489024e46e2879a4bd5e56c2ab8cd6606306
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 4ecc718d418689b9b9b66086ef4d041a21f44327)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If services were added in a tight loop sometimes the services are
created wrong. In practice this results in a situation where a client
reads a characteristic value from "Service A", but gets the value from
"Service B" - even if the client had no knowledge of "Service B".
The problem is that according to Android documentation, the
BluetoothGattServer::addService() must not be called before the prior
added service has received a
BluetoothGattServerCallback::onServiceAdded() -callback.
This commit serializes/queues the service additions.
Fixes: QTBUG-96742
Change-Id: I42c980600419787d4490d1a1059e3893597cb7cf
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 4deb789fe67615ebfa99af6f1071d20b0265a2e9)
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The default-generated Info.plist is not enough on macOS 12 Monterey
as the Bluetooth examples require NSBluetoothAlwaysUsageDescription key
to work properly.
Note that the plist files are only effective if the application is
started as an app bundle, ie. not if launching the contained binary
directly.
Task-number: QTBUG-98090
Change-Id: Iedb7eabbb8fde6ad1ba14ada1a7ee87ec1d708ba
(cherry picked from commit 70d590a81cae3c122c68bcb4521f21771cf02d40)
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the past, QBluetoothLocalDevicePrivate was releasing its instance
of DarwinBTConnectionMonitor, and IOBluetoothDevice was not retaining
this object, thus the correct behavior was assured. Starting from
macOS 12 the behavior changed, just releasing in a dtor is not enough
anymore, instead we should unregister 'monitor' manually, so that
IOBluetoothDevice releases its ownership too. The problem was found
when connecting to LE device which is Classic device at the same moment,
resulting in IOBluetooth sending a notification to the monitor object,
which has a dandling pointer to QBluetoothLocalDevicePrivate.
Fixes: QTBUG-97900
Change-Id: Idcc1233ce51795c561dbee8fd6d9a7aff592a5a2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
(cherry picked from commit 370de7fe8447b8d2216a4cd130df211b05260b8c)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
|
|\ \
| |/
| |
| |
| |
| | |
tqtc/lts-5.15-opensource
Change-Id: I5f92cce8507becd3683f24177d0f0251848b9cdc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The characteristics read was using IAsyncOperation->put_Completed() to
process the results of descriptor reading. Each of these completed
callbacks is executed in its own thread. In our case each of the
callbacks is also calling QWinRTFunctions::await() to perform some
async operations.
As a result, if the service has a lot of characteristics, we could
end up spawning multiple threads, each of them doing some CPU-consuming
operations. Normally it's not a problem, but looks like for some
bluetooth peripherals reading the characteristics can take significant
time. Connecting to such devices can result in 100% CPU load for all
cores if the number of characteristics exceeds the number of logical
CPUs.
This patch removes the put_Completed() approach in favor of another
QWinRTFunctions::async() call. This will guarantee that all the
characteristics read operations are performed in the same worker
thread. As a drawback, characteristics reading becomes sequential,
which makes it slower.
Fixes: QTBUG-97242
Change-Id: If46c3f0afe13a56d93f2b8fc46b87a2c90555bf3
(cherry picked from commit 2a7ef291d696745887e71f8b0e27cb4c8701bdd2)
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce a separate worker that will do all the system calls in a
separate thread and emit a signal once it's done.
This will allow to avoid the crashes caused by disconnectFromDevice()
being called while connection is still in progress and spinning in the
QWinRTFunctions::await() method.
Basically this patch moves the connection code to a separate worker,
and introduces new macros to handle the errors.
It also makes use of the new early return condition of
QWinRTFunctions::await() that was introduced in
1f86957f1dd14cc538e7ad9ffee4eb63001af407.
As a drive-by: increased the characteristics read timeout, because
the initial one was not always enough even for a turned-on device.
Apart from that this patch also solves some other issues and crashes
that could happen due to async nature of some calls. For example:
- handle the fact that service discovery might finish after the
device was disconnected. No need to notify about discovered
services in this case.
- add missing checks for thisPtr != nullptr in some callbacks that
capture thisPtr.
Task-number: QTBUG-96057
Change-Id: Ia2d044a89e3427a53d0879e045b6230d16bac3ce
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit a00ffdfc3569a5741bc42739570dea2ec52b7f0f)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The BT LE connectToDevice() method on Windows was a synchronous
operation for the caller by blocking while spinning the event loop
to keep rest of the application responsive.
Other platforms behave differently. This commit makes the connect
call to return immediately while scheduling the connection in the
background.
The QTBUG-83633 was originally about slightly different crash which
seems not be reproducible anymore, but this crash was found while
investigating that and is investigated in that item.
Task-number: QTBUG-83633
Change-Id: I092a94f2437351d27da758db6746f5b24d5fa9c7
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 3fc3716e0cd209cd9475d632925a9148b40b2f1d)
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The connection method was infinitely trying to connect to a specified
bluetooth device, which does not make much sense and could lead to the
application being stuck.
This patch limits the connection attempts to a reasonable amount of
time. If the connection was not established within this time,
ConnectionError is set and controller state is reset to UnconnectedState
Fixes: QTBUG-80719
Fixes: QTBUG-89149
Change-Id: Ib8efb690a8b0485c8e9d4844799c7332ab81bf97
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 007dcbf074a9e4d72e2a29a4a28ac5e502830e20)
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit amends 83a845aa0e5bb155fae3f1d5d27bb80801f90935.
The callback can be called after the worker was deleted.
Task-number: QTBUG-96057
Change-Id: Ifbd58b240667bd5ff805b4250cf98a9fd2f96e90
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit 3573702aa81f3f7ea20e947dbd27c5d1122cc42a)
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If 'inquiryLength' was ignored. This change is to be revisited
after the official release of macOS 12 - it could be a bug in beta
versions and all this additional timer machinery is a waste.
The fact I was able to observe the same problem with 10.15.7
is quite troublesome though.
Fixes: QTBUG-95960
Task-number: QTBUG-95686
Change-Id: I56685e07791dd751aec81bebbeefde19d31555df
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
(cherry picked from commit cf8ade9fd809e62cb61bb897b3789c75a48f5996)
|