How to get TCN from iOS device in background from Android

[gnuhel]

Hi,

we are trying to use TCN protocol to track iOS and Android devices. iOS could retrieve TCN when advertising data from Android. But when iOS advertise the data, Android could not see any TCN data. Are we doing something wrong? We are using the implementation of Android and iOS in the repo.

In the doc it says

Android (Listener)	<=> iOS	 (SENDER)
The Listener signals availability as a Bluetooth peripheral. The Sender, acting as a Bluetooth central, connects to this peripheral and writes its TCN to a field exposed by the peripheral then disconnects.

So Android opens a GATTServer and iOS can write TCN to it.

What happens if iOS is in the background? does it still try to write anything to the Android Gatt Server? I tried it but I didn't get anything? What would be the solution?

[ivnsch]

The last time we tested iOS -> Android, it was working. We will start a new testing round in a few days and update this issue.

[gnuhel]

Have you tried Android <->iOS (in background)?

[ivnsch]

Yeah, we tested in both directions about 1 month ago. You can try out with the CoEpi app, which uses these libraries: iOS, Android, beta branch and 0.2 tag respectively. We'll be releasing a new version in the next days so will be testing this again.

Can you specify which versions you used?

[ivnsch]

Confirming that with the CoEpi apps, I'm able to see the iOS app's TCN while the iOS app is in the background:

• Removed Android app
• Swiped iOS app up to background or locked device (tested both)
• Installed Android app
• Checked TCN observed by Android app (it's shown in the debug screen)
• Opened iOS app and checked its TCN (it's shown in the debug screen). It matched with TCN observed above.

Android version: Co-Epi/app-android@5b142d4
iOS version: Co-Epi/app-ios@7c5880e

As for the internals (AFAIR!), while Android can connect to an iOS device advertising in the background, there was a bug in Android's BLE after doing many connections, because of which it was decided that the iOS device acts as a central and connects to the Android's peripheral to write its TCN instead. When iOS scans in the background it uses passive mode, which means that it can't request the service UUID from the peripheral if it's not provided directly in the advertisement data. But Android does send it in the advertisement data, so it's not a problem.