Wi-Fi has become a rather ubiquitous standard for wireless Internet communication, but it can often be more power-hungry and more complicated to implement than other wireless standards for nearby device communication. For example, using Google Cast may require your phone to message a router which then in turn messages your Android TV. There can be a fair amount of rerouting in the signal, more than is necessary. With Wi-Fi Aware, a feature being added to Android O, you should be able to create a peer-to-peer connection without a Wi-Fi access point.

There have been a number of news outlets covering these Android O features, but I wanted to do so from a developer point of view. It can provide a unique perspective on how these APIs will work and how they will affect application development.

It’s clear that Wi-Fi Aware is their version of Bluetooth Low-Energy, a low-powered way for nearby devices to communicate through a series of services that publish and subscribe to particular messages. The video shows the equivalent of Bluetooth beacons for transmitting information. It’s targeted as a way to quickly allow phones to become nodes that connect to other nodes just using the Wi-Fi antenna, without the need to be on the same network. However,  Wi-Fi Aware has greater throughput and range than BLE. As there are trade-offs between power and range, this will probably be more power-intensive than BLE. That’s not to say it won’t be used, but we’ll likely still see BLE used in smaller devices like smartwatches.

One example given is the ability to send photos to nearby friends, or play a game with someone nearby. This could also become a common way to cast content, without relying on being on the same network. Your phone can just discover the device and communicate directly without the middleman. While it may not support casting large videos, it could make the discovery process much more convenient.

After making the initial discovery and connection, data is transmitted through one device publishing to a service and the other device subscribing to the service. Data is transferred bidirectional. A subscriber can send a message back to the publisher after it receives something. The API is very similar to  in that there’s a simple pub-sub model. This makes it easy to transfer small sets of binary data, like a chess move, but difficult to transfer video.

Technically, video data can be ripped into chunks and each chunk can be sent. On the other end the chunks can be buffered and reassembled. Then, the receiver sends an “OK” back to the sender to request more data. That’s basically how any video is streamed. If Google incorporated this into Cast, which they probably will for the discovery benefits, they’ll handle all of that in their library. I’m not sure what the latency will be, if data can be streamed fast enough. This post from StackExchange shows BLE isn’t suitable for streaming good quality video, so it’s probably not suitable.

Is this feature enabled now? Well in order to take advantage of this feature, a device needs specific hardware.

context.getPackageManager.hasSystemFeature(PackageManager.FEATURE_WIFI_AWARE);

Future devices, those launching with O, will likely have this feature. At the moment, there’s not much that a developer can do. I think it will take several years for this to be a meaningful feature, due to the need for hardware to get out to more people. I’m sure the developers of the feature are aware of this, and want to future-proof Android. Still, for those who have the latest hardware, I can see some really neat tech demos being built with this.