[Little Brosers] Messages

This week I’ve worked extensively on the generation and parsing of messages in the mobile app. While I was planning on getting started with BLE on the devkit, I had to take care of this PSSC first.

Message Structure

The idea is to define a structure for the messages that will be handled in the app, as well as the interface with the raw messages that will be exchanged over BLE. In order to do that I implemented this kind of structure:

Raw message represents a message as a sequence of bytes that are exchanged over BLE. GenericMessage is the Java representation of any message object that has a header, payload and signature. It takes care of going to and from a raw message. After a message is parsed and transformed into a GenericMessage, its type is checked and then an object with the corresponding message type is created and handled by the app. For the moment we only have one type of messages, which is EncryptedTextMessage.

We put time and effort into this one in order to make it as simple as possible to add other message types in the future without having to rewrite the app’s code. A more detailed description is available in our wiki Java message structure.


Another big aspect of generating messages is taking care of the cryptographic aspects, which are signature and encryption. I’m working closely with one of my teammates who’s handling the back-end side of our system (server and certificate authority) in order to be able to generate properly encrypted and signed messages as soon as possible.

Little Brosers ID

We also chose our 4-byte Little Brosers ID that will help us identify BLE advertising messages that come from our Drops. I won’t reveal what it is but I’ll only say that it has something to do with initials 😉


For Next Week

I plan on having working messages before the end of the week. I’m also hoping to start working on the devkit to implement our protocol over BLE (as described in a previous post).

[Little Brosers] The Delights of Working with Android

Hello everyone,

Last week I resumed working fully on the Android app, the app on which I’ve been working On/Off for about 3 weeks. My major sticking point was moving the scanning to a foreground service, which is a service that the user is aware of, and that keeps running after the app is swiped from the recent apps list (that is as long as the system has enough memory for its other tasks). The problem was that on my device, the Huawei P9, the service was getting killed the moment I swiped the app from the recent apps list. I tried everything I possibly could, until a teammate of mine tried the app on his phone, and it worked like a charm. What a delight it is to work with Android, where every device acts in its own special way. After a long search I was able to find the setting that made my app work on my Huawei.


So right now the app scans for BLE devices in a separate service, in a separate process, and when it finds one it sends a notification with the BLE device’s address as a proof of concept at the moment.


BLE scan screenshot


With that out of the way, we can now focus on refining the scanning, while implementing our filters to wake up the app only when a Little Brosers drop is detected. The global protocol is explained in one of my previous posts.
For now, with the help of the dev kits, we will bring the app closer to reality and make it establish a conversation with (what will act as) a real drop.

[Little Brosers] The User’s Side of The Story

Hello everyone,

This is my first personal post in the logbook, since we finally started working on separate issues in the project. So let me tell you a little bit about what I’ve been working on in the last few days:

Little Brosers App

I have been working on the user’s side of the Little Brosers project, the mobile app. Since I have previous experience in developing Android apps, it was a logical choice for me to explore this aspect of the project and lay the foundations of our future work. I started by looking at the Bluetooth Low Energy capabilities and APIs for android that will allow us to detect and interact with the drops from the smartphone. After looking at the official API and other third-party libraries, I came upon a library developed by Nordic Semiconductor, as well as a PDF document, also written by them, about BLE on Android. Nordic’s library being reliable and simple to use was the final winner.

Using this library I was able to write a very simple android app that was capable of detecting and logging the address of any BLE beacon in range in the foreground (I used an app to turn my iPad into a BLE beacon).

I believe that this is an important first step. Having found a reliable library, the next steps would be the following:

-Implement UUID filters in the scan to detect only the Little Brosers drops.
-Clean the app code to separate as much as possible UI elements from functionality ones.
-Move the detection to the background using Android services.

Note that the last point is tougher than it looks. There are many decisions still to be made regarding the behavior of the app that will affect how we handle this part.

Aside from the mobile app, I will also be working on refining the message structure and the Merkle tree with my teammates, so that we can start developing the core of our project.


Until next week,