The subject says it all, really. Documentation, insofar as it exists at all, suggests that apps written against the CoreBluetooth framework running on iOS devices can add “bluetooth-central” to their background privilege list and so process some kind of Bluetooth events whilst inactive, but which exact events do and do not get delivered?
For example:
- Can I carry on communications with a device I already established a pairing with?
- Can I issue periodic discovery requests to find devices which are out of range / I’ve never seen before? (For example if I wanted to be able to deliver a notification when a new interesting device is encountered)
- What if a device goes out of range and then comes back? Will I get disconnected and connected events without user intervention, or will I need to be foregrounded and have the user explicitly request reconnection?
Nobody seemed to know, so I bought an iOS developer account and ran some experiments. Here’s what I found:
When running in the foreground, you can start a scan using CBCentralManager::scanForPeripheralsWithServices. Your scan can be restricted to devices advertising a particular service, or unrestricted (pass nil for that call’s parameter). It can also allow or disallow duplicates; in the former case you’ll get a didDiscoverPeripheral callback every time the iPhone receives an advertisment packets; in the latter you’ll only get one callback per device found.
When you enter the background, the rules appear to be as follows:
I don’t know whether connect attempts to nonconnectable devices (e.g. BLE Advertisers, like those implementing the proximity profile) is good enough as my example devices are connectable. However at least for connectable devices, this scan/connect/disconnect/scan procedure suffices to poll for a device’s presence in the background.
The above results were gathered using an iPhone 4S running iOS 5.0.1