Google goes IoT with Android Things
The Internet of Things is booming, but so are its security concerns. Can Google fix it all with its new Android Things? Darren Yates investigates.
For the first time, 2017 looks likely to be the year there are more Internet of Things (IoT) devices connected to the web than there are people on the planet, with market analyst firm Gartner forecasting IoT numbers to exceed 8 billion by the end of the year, up more than 30% on 2016. But that isn’t the half of it — by 2020, IoT numbers are expected to skyrocket to 20.4 billion ( tinyurl.com/hd8b9l8). With growing global concern over IoT security, these are numbers likely to make security experts wince.
Already, we’ve seen a number of major distributed denial of service (DDoS) attacks involving IoT devices, including the attack on domain-name server (DNS) supplier Dyn in October 2016, reportedly launched by IoT devices hacked with the Mirai botnet malware code ( tinyurl.com/jte7vsr).
With that as the landscape, Google has tweaked its Android operating system to launch a new IoT-specific OS called Android Things — could it be the answer to all that ails IoT?
PROJECT BRILLO
Android Things began in 2015 as Project Brillo ( tinyurl.com/gwpflaw), described at the Google I/O conference that year as a ‘polished down’ version of Android, stripped back to just the kernel (the core engine) and the minimum abstraction layers required to offer the key features Google named as ‘minimal system requirements’, ‘ broad silicon support’ and ‘ be easy to secure’.
While Brillo was built on Android, it wasn’t really Android. For starters, Google replaced the usual Java application framework, choosing instead C/C++, the language commonly used to code IoT devices powered by low-power processors called ‘microcontrollers’ (we code microcontroller projects using Processing, a simpler language derived from C++, in our monthly Arduino Masterclass).
Brillo also included the new Weave protocol, enabling Brillo-powered devices to talk not only to your Android phone or tablet, but to each other, using application programming interfaces (APIs) available to IoT app developers.
It was commonly reported at the time that Brillo would power devices with as little as 32MB of RAM; however, this was seemingly never confirmed or denied by Google. Nevertheless, the IoT-focused OS began reaching developers by invitation in October 2015. By January 2016’s Consumer Electronics Show (CES), it had gained some big-brand support from names such as LG, ASUS and Marvell ( tinyurl.com/j86h2nq).
ANDROID THINGS LAUNCHED
But a year is a long time in tech and, in December 2016, Google had rebadged Brillo, announcing the Android Things platform with a developer preview and recently releasing ‘Developer Preview 2’ ( tinyurl.com/hs76ufx). At time of writing, four hardware platforms were now supported — Intel’s dual-core 500MHz Atom-powered Edison, the quad 1.7GHz Atom-cored Intel Joule, NXP’s Pico i.MX6UL with its singlecore 500MHz ARM Cortex A7 SoC,
plus the famed Raspberry Pi 3 with 1GB of RAM and quad-core Cortex A53 SoC. More hardware platforms could receive support by final release.
Android Things shows a number of changes from Brillo, whether as the result of internal discussions or from developer feedback. Whatever the case, gone is C/C++ as the primary coding language and back comes Java. While this might offend some IoT purists, Java — as the default language of Android — is arguably a better fit for an Android-based platform. The other notable difference, from the initial rumours at least, is the apparent minimum hardware level required, with NXP’s Pico i.MX6UL having the smallest RAM cache at 512MB — a long way from those ‘32MB’ rumours. However, the broad switch from C/C++ to Java will allow Android developers to write familiar code using the existing JetBrains-powered Android Studio development environment. If you’re interested in the ‘developer preview’, there isn’t much at time of writing that’s specifically ‘Android Things’ in terms of coding. Apart from requiring Android Studio 2.2 or later, you need to install a minimum of Android Nougat/7.0 SDK (software development kit) and Android SDK Tools version 24 ( tinyurl.com/jh6wh5n). After that, you create a new project that targets at least Nougat/7.0 and add the Android Things library in the app-level build.gradle file, using the code:
provided ‘com.google.android. things:androidthings:0.1devpreview’
...within the dependencies group. You then add the shared library to your app’s manifest using:
<uses-library android:name=”com.google. android.things”/>
But the real key is the Android Things OS you install onto your IoT development board. This was available at time of writing as ‘system image’ previews from Google’s Developer website ( tinyurl.com/h54xcyg) at approximately 250MB each. Ensure you download the file that corresponds to your development board. The process of installation is different for each of the currently supported boards, but generally follows traditional methods, for example, Win32DiskImager to write Raspberry Pi 3 images to microSD card and Android SDK Platform Tools (that we’ve recently covered in-depth) for the Intel Edison. Bottom-line, make sure you follow the appropriate install instructions for your particular board ( tinyurl.com/zsdxfsh). ADDITIONS AND TAKEAWAYS Even supporting devices with 512MB of RAM on-board, Android Things is notable for what it includes — as well as what it leaves out.
Arguably the most important addition is the Peripheral I/O API. It provides the code-hooks to connect the development kit board to external devices using standard protocols. According to Google, protocols supported include GPIO (general-purpose input/output), PWM (pulse-width modulation), I2C (inter-integrated circuit), SPI (serial peripheral interface) and UART (universal asynchronous receiver/transmitter). This enables Android Things boards to hook up to a range of display devices and sensors, such as ultrasonic, temperature/ humidity, magnetometers and OLED/LCD panels.
Then there’s TensorFlow ( tensorflow.org), Google’s machinelearning library that allows you
to build in analytics and in-depth mathematical operations into your IoT project.
But as Google giveth, so it also taketh away — a decent swag of contentprovider APIs have disappeared, including DownloadManager, Settings, Telephony and MediaStore.
Android Things still supports graphical user interfaces (GUIs) and the standard UI Toolkit remains, but not the system status bar or navigation buttons. The good news is displays are optional, in support of ‘headless’ IoT designs ( tinyurl.com/hqmqrls).
More broadly, Google has also axed some Google services in Android Things. Services surviving include screencasting and using Android devices as remote controls (Cast), Google Drive (Drive), as well as fitness (Fit), Location, Nearby and Places. Services that didn’t make the cut include AndroidPay, AdMob, Maps, Play Games, Search and Sign-In. You can read the list on the Google Developers page ( tinyurl.com/hqmqrls).
DEVELOPING HARDWARE
What will likely be different for many Android developers is making hardware (something we’ve been doing for a few years now in our Arduino Masterclass series).
Google even offers a ‘Hardware 101’ guide to get users started ( tinyurl.com/ ztfurs4); however, in our view, it doesn’t go near far enough and its concept of ‘resistor strength’ isn’t one you’ll find in too many electronics textbooks.
While the current Android Things development hardware support is definitely a step up in performance from Arduino, the electronics principles involved in connecting the outside analog world to a CPUcontrolled board remain the same. Breadboards, interconnecting wires, components all mean you’ll need at least a moderate level of electrical engineering knowledge before trying to develop reliable IoT systems.
While C/C++ has given way to Java as the primary coding language, it hasn’t gone entirely. Thanks to the newly added support for Android Native Development Kit (NDK), developers will be able to use their own C/C++ code to communicate with external devices via I/O ports available on Android Thing-ready boards. Called ‘Native PIO’ ( tinyurl.com/hjzohf9), your C/C++ code can handle GPIO, PWM, I2C, SPI or UART devices and data transfer.
HARDWARE MISSING
But if you’re coming from an Arduino background, the one thing you’ll likely miss is ‘analog inputs’. On most Arduino boards, these inputs allow you to provide direct and continuous (analog) voltages to the microcontroller through a built-in ‘analog to digital converter’ (ADC). For example, say you want to make a simple light sensor — on an Arduino, you could use an LDR (light-dependent resistor) connected between an analog input and ground, with that input set to use its internal pull-up resistor to create a voltage divider whose output varies with light intensity. You then read the analog input for its digital value, thanks to the internal ADC.
None of the four boards so far supported by Android Things has an on-board ADC — that means you must supply your sensor data either in digital form or use your own ADC, which can be problematic. Online electronics retailer SparkFun has a ‘ block’ expansion board for the Edison that adds a 12-bit ADC for US$10 ( tinyurl.com/hqmb449).
OTA UPDATES
One of the features Google is keen on with Android Things is the ability to push updates over the air (OTA) to an IoT device, not just Google’s but your own app updates as well.
However, some online already seem a bit wary, asking how long will these Google OTA updates continue. We think it’s a fair-enough question, as the Android ecosystem has a trail of orphaned devices stuck on older versions of Android ( tinyurl.com/ m7zm5cu).
How long should Google support these current development kits? We’d argue it needs to be more than the two years or so smartphones and tablets seem to currently get. Replacing an orphaned smartphone is one thing, but ditching an IoT-connected appliance or smart-home feature because someone decides ‘your hardware is out of date’ isn’t likely to go down well. Moreover, industrial IoT device users will rightly expect long-term support as well.
Google’s recent moves to provide direct OTA support, rather than relying on telcos for OS updates, paves the way for a decent solution. An IoT platform that can remotely update its core OS features, including security, without relying on the IoT app developer to do the leg work has decent potential.
AND BLACKOUTS
Overall, Android Things tries to address a number of issues that everyone laments regarding IoT, from lack of data standards to security fears. Still, it may well be early days for the OS, but I have concerns for Android Things and the broader IoT market.
One notable barrier to Android Things at the moment is the hardware requirements — the apparent need for at least 512MB of RAM essentially makes this a computer-grade operating system requiring a computer-grade CPU. By that, read ‘ARM Cortex A-series’ SoCs (system-on-a-chip) that power just about every smartphone and tablet.
The problem with that is that many IoT applications just don’t need that amount of CPU horsepower — in many cases, it’d be a bit like taking your Rolls Royce Phantom down to the local takeaway to grab your Friday-night fish and chips.
At time of writing, the ‘microcontroller’ class of processors, including from 8-bit Arduino-grade devices up to 300MHz low-power high-performance 32-bit Cortex M-series cores, appear to be ignored by Android Things. We hope this soon changes.
Another issue is power consumption. The current hardware development kits supported, such as the Raspberry Pi 3, are indeed popular, but they can also chew through considerably more power than the vast majority of microcontrollers. For example, according to the Raspberry Pi Foundation, the Raspberry Pi 3 requires around 400mA of current minimum to operate ( tinyurl.com/ lno7myc). By contrast, ST Microelectronics’ 32-bit STM32F405 microcontrollers running at 168MHz can operate on one-tenth of that current ( tinyurl.com/jlgul75, PDF, page 8). Now microcontrollers generally require C/C++ coding and don’t have the RAM to hold an OS, but then, not every IoT device needs an OS.
For now, it seems the fundamental issue is that higher-performance boards are needed to give IoT security some muscle; however, that muscle will often result in an IoT device that otherwise performs the equivalent of cracking a walnut with a sledgehammer.
More broadly, this approach to IoT design is a growing issue we reckon the tech industry will have to address.
There’s an old saying that, when all you have is a hammer, everything looks like a nail. I like the Raspberry Pi as much as the next geek, but if the major tech players want to encourage smart IoT development, maybe we need to get past building connected doorbells using a Raspberry Pi simply because that’s the hardware everyone is familiar with.
Here’s one reason why — power generation is a hot topic in Australia right now, given issues in South Australia and calls to reduce power consumption during this past summer’s heatwaves in NSW, Victoria and Queensland. A recent 2016 report by the International Energy Agency (IEA) stated that, while IoT could be an ‘enabler of applications’ that lead to reduced power demands, it concluded that ‘the expected future contribution of mains-connected IoT devices to the worldwide annual energy consumption is significant’ ( tinyurl.com/jgft8ww, PDF, page 7). By all means, encourage IoT development — but we need equal focus on power-efficient design and that has to include microcontrollers.
Android Things clearly aims to provide a general-purpose platform for anyone with Java coding skills to create connected and secure IoT devices. But for now at least, we’re not convinced it’s the most power-efficient platform for every IoT project.