davidgyoung / backgroundadvertiser Goto Github PK

Hi David, thanks for this app and the accompanying article (http://www.davidgyoungtech.com/2020/05/07/hacking-the-overflow-area) - it's really cool that you figured all of this out. I have a few follow-up questions:

1. When I try using the app, I see the following error:

[CoreBluetooth] API MISUSE: can only accept this command while in the powered on state

I made sure that the app has proper bluetooth and locations permissions as explained in the readme, and that bluetooth is on, airplane mode is off, etc. Do you have any thoughts on why the app would say this is powered off?

2. I tried making my own background bluetooth communication app from scratch, with one phone set as the advertiser and one as the receiver. (I'm able to get past the issue of bluetooth being off like was happening using your app for some reason). What I'm seeing is that when at least one phone is running the app in the foreground, the advertisement gets sent/received properly. But when both are in the background, the advertisement is not detected. So it doesn't seem like either phone is having problems transmitting or receiving advertisements in the background (since both work correctly when the other is in the foreground). Have you seen this problem before? One idea I have is that because the rate with which bluetooth advertisements are sent/scanned for decreases when the app is in the background, when both are in the background, they are sending and scanning for advertisements at different times, and thee times are not aligning for there to be a connection. Does that sound reasonable?

3. Regarding the "How iOS Handles Collisions" section in your article. You mention that

iOS will give a scanning callback for the colliding but different service UUID

How do I as a programmer access this callback/define the behavior for when there's a collision? What I am seeing is that if I broadcast an advertisement in the background with a few service UUIDs, where some are from your Overflow Service UUIDs by Bit Position table and some are chosen arbitrarily (not from that table), the list of service UUIDs in the advertisement received includes all of the ones from your table, but the arbitrarily chosen UUIDs are converted into different UUIDs. So it seems like the ones not from your table are being changed to other UUIDs which correspond to the same bit positions. But how do I know that it's a different UUID than what was originally advertised (since there was a "collision")? Though it would make sense to me if it's impossible to make the distinction- it's not like there's some data in the advertisement indicating that there was a collision right? So if you could just explain the "How iOS Handles Collisions" section of the article a bit more I'd really appreciate it.