Google’s Android Things development Iokit turned v1.0 on Monday. I celebrated the birthday of the new tool that hopes to address IoT problems in development by belatedly attending a “What’s New in Android Things” talk at Google I/O (Google’s annual developer conference).
In the name “Android Things”, the word “Things” refers to devices that communicate with one another, with or without human intervention. For example, your smart thermostat is one component in your home’s Internet of Things. The thermostat optimizes your home’s energy usage and adjusts its setting when you say, “OK Google, raise the temperature by one degree.”
From where we’re sitting in the year 2018, IoT is like the proverbial Wild West, which can create IoT problems when it comes to development and integration. People build prototype IoT devices by soldering parts from many sources, with help from many incompatible standards using several different communications protocols. There’s simply no agreement on the best tools to use and the best way to use these tools.
Solving IoT problems
The fundamental IoT problem is that devices must be very small. They can’t be the big, clunky computers that you see on peoples’ desktops and in peoples’ laps. They have to blend into the background and be part of whatever hardware they’re driving. They must respond in real-time to somewhat unpredictable conditions so the traditional chips and motherboards that you find in desktops and laptops don’t cut the muster.
Unlike today’s desktops and laptops, the new low-power, small profile devices that control IoT devices haven’t been around long enough, which creates an IoT problem in terms of standardization. What’s more, solving the IoT problem with standards is harder than the problem for conventional computers. A small computing system that works well in a home thermostat might be totally unsuitable for a wearable strap that measures a swimmer’s strokes.
So, getting started means learning about dozens (maybe even hundreds) of different IoT hardware platforms. Arduino and Raspberry Pi seem to dominate the field, but there so many alternatives, each with its own specs and features, that the choice of hardware for a particular project can be mind-bending. Each hardware platform comes with its own capabilities, its own way of being controlled (perhaps with C, Python, or a home-grown assembly language) and its own operating system (if it even has an operating system). How does an IoT innovator deal with all these choices?
One possible answer to the IoT problem is Android Things. To create Android Things, Google took the existing Android SDK (the one that powers 80% of the world’s smartphones) and modified it to deal with IoT problems. Think about a device that monitors traffic on a busy street and sends the data to a server in the cloud. That device has no keyboard, no screen, and no need for a user interface. So, the Android Things toolkit provides no packages for communicating with an ordinary user. Instead, the toolkit’s packages allow engineers to communicate through general purpose input/output (GPIO) pins. Setting up the communication means typing code such as this:
var button = PeripheralManager.getInstance().openGpio(pinName);
There are many advantages of creating an IoT version of Android from the venerable mobile-phone version of Android. For one thing, developers can leverage their existing Android coding skills as a starting point for creating IoT applications. Also, from its years as a smartphone operating system, Android comes with a full stack of services that can be used to create new IoT applications.
Google has partnered with several companies such as Qualcomm, MediaTek, NXP, and Raspberry Pi, to make Android Things available for their products. They’ve created lists of pre-certified hardware that run the Android Things SDK. This pre-certified hardware spans the range from devices that are used mainly for prototyping and development, to devices that are practical in real world settings. So, with Android Things, the transition from development and testing to actual production doesn’t require a change in the software platform.
Security: Another IoT problem
Security is an important concern in IoT. That’s why security is baked into several stages of Android Things. This includes a sandbox for apps, the existing Android permissions scheme, the signing of system images, a verification step whenever a device reboots, and keys to identify particular hardware. It’s tempting to say that, with the Android Things security features, an app developer is relieved from the usual concerns about security. Of course, this view is too simplistic. In this day and age, everyone has to think about security, even if that thinking is on the high level that’s provided by the Android Things SDK.
Each release of Android Things will be supported for at least three years, and Android Things devices will receive consistent, automatic updates. What’s more, Android Things is free to use. According to the speakers at Google I/O 2018, no fees are required in order to use Android Things. (Please check your legal team to verify all the details. I’m not a lawyer and I’ve never played a lawyer on TV. My claims are Android Things licensing are based only on what I’ve heard, not on anything that I know for sure.)
In the olden days, each farm object was hand crafted with its own size and shape. Then, as the 20th century rolled around, the world discovered standardized parts. At the dawn of the consumer computer age (the early 1980s) we had several different vendors proposing their own standards for disk storage and operating systems. The field eventually settled into only a few players such as UNIX, Linux and Windows.
Today, as we approach the 2020s, we have hundreds of standards for IoT hardware and software platforms. The typical innovator must choose among the many alternatives to create a system that has internal consistency and, if the stars are all aligned, can also talk to devices that are external to the system. Perhaps Android Things is a way to create order from this chaos. Let’s ask our robot arms to keep their mechanical fingers crossed.