AccessorySetupKit and BLE RRA

Question

Created Jul ’24

Replies 4

Boosts 0

Participants 2

Currently (as of iOS 18 dev beta 4), if a BLE device supports RRA and the MAC address changes while the ASAccessorySession's picker is displayed a second entry is added to the picker (usually without a friendly name). Once in this state one picker item will work, the other will display a "Cannot Add Accessory" error. Are there any plans to improve this user experience in AccessorySetupKit or do you have any recommendations on how to better handle this use case?

We currently have a work around for this in our existing pairing flow but it does not translate to ASDiscoveryDescriptor as it requires comparing previous BLE advertisements.

Boost

Answer 1

Engineer OP

Apple

Jul ’24

Hello.

Can you share the reason why an accessory might rotate its address while waiting for set up ? The bluetooth spec privacy methods, like the RRA, make it impossible to differentiate a legit address rotation of the same device, vs a second device advertising with similar payload.

Thanks.

0

Answer 2

jestinson OP

Jul ’24

Hi!

Our accessories currently use their public address only when they are in pairing mode (otherwise they rotate the address periodically). They ship in pairing mode so first time setup usually isn't an issue. The bigger issue is in trying to re-pair a previously paired accessory (that's not in pairing mode) or trying to pair to a second device. To do this the user must put the accessory back into pairing mode. If they do this while the picker is displayed duplicate entries result.

We currently solve for this use case in our custom pairing flow by having specific fields in the advertising data that are guaranteed to not change upon entry into pairing mode. This allows our app to detect the address change and ensure we connect using the proper address.

0

Answer 3

Engineer OP

Apple

Jul ’24

You can do the same thing with AccessorySetupKit. The AccessoryDescriptor allows you to specify either or both : bluetoothManufacturerDataMask bluetoothServiceUUID

In addition each one of these allows you to specify the exact payload you're looking for using blob/mask. bluetoothServiceDataBlob bluetoothServiceDataMask bluetoothManufacturerDataBlob bluetoothManufacturerDataMask

The mask will tell us what bits to look at (0 means we dont care, 1 means we look at that bit), and the blob is the data you're looking for (each bit set to 0 or 1)

If you use the right combination, the AccessorySetupKit UI will only show you devices that are in that specific mode.

Let me know if this helps you resolve the problem.

0

Answer 4

jestinson OP

Jul ’24

The problem I have is that the values in the manufacturer data are not already known to the app so i cannot create a descriptor to describe them. They are actually part of an application-level IRK that normally changes at the same time as the MAC. The entry into pairing mode is a special case where they remain unchanged even though the MAC changes.

We do have a bit in the manufacturer data for pairing mode so I can filter out devices not in pairing mode but we prefer to discover those devices then give users specific instructions on how to get their device into pairing mode as instructions can vary by model.

0