We have an application that's using a Socket Mobile scanner (a CHS 7Xi, in particular) to scan bar codes from a variety of sources. We're using the latest SDK. It appears that sometimes—not always—when the app resigns and then regains active status, the SDK is unable to reconnect to the device. We get a few error notifications through the delegate protocol (specifically, ESKT_UNABLEINITIALIZE), and then nothing. Fixing this usually involves quitting the app, restarting the scanner, and starting over.
Does anyone have any idea why that might be, or how we can prevent this?
EDIT: hrm. The problem described in this Socket Talk blog post sounds familiar. Though it claims that the issue was long-since fixed in the SDK we're using (10.0.9.10686).
Related
I am working to build the PJsip project for iOS 16(i.e Xcode 14) where I am using the “c” based library PJsua. I am able to make calls using free SIP accounts created on Antisip.com.
Problem: Not able to hear any sound on my iOS device after the call gets connected to my VoIP server(which is modified to play only the recorded message).
I have analyzed the server & mobile app logs but have not observed any errors. Also haven’t noticed any difference in server logs for calls done via old and newly built PJSip project.
I did a lot of research on it but am still stuck on this sound issue. I am not sure if I am missing anything related to audio configuration or if anything is specifically required for iOS 16.
Other details:
TransportType: TLS
OpenSSL: 1_1_1r
Server: kamailio (5.2.0 (x86_64/linux))
Kindly help if someone has any idea on this.
NOTE: Although, not facing any issues and able to hear the voice if the call is made using previously built(using iOS 11 SDK i.e Xcode 9) PJsip project.
Following iOS 14 new policy of blocking access to local network, a com.apple.developer.networking.multicast special entitlement is needed to access the local network, and this access should be confirmed by user during an authorization dialog. Although this new feature is not thoroughly documented, Apple engineers have indicated in forums that this authorization dialog popup is only triggered when the app tries to send traffic, causing an issue for apps reading only the network, as indicated in iOS 14 How to trigger Local Network dialog and check user answer?
Unfortunately, the advice of sending some data to trigger the authorization dialog does not seem to work in our case, as we never got the popup dialog appearing.
Our app usually only receive UDP broadcast (no transmit except in a few cases). We have got the com.apple.developer.networking.multicast entitlement, have added it to our app entitlements, have added the requested NSLocalNetworkUsageDescription in our Info.plist and are signing our app manually using XCode 12.0 with a provisioning profile including this entitlement (manual code signing is needed in this case as indicated in https://developer.apple.com/forums/thread/656773?answerId=628537022). Since then, situation has somewhat improved as the UDP packet reception that was fully blocked before adding the entitlement started to work sometimes, but unfortunately not always (situation seems worse on iOS 14.0.1 than on iOS 14 and on iPhone than on iPad).
Most importantly, we never got the authorization dialog displayed and our app does not appear as authorized in Privacy/Local Network (even when UDP reception works). We suspect this may be the cause for this spurious reception issue. As it seems the authorization dialog is only shown when sending data, we configured our app to send data to the local network to try to trigger the dialog, using all below methods:
TcpSocket class (using CFStreamCreatePairWithSocketToHost) to connect to 192.168.1.1 on port 80 and send a few bytes (there is a device at this address)
using GCDAsyncSocket to connect and send a test TCP packet to same address/port
using GCDAsyncUdpSocket to create a UDP socket, enabling it for broadcast, then joinMulticastGroup 224.0.1.0 and broadcasting a test UDP packet on port 80.
using GCDAsyncUdpSocket to create a UDP socket, enabling it for broadcast, then broadcasting a test UDP packet on port 80 to 255.255.255.255.
reusing the example from Apple article (https://developer.apple.com/news/?id=0oi77447) sending multicast packets with NWConnectionGroup to 224.0.1.0
and finally using the triggerDialog() method of class LocalNetworkPermissionService indicated in iOS 14 How to trigger Local Network dialog and check user answer?
None of the above actions triggered the authorization dialog on iOS 14.0 and iOS 14.0.1, and our app is still not listed as authorized in Privacy/Local Network, with spurious reception of UDP packets.
If somebody has encountered the same issue and found a solution, many thanks for your advice.
Thanks to #Columbo and help from Apple, a solution has been found, although the root cause of the issue is not yet fully understood.
Our app was built with a iOS release deployment target of 9.0 because we tried to preserve compatibility with older devices. It seems a deployment target lower 12.0 may cause issue with the network privacy management. The solution was then:
to rebuild the app after updating the iOS deployment target to 12.0 or higher.
for all iOS 14.0 and 14.0.1 devices having a previous version of the app already installed, to fully delete the app and install it again (updating the app was not sufficient, the network privacy alert was still not shown).
Of course, this procedure is not ideal for users that will have to reinstall the app from scratch and configure it again. I will update this thread if a future version of iOS avoids this issue.
Update: when using iOS 14.2, the app is correctly triggering the network privacy alert even after an upgrade (without full deletion and reinstall). We then recommended our users to upgrade to 14.2 before upgrading our app. We have kept the deployment target at 12.0
To those who suddenly find that APP ask this authorization, and don't suppose it appear. The answer is that maybe your APP trying to connect to your test server which in same LAN with your iPhone running iOS 14.
For 14.2, the local network access is handled little better and there is a sample code used to trigger this alert as mentioned in https://developer.apple.com/forums/thread/663768
Also you can create dummy connection using NWConnection, this will trigger system dialogue for asking permission (if system dialogue is not shown anytime before) and check the local network access is allowed or not as mentioned in https://developer.apple.com/forums/thread/663769 , this is available from iOS 14.2.
I am working on an mbed powered Bluetooth Low Energy project. I have been developing various GATT services, however, I have now found my project has got "stuck" on a previous service. What ever program I download onto the device, a Service is broadcast with the name "HRM_SEC". I have repeatedly changed the name from this.
I have installed known working examples of default Heart Rate Monitor Example. I have installed blank programs without bluetooth service definition etc.
However, the name of this prior service is persisting.
I have reinstalled my ios app - LightBlue - incase it was a casheing thing. By reinstalled I mean deleted and then downloaded from app store.
I can't connect to these services. New programs are being installed, as I am getting the expected serial feedback.
Why is this happening and What can I do?
I have just tried using the LightBlue app on a different iPhone and I am getting the expected behaviour. How can I purge the stored data from the LightBlue app. I have tried deleting it, then doing a reset (holing lock and home button), then when it has rebooted I re-downloaded the app from the app store. What else can I do to clear which ever info is being stored by LightBlue?
This seems to be an underlying iOS issue, as my other apps are also now using this legacy name. I have tried disabling and then enabling Bluetooth, but this hasn't worked. Any other ideas?
I have submitted an iOS bug report. This is really annoying, as I cannot use my iPhone to test an app I am working on. Any ideas for workarounds?
I have created an iOS app that interacts with a bootloader on some custom hardware/firmware to update the application on the hardware. In order to accomplish this, the hardware/firmware has a bootloader application and a regular application. First, I connect my iOS app to the bootloader application and update the regular application. At which point the regular application starts to run and I would like to connect to it with my iOS app.
If I search for peripherals with an Android application it correctly sees my hardware broadcasting as the bootloader application and then switch to broadcasting as the regular application after the update has been completed. However, for some reason, the equivalent iOS app only sees it being broadcast as the bootloader application. I have found that if I restart the iOS device or if I turn the iOS device's bluetooth off and back on after a few seconds it will finally recognize that the regular application is broadcasting.
It seems as though the iOS device is caching the peripheral information. Does anyone know if there is a way to clear the cache or refresh to get the current/valid status of the device?
I have exactly the same issue here, unfortunately this is indeed due to iOS. There are a lot of other threads about this topic but after looking for a while I would recommend this answer :
https://stackoverflow.com/a/25930825
Best of luck, I haven't finished yet and this won't be easy...
My app uses BLE (Bluetooth 4) to connect to a physical peripheral.
My users and I have repeatedly encountered a bug where, at some point, the app stops connecting to the peripheral - you can see an indication that the BLE peripheral is discovered and the connection was established, but then few seconds after, the connection is dropped.
Things go back to normal only after restarting the iDevice.
I’ve done a very long work on checking it and researched this issue thoroughly, until I got to the conclusion that this must be a bug in iOS (tested with 7.1, but probably occurs on 8.0 as well).
My tests and findings:
Occurs with every BLE supporting iDevice.
Occurs with both my own BLE peripheral and with other 3rd party BLE products, both known to work perfectly in normal cases.
It can sometimes work well for even 50 launches, but then eventually it’ll fail.
Network & factory settings reset did not help.
Tested and occurred with various applications: ##
My own app.
Clean new Xcode project that’s only scanning for peripherals and trying to connect to the first and only discovered peripheral.
Apple’s BLE example app: Health Thermometer (with relevant modifications since I don’t have this particular peripheral).
3rd party apps, including the generic LightBlue.
Important note: Every one of the options above worked perfectly for a while (multiple launches), at some point suddenly stopped and then worked again after a restart of the device.
The connection procedure seems to fail when trying to discover the peripheral’s services - i.e. it gets discovered and connected normally, but when initiating discovery of services, it stops responding (didDiscoverServices isn't called).
I have of course tried many approaches found online with no luck.
Can anyone shed some light on this problem?
Is it a known issue?
Was it fixed in a recent iOS update?
Is it going to be fixed?
You can imagine the negative affect such an issue has on my users’ experience, as BLE connection is essential to the product.
I'll appreciate your advice and suggestions on how to solve it.
Thanks!
Update:
Apple responded to my tech support request:
Bottom line(s):
They said they had fixed some BLE related bugs in iOS 8 and urging us to test if it still happens in iOS 8.
They said to start with that and if not, try to diagnose the problem with a utility app they provide.
So far for me it didn't happen with iOS 8, but on the other hand I can see posts about other Bluetooth issues, that are not necessarily related but who knows.
Full answer:
I’m responding to your finding that you and your customers find that
after some point of use, iOS BLE fails to maintain a connection. You
indicate that the problem was identified with iOS 7.1. There have been
issue regarding iOS BLE which have been reported and have been fixed
with iOS 8.0. To best determine whether your issue has been addressed,
of course the simplest means would be to install iOS 8 and to see if
the issue can be replicated. However, as you report that you can
replicate the problem on your deivce with iOS 7.1 the first thing
would be to obtain the Bluetooth Server profile, install it to your
deivce, replicate the problem, then obtain a BLE Server log when the
problem occurs. The profile will have the BLE server report additional
logging details which can help to report issues that the server
encounters. We can see if the issue is one which has been reported
previously. Something to consider is that for all new bug report
issues, Core Bluetooth engineering is requesting that all issues be
regressed with the currently shipping version of iOS - that is 8.0.
For customers with iOS 7.x, there will be no more iOS 7 updates - all
software fixes and bug fixes will be with iOS 8. For this reason, only
issues which are reported with iOS 8 will be investigated. You can
obtain the BLE server profile from the Apple Developer bug report web
page https://developer.apple.com/bug-reporting/ios/bluetooth/. The
instructions for installing the profile and capturing the log, are
presented on the web page. If you capture a log with iOS 7.x, you can
send it to me for review. However, this will be somewhat of an
academic exercise - to know if iOS solves the issue, or whether it
persists, we will need to see if the issue occurs under iOS 8.
Something to keep in mind, once you update a device to iOS 8, you will
not be able to restore it to a previous version. I’m happy to
review your results. If however, the problem persists under iOS 8,
it’s best to submit a bug report to get Core Bluetooth engineering’s
attention on this matter. You can submit a bug report using the Apple
Developer bug report web page. - http://bugreport.apple.com
So it looks like the problem is solved with recent iOS update (either 8.0 or 8.1).