Our Xamarin app receives 2 advertisement records of manufacturer specific data type. On Android we receive 2 separate records and prior to iOS 16.4, we received both records combined as one record appended on the other. As of iOS 16.4, we no longer receive the second record, as a second record or appended to the first. This is needed for our app to function and we cannot find any documentation about this change. There is a security patch note for Bluetooth Core. We have verified it is not specific to our app because the same thing occurs in the nRF Connect for Mobile app and it works as previously stated on iOS 16.3
Bluetooth Advertisement Records iOS 16.4
Hello,
My name is Peter Maxwell Warasila, the engineer responsible for the firmware side of these advertising packets. I wanted to expand on what the peripheral side of this looks like now, in some tests I've conducted, and what records I've been able to reproduce both in our application and using the nRF Connect for iOS application.
First, as our application exists today, we send an MSD field in a periodic legacy advertising packet with a first byte multiplexer (in the payload of the MSD data, after the company ID) of 0x1e. This periodic advertising packet also contains the advertising flags field. The scan response data contains a different, separate MSD field, with a first byte multiplexer of 0x1f. What we are seeing in iOS is only the MSD field data from the field in the periodic advertising packet with the multiplexer of 0x1e.
I also tested moving the second MSD field with 0x1f multiplexer into the same periodic legacy advertising packet. This periodic packet now contains the advertising flags, our 0x1e MSD field, and finally the 0x1f MSD field in that order. What is now visible both in the records returned to our application and within the MSD fields of the nRF Connect for iOS application is only the MSD field with the 0x1f multiplexer.
This does not seem like the ideal behavior for manufacturer specific data fields. The Android API happily returns as many records as we send, and as far as I can tell the Bluetooth Core Specification does not put any restrictions on number of manufacturer specific data fields that can be placed in a single AdvData structure. Since it is permissible for devices to send multiple MSD fields in their periodic and scan response data I would expect that Core Bluetooth would also support this possibility, up to a point at least. With the way that extended advertising essentially allows for arbitrarily large advertising data I could see a cap being imposed somewhere. For the 31 byte legacy advertisements, though, it shouldn't be an issue.
This is a major issue for the company I work for as well. We’re hoping to receive confirmation Apple has discovered the issue and are working on a fix as soon as possible.
Same here... Since 16.3, it is not possible to pair our app to our flight instrument device. This is currently creating many support tickets from our customers.