ProximityChat

Some time ago I opened a wifi hotspot on my Phone putting some joke question in its SSID while sitting in a crowded lecture hall (as many other bored students do) and not thinking further of it. Shortly afterwards a friend sitting next to me looked at the open wifi networks and saw that someone answered my question by putting the answer in the SSID of their hotspot. Following this I continued talking to this random person somewhere within that lecture hall purely via the SSIDs of the hotspots of our phones.

I found the (mis)use of the SSIDs, which are usually for identification of networks, for communication quite intruiging. Especially since wifi beacons as message carriers can be compared to soundwaves carrying speech as both require conversation participants to be near in order to “hear” each other and everyone around you may listen and participate in the conversation. This may sound far fetched, but it could be seen as a digital equivalent to normal face-to-face conversation.

This gave me the idea to try and build an actual application that facilitated the Hotspot SSIDs to send messages to people in close proximity to you (hence the Project title).

This isn’t going to be a step-by-step on how to build such an app, but rather I’ll highlight the things that gave me problems and explain how I solved them. If you wanna understand the app in-depth, the source code is available here.

Properties of Wifi Hotspots and SSIDs (on Android)

Our goal is to build a simple prototype app that has nothing but a chatlog and a textinput. First of all we have to look into if it’s even possible to control the creation of a wifi hotspot via an app.
A quick google search gives the answer:
On Android - Yes
On IOS - No

Great, I personally have no way to develop on IOS anyway, so this works for me. The next consideration is, how many characters can fit in an SSID/Message? Another quick search yielded: 32 Characters.

A bit limited but I already know it works for basic conversation.

Now we know that it’s possible and what we’re dealing with. So taking to Android Studio I whipped up a simple UI.

Ignore the numberinput with the “50” for now, we’ll get to that in a bit. Otherwise we have a large chatlog at the top and a simple textinput at the bottom.

Functionality

Now we need a way to get a list of the available wifi networks into our app since that is how we recieve messages. The technicalities of that are fairly basic if you ever touched Android App dev (or even if you didn’t) and described in [1]. Essentially you create a WifiManager object through which you can start scans and a Broadcastreciever through which you’ll be notified of the results. The only huge quirk here is that, for whatever reason, your app needs the

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

permissions AND location services/GPS enabled to retrieve the scanresults.

If GPS is disabled, you’ll only recieve an empty list as a result.[2] The specifics of why that’s necessary are beyond me, but I’m also no expert at Android internals, so I’d be happy if someone could elaborate on that.

Allright, now we can recieve messages. A consideration to be made, that I have largely ignored for the prototype, is that you’ll re-recieve the same message multiple times with every scan for as long as the other person is broadcasting it. So for an actual implementation you’d have to filter out duplicates.

Next we need a way to send messages. As already described we do this by creating a hotspot with our message as the SSID. Sadly there is no official/documented API in Android that will let us control the hotspot. BUT a method to do that still exists within the WifiManager class, we just need to “extract” it. [3]

private Method enableWifiAP;

try{
  enableWifiAP = wifiManager.getClass().getMethod(
						"setWifiApEnabled",
						WifiConfiguration.class,
    					boolean.class
				 );
} catch (NoSuchMethodException e){
  e.printStackTrace();
}

We can now invoke this Method with a WifiManager, a WifiConfiguration object that contains information like the SSID, wether the wifi should be on or off, etc. and a boolean describing wether we want the Hotspot enabled or not.

//Disable AP
enableWifiAP.invoke(wifiManager, wifiConfig, false);
//Enable AP 
enableWifiAP.invoke(wifiManager, wifiConfig, true);

Great, now we can programmatically control the HotSpot. Note as this is an undocumented method and it may well get deprecated and removed at some point (or already has been). Now we just need to hook that up to the ‘Send’ button and boom, we can send messages. Except there’s still one bit left: We can’t recieve messages while we’re broadcasting and we can’t broadcast while recieving. That’s where the number input comes into play.

The most obvious solution is to only broadcast for a set number of seconds and then go back to recieving. Definetely not perfect but it will work. So we simply have a number input that lets us set the amount of seconds we want to broadcast that specific message. Here a plethora of issues come up like: The system fails if both parties send for roughly the same duration at the same time as neither of the two will recieve the sent messages. These pose a challenge and are probably solvable but beyond the scope of a proof of concept.

Proof of concept

This is a screenshot of the first testrun in that very same lecturehall the idea first came up in. (The messages are in german)

And it’s a Success!

Though, again, many issues are apparent. You can see what I meant by “There’ll be duplicates” as the same message from my friend pops up multiple times. Also, not visible here, but an issue is that legitimate wifi access points will always show up with every scan without any filtering applied.

Conclusion

This was the first time I ever went and really built a PoC for an idea i had so I was pretty proud to see it work out, albeit with issues not with any full roadblocks. It wasn’t a smooth process, nor is this a clean implementation as it uses some hacks to get by and the Permission system of Android really doesn’t play nicely with this idea and gave me quite a headache. Still I really like the implications of this being a creative way to use existing technology for a completely different purpose. I’ve tried to iterate on this project already using bluetooth instead of wifi but thats gonna be another blogpost eventually.

The full source of the prototype is available here.

Feel free to iterate on it, use it to learn the techniques for some other project or whatever. I’d be happy to hear from you if you do!

Also this was my first ever blogpost so if you made it this far, thank you! Even if you won’t look at the code, I’d still be glad to get constructive feedback of any kind!

[1] https://stackoverflow.com/questions/18741034/how-to-get-available-wifi-networks-and-display-them-in-a-list-in-android
[2] https://stackoverflow.com/questions/32151603/scan-results-available-action-return-empty-list-in-android-6-0/32151901#32151901
[3] https://stackoverflow.com/questions/6394599/android-turn-on-off-wifi-hotspot-programmatically