Contact Tracing - Part 1

Contact Tracing - Part 1


0 min read


With the advent of the Coronavirus disease, there has been numerous proposals to reduce its spread. Proper hygiene, social distancing/self-quarantine etc have been words we've heard to help 'flatten the curve' - slow down the rate of infection. 3 weeks ago, I set forth to create a service that helps trace contacts you've come across. This is a voluntary opt-in service that traces a contact using an anonymous token broadcasted by your Android and iPhone mobile device. In this few part series, I'll take you through the development of the service, challenges faced and framework features that facilitated this solution.

Why Mobile?

Mobile phones have greatly enhanced our lives. We carry them everywhere ('mobile' ๐Ÿคท๐Ÿพโ€โ™‚๏ธ), have astounding features such as GPS, Camera, Bluetooth, Connectivity capabilities and so on. With these features coupled with their ubiquitous nature, mobile phones form an ideal device to implement contact tracing. Plus I am a Software Engineer - I use the tools at my disposal ๐Ÿ˜Ž.



From the stats I could find on mobile phone market share in Kenya (Jumia Mobile Report 2019, Stat Counter - chart below), Android OS is King ๐Ÿคด๐Ÿพ: with estimates at are around 92%.



iPhone has about 6% share. This could be higher as you see these devices everywhere nowadays. Nonetheless, being popular brands, the combined market share of Android and iPhone make them ideal targets for development platforms plus they both have mature stable frameworks.


Trial 1 - Google Nearby

logo_nearby_color_48dp.png I was looking for a technology that I could use to detect mobile devices nearby (thus contacts) and remembered watching an IO session on Google Nearby sometime back. Nearby uses Bluetooth, Wi-Fi, and audio to communicate with devices within their vicinity. It comes in 3 flavors in which one of them, Nearby Messages, works on both Android and iOS (using internet) making this a great choice. The folks at Google have done all the heavy lifting on the library layer for both platforms and the documentation is sufficient to hit the ground running.

This is a publish-subscribe API and here's the dance:


Looks involved but it's really not. Let's step through:

  1. The publishing phone requests the server to associate a message with a token.
  2. The publishing phone broadcasts this token to nearby devices using a combination of Wi-Fi, Bluetooth, Ultrasonic, Bluetooth Smart (BLE) technologies.
  3. A subscribing phone detects this token
  4. The subscribing phone reports this token over to the server
  5. The server facilitates the exchange of message associated with token between the two devices.

Both phones could be acting in both roles, publisher and subscriber, at the same time facilitating dual pub-sub communication.

It's important to note that Nearby Messages is unauthenticated though requires the developer to register the API keys used in the same project in the Google Developers Console. You can read more from the official documentation here.


Surprisingly enough, Nearby Messages supports both background subscriptions and publications using BLE (Bluetooth Low Energy) on iPhone only. On Android, this technology seems geared towards Beacon messages subscriptions and thus does not support background advertising. They enforce this restriction based on the context you provide when creating the MessagesClient which only supports an Activity and FragmentActivity.

Another limitation I came across was that creating a Strategy using the builder on nearby version 17.0.0 doesn't allow you to set a different 'DiscoveryMedium'. Supported mediums are Ultrasound, BLE and a combination of these two (the default). The builder will always set the medium to BLE and actually ignores the parameter you're trying to set. Checking the obfuscated source clearly show this.


In addition, the library even has the medium setter method name mangled. Perhaps this shouldn't be public api but then it's exposed to be ๐Ÿคท๐Ÿพโ€โ™‚๏ธ.


For Contact Tracing, the user would therefore be required to have the application in the foreground (Activity Context) in order to advertise their anonymous token and this didn't meet my requirements to have background subscriptions and publications. (FYI even foreground Service context didn't work).


Google Nearby technology is amazing and integration was straight froward enough save for the limitations mentioned above. I therefore had to look for a different solution perhaps a subset of this? Let's explore that in the next article.

Stay safe, social distance, flatten the curve. Happy coding!