I was reading a post recently by a friend, Mark, about the challenges of getting Wifi Direct working with multiple Android devices. As with most Android development, you are reasonably assured that your app will work on a wide variety of platforms as long as you work within the Android framework, but the moment you start working with hardware sensors, you get into wtf territory pretty quick (talk to anyone who has created a camera related app on Android).
The problem probably is that Google’s direction to OEMs probably mandates a few APIs that they must implement but leaves most of the details to them. And even this is just restricted to devices that Google actually can control. There are a lot of Android OEMs that don’t have any relationship with Google (Xiaomi, Amazon, etc).
To get these guys rowing in the same direction, you don’t need better documentation or rules, you need killer apps to be built on top of them. In the case of Cameras for example, I imagine it would be hard for an OEM to ship a product without making sure Facebook and Instagram work on the device.
Wifi-Direct’s problem is that there isn’t yet a killer app built on top of it. I think Android Beam uses it, but no-one really uses that feature (Beam itself was probably the wannabe killer app that would force NFC and Wifi-Direct adoption among Android OEMs).
It would be hard to imagine a startup or an independent developer building a killer app for it, basically betting their bank on a fractured technology ecosystem. If Google was serious about it, it would have to come from them. But Google’s direction now is to look increasingly at the cloud to solve these problems and so I imagine Wifi-Direct would be left to the side in favor of something powered by something like WebRTC.
This thinking also needs to be applied in the IoT market where there is are so many new standards for device to device communication (AllJoyn, Thread, Brillo, etc). However, without any real killer app in that world, it seems most of these are on the same road as Wifi-Direct.
The best standards emerge from successful products.
Code Zen 
Unfortunately, this problem is not confined to relatively less used hardware features like WiFi-Direct. A task as simple as using WiFi Manager APIs to connect to a specific network is riddled with inconsistencies. If you need to go further, like perform a WiFi Scan, then you are in even more trouble. On some devices, Access Points that were switched on recently do not show up in the WiFi Scan unless the Android device WiFi is “cycled” (i.e., switched off and on again). If you do that programmatically, you run into more inconsistencies.
I’m sure the situation is similar in the world of Bluetooth/BLE as well.
Having said that, this is not intended to be a rant. I think CTS covers the basic functionality else these devices would never have shipped. I suspect the behavioral differences arise because of the varying chipsets and drivers. Question is – how can Google rein in these differences? Should the CTS specify things in greater detail? Is there such a thing as over-specification?
I don’t know the answers to these questions. However, they better be addressed soon because these are critical for IoT applications.
LikeLike