1. 08 Aug, 2022 1 commit
  2. 04 Aug, 2022 1 commit
  3. 29 Jul, 2022 1 commit
  4. 28 Jul, 2022 3 commits
  5. 27 Jul, 2022 8 commits
  6. 26 Jul, 2022 1 commit
  7. 19 Jul, 2022 1 commit
  8. 15 Jul, 2022 2 commits
  9. 14 Jul, 2022 1 commit
    • Assam Boudjelthia's avatar
      Android: skip some bluetooth test cases that fail on Android 12 CI · 969da302
      Assam Boudjelthia authored
      
      
      Android 12 sends popups to user about operations in bluetooth like
      enbaling or disabling or scanning for devices, and these popops will
      wait for user action. On CI or in qtconnectivity we don't wait for those
      so some tests are either failing or timing out. This patch skips the
      tests on Android 12+.
      
      Pick-to: 6.4 6.3 6.2
      Task-number: QTBUG-104914
      Change-Id: Ibadaf3a4d67170e33dcdcbe836c6d1a2e8a55c23
      Reviewed-by: default avatarIvan Solovev <ivan.solovev@qt.io>
      969da302
  10. 12 Jul, 2022 1 commit
  11. 11 Jul, 2022 4 commits
    • Ivan Solovev's avatar
      Windows: refactor device discovery · 9ab51220
      Ivan Solovev authored
      
      
      - Move the LE scan timer to the worker class
      - Introduce a separate function to check for scan finish conditions.
      
      These changes allow us to be more precise in deciding when to stop
      device discovery.
      For example, before this change we were unconditionally stopping the
      discovery when the LE scan timeout expired, even if the Classic scan
      was still in progress. That is fixed now.
      
      Fixes: QTBUG-103263
      Fixes: QTBUG-97797
      Pick-to: 6.4 6.3 6.2
      Change-Id: I8ab457971b95a7573483b9e6f4e8abbec97e9755
      Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
      Reviewed-by: default avatarJuha Vuolle <juha.vuolle@insta.fi>
      Reviewed-by: default avatarOliver Wolff <oliver.wolff@qt.io>
      9ab51220
    • Ivan Solovev's avatar
      Windows: refactor low energy device discovery · 36dd802c
      Ivan Solovev authored
      
      
      This is the continuation of porting QWinRTBluetoothDiscoveryWorker to
      C++/WinRT. This allows to simplify the code and completely get rid of
      COM APIs in qbluetoothdevicediscoveryagent_winrt.cpp
      
      This patch is mostly a plain rewrite, with minimal logic changes.
      
      As with classic device discovery, we need to remember that callbacks
      from async operations come in separate threads.
      
      We also wrap BluetoothLEAdvertisementWatcher into a helper class and
      use signals to notify about new data.
      
      Task-number: QTBUG-103263
      Pick-to: 6.4 6.3 6.2
      Change-Id: I3376930d145dccac2ded400e05c409f64fc24897
      Reviewed-by: default avatarJuha Vuolle <juha.vuolle@insta.fi>
      Reviewed-by: default avatarOliver Wolff <oliver.wolff@qt.io>
      36dd802c
    • Ivan Solovev's avatar
      Windows: fix Classic device discovery by porting to C++/WinRT · 2f560d04
      Ivan Solovev authored
      
      
      Start porting QWinRTBluetoothDeviceDiscoveryWorker to C++/WinRT.
      Use DeviceWatcher to discover both paired and unpaired Bluetooth
      Classic devices.
      
      Unlike old COM implementation, in C++/WinRT each callback for
      IAsyncOperation comes in its own thread, so we need to care
      more about thread-safety. As a result, we had to use
      std::enable_shared_from_this on the
      QWinRTBluetoothDeviceDiscoveryWorker to guarantee that it is
      alive when the callback is triggered, and also to use
      QMetaObject::invokeMethod() to check for the scan finish
      criteria. This caused some further refactoring of
      QWinRTBluetoothDeviceDiscoveryWorker.
      
      This patch leaves some TODOs to handle LE device discovery. This
      will be implemented in the following patches.
      
      Task-number: QTBUG-103263
      Pick-to: 6.4 6.3 6.2
      Change-Id: I9128fe7a65f1a5aedcba427d6944372ecfe33f2f
      Reviewed-by: default avatarJuha Vuolle <juha.vuolle@insta.fi>
      Reviewed-by: default avatarOliver Wolff <oliver.wolff@qt.io>
      2f560d04
    • Ivan Solovev's avatar
      Windows Bluetooth: move DeviceWatcher wrapper into a separate header · 761a059d
      Ivan Solovev authored
      
      
      The DeviceWatcher wrapper seems to be useful not only in
      QBluetoothLocalDevice implementation, but also for device discovery.
      This patch moves it to a separate header, so that it can be reused.
      The class' API is also refactored to suit for more general usecases.
      
      This patch also applies the changes to QBluetoothLocalDevice.
      
      As a drive-by: clean-up some includes and namespaces in
      QBluetoothLocalDevice implementation.
      
      Task-number: QTBUG-103263
      Pick-to: 6.4 6.3 6.2
      Change-Id: I470c6eab4810065c03d5905032f4288fa9d6de8e
      Reviewed-by: default avatarJuha Vuolle <juha.vuolle@insta.fi>
      Reviewed-by: default avatarOliver Wolff <oliver.wolff@qt.io>
      761a059d
  12. 08 Jul, 2022 1 commit
  13. 07 Jul, 2022 2 commits
  14. 05 Jul, 2022 1 commit
    • Timur Pocheptsov's avatar
      QtConnectivity/NFC: implement read/writeNdef for iOS · 8fd38321
      Timur Pocheptsov authored
      
      
      Similar to already existing 'tag type specific access', add
      a very limited support of NDEF access method. For this we use
      NFCNDEFReadingSession and id<NFCNDEFTag> in addition
      to NFCTagReadingSession (in qnearfieldtarget_ios private
      implementation). Session allows to detect tags and their
      capabilities, tag itself can be connected to and then
      NDEF message can be read/written.
      
      [ChangeLog][QtNfc][iOS] Added support for writing and
      and reading NDEF messages on iOS devices.
      
      Task-number: QTBUG-74052
      Change-Id: Iff848f8f56992cba237b4562543a10d45a14eea6
      Reviewed-by: default avatarJuha Vuolle <juha.vuolle@insta.fi>
      8fd38321
  15. 28 Jun, 2022 3 commits
  16. 24 Jun, 2022 1 commit
  17. 23 Jun, 2022 1 commit
  18. 21 Jun, 2022 4 commits
    • Juha Vuolle's avatar
      Add a timeout guard for Android BT device discovery not starting · eedaaca9
      Juha Vuolle authored
      
      
      In some bluetooth environments, after a full SDP service discovery,
      the device discovery can get stuck indefinitely. Everything seems
      to be starting fine but we do not get the DISCOVERY_STARTED action.
      In the normal case this action is received in < 1 second.
      
      This commit adds a timeout guard for this. If we don't get the
      DISCOVERY_STARTED action in time, we silently restart the query.
      Typically the discovery starts working after 10..20 seconds.
      
      Task-number: QTBUG-101066
      Pick-to: 5.15 6.2 6.3 6.4
      Change-Id: Id6032ebeec97d1ad9eec07a946bc623c92500fd5
      Reviewed-by: default avatarIvan Solovev <ivan.solovev@qt.io>
      eedaaca9
    • Juha Vuolle's avatar
      Android BT LE advertisement start to fail when bluetooth is OFF · 4292b32d
      Juha Vuolle authored
      
      
      When we start a BT LE advertisement while bluetooth is OFF, the
      advertisement should fail to start, and on the other hand when
      bluetooth is switched back ON, starting the advertisement should
      be possible again.
      
      This commit adds offline/online check to the startAdvertising function.
      
      In addition the creation of the advertiser is delayed until the first
      advertisement request. This delaying is done for the case when the
      bluetooth is OFF when the LE controller is created => we don't want the
      creation of advertisement to fail once during construction and therefore
      become unusable even if bluetooth is later switched ON.
      
      For completeness it should be mentioned that Android documentation
      mentions that the getBluetoothLeAdvertiser() returns 'null' if the
      bluetooth is offline. However on all the devices I've tried this,
      it returns a valid instance. This means that the creation delay of this
      commit would not be strictly speaking necessary. But we shouldn't rely
      on it: on some Android devices the advertiser might be returned as null
      when bluetooth is offline, as documented.
      
      Pick-to: 6.2 6.3 6.4
      Fixes: QTBUG-104106
      Change-Id: Ia016e4534c29fac23f42785d68bc95d568c41def
      Reviewed-by: default avatarIvan Solovev <ivan.solovev@qt.io>
      4292b32d
    • Juha Vuolle's avatar
      Fix Bluez LE advertiser delete crash · f1ff9f4d
      Juha Vuolle authored
      
      
      Bluez LE advertiser and Bluez LE controller use/share an instance of
      HCI manager, and in some circumstances the deletion of the LE controller
      leads to a crash. This is because:
      1) LE advertiser and HCI manager are parented to the LE controller
      2) LE advertiser uses HCI manager in its destructor
      => When LE controller is deleted, its QObject children are deleted.
         If the HCI manager happens to be deleted first, the advertiser uses
         a by-now deleted HCI manager in its destructor
      
      This commit makes the HCI manager a shared resource so that the exact
      destruction order does not matter.
      
      As a drive-by set deleted cmacCalculator pointer to nullptr.
      
      Fixes: QTBUG-104105
      Pick-to: 6.2 6.3 6.4
      Change-Id: I1c5e319af2fc59c4d5bb1fed33b8824eb3c4cb29
      Reviewed-by: default avatarIvan Solovev <ivan.solovev@qt.io>
      f1ff9f4d
    • Qt Submodule Update Bot's avatar
      Update dependencies on 'dev' in qt/qtconnectivity · a82105dc
      Qt Submodule Update Bot authored
      
      
      Change-Id: Ie0c027a330bdfe03471e29dc2735b4f9639986f5
      Reviewed-by: default avatarQt Submodule Update Bot <qt_submodule_update_bot@qt-project.org>
      a82105dc
  19. 20 Jun, 2022 1 commit
    • Andreas Buhr's avatar
      Repair tst_QBluetoothDeviceDiscoveryAgent unit test on Android · 32b859dc
      Andreas Buhr authored
      
      
      tst_QBluetoothDeviceDiscoveryAgent::tst_startStopDeviceDiscoveries
      was broken on Android. The sequence
      QBluetoothDeviceDiscoveryAgent::start()
      QBluetoothDeviceDiscoveryAgent::stop()
      QBluetoothDeviceDiscoveryAgent::start()
      QBluetoothDeviceDiscoveryAgent::stop()
      is called rather quickly.
      The first stop() results in the state
      pendingCancel=true, pendingStart=false.
      The second start() results in the state
      pendingCancel=true, pendingStart=true.
      The second stop() then did nothing because pendingCancel=true.
      Then, after the whole sequence, discovery started because
      pendingStart=true.
      This patch repairs it by setting pendingStart=false
      in the stop() method.
      
      Pick-to: 6.2 6.3 5.15
      Change-Id: I55486b5b494265c90149e72461a1d0529adaa2f0
      Reviewed-by: default avatarAlex Blasche <alexander.blasche@qt.io>
      32b859dc
  20. 15 Jun, 2022 1 commit
    • Mike Achtelik's avatar
      QtNfc: Fix iOS session invalidation/restart · a113cea7
      Mike Achtelik authored
      
      
      Fix a problem where the user is able to get into a state, where iOS NFC
      implementation deadlocks itself, so the whole app has to be restarted
      to get it working again.
      
      Basically, if we (or the user) abort a scan sessionStoppedByApplication
      will be set, preventing a new scan until the session is invalidated by
      the system and sessionStoppedByApplication is cleared. The problem is
      that sometimes the invalidation by the system takes some time, especially
      if the sessions is transmitting and waiting for a timeout. In that case,
      the user is able to quickly start a new scan, which will of course wait
      for the flag to be cleared. However, if that scan is immediately stopped
      again self.session will be set to nil. This then becomes a problem, when
      the original session finally invalidates and we now think it's an
      unexpected session and return. This means self.sessionStoppedByApplication
      will never be cleared, preventing any start of the scan.
      
      To fix this we should always wait for the system to invalidate the
      session and not just clear it ourselves. Similarly, if we already have
      a session don't just to restartPolling, since it has no effect on
      an invalidated session, so invalidate it to make sure and wait for
      it to clear and start a new one.
      
      Pick-to: 6.4 6.3 6.2
      Change-Id: I341a114d6ba5c761aa3c61df66b1a17636ec3946
      Reviewed-by: default avatarJuha Vuolle <juha.vuolle@insta.fi>
      Reviewed-by: default avatarTimur Pocheptsov <timur.pocheptsov@qt.io>
      a113cea7
  21. 13 Jun, 2022 1 commit