[iOS, Bluetooth] App crash when disconnected (__CRASHING_DUE_TO_PRIVACY_VIOLATION__)

[Rollo62 536]

Dear all,

I have a strange behaviour when using Bluetooth LE.
In my apps I use the same, well tested BT library in many apps, which works fine so far.
Now I have one app that crashes in foreground, with  exception "Project TestApp raised an exception class 6."

Quote

4   TCC 0x000000021c943a90 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 0
5   TCC 0x000000021c94792c __tccd_send_message_block_invoke +

The stack trace shows similar __CRASHING_DUE_TO_PRIVACY_VIOLATION__ message, but the rest is not very helpful.
There is no reference to any of my units nor at least anything that could be explaining why this happens.
I've tried a lot to re-order and try add/remove several features, but I couldn't receivce any clue from this, the error stays there and is reproduceable.

What I've found out so far is that is might be related to the iOS background mode permissions

Quote

bluetooth-central
bluetooth-peripheral

I want to be able to receive data from a before (in foreground) connected device, which would require bluetooth-central usually, but to keep
the connection active during background bluetooth-peripheral seems to be necessary too, although I don't use it that way.
At least this configuration keeps my data running in background as well, as intended.

I use it the following way:

• app in forground
• discover IoT devices
• connect IoT device
• receive data from the IoT device (every second)

so far this works fine

• app still in foreground
• the IoT device disconnects
• the app closes the connection
• at that point suddenly the crash appears

 

So far when I use the SAME bluetooth library, doing the same things, no crash happens.
It seems to be related to the background modes, only when they are defined, then it crashes (also in other apps, not using background mode).

 

There are some infos in the web about __CRASHING_DUE_TO_PRIVACY_VIOLATION__, which seems to have to do with accessing private parts,
like photo or other gobd relevant data (at least I could imaging that these requirements could cuase such crash).
But I don't really use any of such in my app, nor that I even touch anything during disconnection of an IoT device.

 

What I can see before the crash is an exception in the IDE while debugging: "Project TestApp raised an exception class 6."

 

I have no more ideas howto debug this issue, since this seems to happen deep inside iOS.
So far I tried to remove all other relevant aspcets around, but none of them seems to change anything.
Enclosed you find a crash report from iOS, the callstack looks similar and never gives any reference to anything I would see relevant.
 

I hope you have some hints or solutions, howto fix this.

 

Edit:

Ja, writing a thread is a good way to rethink and find possible reasons

Quote

Important: Do not forget to add the flag Privacy Flag - Bluetooth Peripheral Usage Description so that the user allows the app to use the device as a peripheral, just as we do when we want to use the camera or location.

This could be the reason of coarse, I will try how thisa flag could be added, since I think its not in the usual version info.

 

Edit2:

Yes, this was the reason.
After adding these 4 lines in the info.plist.TemplateiOS.xml template file it keeps working.

Quote

<key>NSBluetoothPeripheralUsageDescription</key>
<string>The app needs bluetooth access to be able to process data from an IoT device in the background</string>
<key>NSBluetoothAlwaysUsageDescription</key>
<string>The app needs bluetooth access to be able to process data from an IoT device in the background</string>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<%VersionInfoPListKeys%>
<%ExtraInfoPListKeys%>
<key>NSBluetoothPeripheralUsageDescription</key>
<string>The app needs bluetooth access to be able to process data from an IoT device in the background</string>
<key>NSBluetoothAlwaysUsageDescription</key>
<string>The app needs bluetooth access to be able to process data from an IoT device in the background</string>
</dict>
</plist>

Oh, how I hate these permission crashs, without any notice.

Those changes in the template file might get lost when the IDE has to re-create this file, so this is another point of failure, but I'm well aware of this.
Would be great if Embarcadero could offer a way to add such additions in the version

 

Now I've got a permission request message like "Bluetooth want to share data with devices around ...", which I have to enable.
What is strange, that this doesn't appear at app start, but only when a device disconnects.

Another strange thing that I have to re-start an IoT twice now, before it gets detected again, but maybe this is due to my test settings here.

I hope somebody has a good explanation and solution to these questions also.

Maybe there is a workaround for that, but at the moment I'm happy that the crashes are gone.
For the rest I have to do further testing now.

I don't understand how Embarcadero get Beacons working in the background, which should basically use the same settings as I do here.
Never had checked with beacons, maybe one day in the future, but they are also using only the BLE framework ,as fas as I know.

Either all beacons might see same crashes, or Embarcadero made a trick to make them work silently.

Maybe sombody has experience with beacons, bluetooth and background modes ?

 

 

 

CrashReport.txt

 

Edited August 8, 2019 by Rollo62

[Dave Nottage 557]

15 hours ago, Rollo62 said:

I don't understand how Embarcadero get Beacons working in the background

They haven't: there is critical code missing that allows them to work in the background:

https://quality.embarcadero.com/browse/RSP-21460

 

[Rollo62 536]

@Dave Nottage
Well, is that line of yours an advertisement for BeaconFence ?

 

I were lucky to use Bluetooth in foreground up to now, but it should be possible with the background modes.
Why else did Embarcadero added them ?

Is there any way to get background modes working as expected?
I could already do background receive/transmit data, start Tts, place a local notification, etc.
when the app was in foreground and the phone is just switched off (to black screen).

But when the app is set to background before switching off (black screen), this might not work all the time.

At at least I would say foreground works very stable in my library (which took a long way),
the only problem now is the missing ability to reconnect at once, only 2nd power up of the IoT devices does the job.
There seems to be something strangely blocked in the BT system, I have to investigate in the FMX code.

Generally BT worked for me after long tests and finetuning, and one of the biggest issues from day one was
the disconnection of IoT devices.

While connection went more or less nicely, the disconnection may end in all kinds of strange behaviours,
which I think has to do with the mixing of internal BT threads and Delphi threads, to avoid UI blocking.
What helped me there was to completely destroy (free) the TBluetoothLEDevice variable, to get disconnection stable.
Especially disconneting is still a very fragile process, and I'm happy it works halfway stable so far.

 

 

Edited August 9, 2019 by Rollo62

[Dave Nottage 557]

3 hours ago, Rollo62 said:

Well, is that line of yours an advertisement for BeaconFence ?

I don't understand how you came to that conclusion.

 

3 hours ago, Rollo62 said:

Why else did Embarcadero added them ?

As far as I know, they haven't

 

3 hours ago, Rollo62 said:

Is there any way to get background modes working as expected?

Yes, with the changes I proposed in the QP report.

[Rollo62 536]

51 minutes ago, Dave Nottage said:

I don't understand how you came to that conclusion.

Sorry, I missed to put this in <irony> tags. Of coarse this is a nogo for Beacon apps, same as for BeaconFence.
Isn't there a big field of applications (if not the largest field) for beacons using the background mode ?

 

51 minutes ago, Dave Nottage said:

Yes, with the changes I proposed in the QP report.

These changes were for Beacons, but not directly for normal Bluetooth LE apps.

You mean keeping background mode like this

Quote

Open Project Settings -> Capabilities -> Background Modes -> Toggle Location Updates and Uses Bluetooth LE accessories to ON.

I wouldn't need the location update, and the BLE accessories is the " bluetooth-peripheral" flag, right ?
So do you mean here to use location updates to keep BLE alive in background ?

Keeping alive already does the " bluetooth-peripheral" flag for me, but with some side-effects.
Or with an ability to clear internal BT buffers after disconnected devices.

A better solution would be to use " bluetooth-central" only, in background mode, hopefully w/o any side effects.
But this I didn'T get to work w/o the " bluetooth-peripheral" flag.

[Dave Nottage 557]

12 hours ago, Rollo62 said:

So do you mean here to use location updates to keep BLE alive in background ?

No, I was specifically referring to Beacons. I expect the BLE issue is separate.

 

12 hours ago, Rollo62 said:

A better solution would be to use " bluetooth-central" only, in background mode, hopefully w/o any side effects.
But this I didn'T get to work w/o the " bluetooth-peripheral" flag.

Now I'm confused: does it work, and if so, only with both?

[Rollo62 536]

@Dave Nottage

Yes, it seems to work permanently in background only when I set both modes, but I do only use it as bluetooth-central.
Otherwise it could be killed within 10 minutes.
The iOS documentation tells me that background app can be killed anyway, no matter how many modes are set,
if the phone needs resources (so that doen't make me feel much secure in this area), although my app is not safety critical.

What I assume is that defining the bluetooth-peripherial seems to trigger the strange behaviour, which I haven't seen before.
Theoretical there should be nothing wrong defining a background mode that I don't use, but this rejects maybe some more customers from the app.
Anyhow, I have to do still more tests, but next week I'm on holiday, so won't be able too in short time.

I would be happy to see more developers with BLE running in foreground or background in general, so far I have seen '
only little feedback in these topics (to be fair I see also little feedback in Xamarin and other products forums).
There could be a solution to completely rework and rewrite the BT stack, but it still makes most sense to me to use the existing BT system, also because it shall work well on all platforms.
 

[Dave Nottage 557]

3 hours ago, Rollo62 said:

The iOS documentation tells me that background app can be killed anyway, no matter how many modes are set,
if the phone needs resources (so that doen't make me feel much secure in this area)

Unless your app is called "Facebook", "Twitter", or "Instagram", yeah 😉

[Rollo62 536]

I would like to get back to the original (and related) issues:

Its still not 100% clear what the reason is, but as a workaround I found that the follwoing method helps.

Simply wait 1-2 sec. after the disconnection of a device and cleaning up the BluetoothLE stack, before restarting the next DiscoverDevices cycle.

Seems that iOS needs some time to cleanup internally, and too early restarts might confuse the system.

There are different delay times from phone to phone (iPhone 6S differs from iPhone X and needs more time), which makes sense (different CPU, etc.).
When discovering is started too early, then I don't see the new device in OnEndDiscoverDevices, in my case I also see this never again no matter how often
DeviceDiscover is restarted, and so I will never be able to re-connect again.
Only a power down/up cycle the IoT device helped in that case (and I tried may different items from different vendoes, so its not a case of the IoT device).

Anyhow, not sure about the real internals, but I'm afraid adding some more time (I had 300ms before) raising to 2000ms will do the job for me at the moment.