Closed marcuspridham closed 3 years ago
I'm wondering if this has something to do with the implementation of AirTags and the "Find My" feature in the latest iOS versions.... Since the AirTags rely on a consistent BLE connection to transmit data across the "Find My" network, is it possible that the BLE APIs were changed in a way that is causing the issues here?
Information from our investigation. Not a bug therefore.
For iOS devices, while Bluetooth is ON, the advertiser will continue to function to handle read/write/notify events with another recently connected iOS device, despite a call to peripheral.stopAdvertising()
until either device changes BLE address, or switches Bluetooth OFF. This is an undocumented behaviour of the iOS BLE API covering at least iOS 9.3 - 14.2. Herald manages this by absorbing the internal events (wakeTransmitter, readPayload) and suppresses callbacks to SensorArray
delegates, until these events cease due to BLE address change (circa 15 minutes). In short, on SensorArray.stop()
, Herald should not generate any callbacks to the SensorArray
delegates, but the log may show internal BLE activities for some time.
For investigation, additional logging was introduced to ConcreteBLETransmitter
. The log shows SensorArray.stop()
has correctly stopped the BLE central and peripheral. The test does also show calls to didReceiveWrite
and didReceiveRead
from the recently connected iOS device, however a scan using another device running nRF Connect
app confirms the advert has stopped, and no delegate calls were generated by these activities.
2021-04-24 11:45:21.047592+0100 Herald-for-iOS[232:5717] [SensorArray] stop
2021-04-24 11:45:21.052020+0100 Herald-for-iOS[232:5717] [ConcreteMobilitySensor] stop
2021-04-24 11:45:21.056756+0100 Herald-for-iOS[232:5717] [ConcreteMobilitySensor] stopUpdatingLocation
2021-04-24 11:45:21.060800+0100 Herald-for-iOS[232:5717] [ConcreteMobilitySensor] stopRangingBeacons(ios<13.0,beaconUUID=428132AF-4746-42D3-801E-4572D65BFD9B)
2021-04-24 11:45:21.062575+0100 Herald-for-iOS[232:5717] [BLE.ConcreteBLESensor] stop
2021-04-24 11:45:21.067654+0100 Herald-for-iOS[232:5717] [BLE.ConcreteBLETransmitter] stop, transmitter disabled
2021-04-24 11:45:21.071578+0100 Herald-for-iOS[232:5717] [BLE.ConcreteBLETransmitter] stopAdvertising()
2021-04-24 11:45:21.072365+0100 Herald-for-iOS[232:5717] [BLE.ConcreteBLETransmitter] stopAdvertising, notify timer cancelled
2021-04-24 11:45:21.075662+0100 Herald-for-iOS[232:5717] [BLE.ConcreteBLEReceiver] stop, receiver disabled
2021-04-24 11:45:21.080992+0100 Herald-for-iOS[232:5939] [BLE.ConcreteBLETransmitter] stopAdvertising, peripheral stopped advertising
2021-04-24 11:45:21.082608+0100 Herald-for-iOS[232:5717] [BLE.ConcreteBLEReceiver] disconnect (source=stop,peripheral=6CE293F9-3C5B-F0EA-E70B-57D5126DDB5F)
Describe the bug
After calling SensorArray stop, there is still ConcreteBLETransmitter and ConcreteBLEReceiver events. The underlying CBCentralManager and CBPeripheralManager are still calling the delegate methods hooked up to them.
Logs taken from device with SensorArray stopped:
A clear and concise description of what the bug is.
Smartphone and App information (REQUIRED):
To Reproduce
Steps to reproduce the behavior:
Expected behavior