In December 2016 Google released the first developer preview of Android Things and Android-based operating system designed for IoT devices, formerly known as Brillo. In this series we’ll take a look at some of the basics of Android Things and create a simple weather station.
Rather than try and create our weather station from scratch, I am going to use a Raspberry Pi 3 with a Pimoroni Rainbow HAT to keep the hardware aspect to a minimum so that we can focus on the software side of things and explore how Android Things differs from regular Android.
I am sure that most readers will be familiar with the Raspberry Pi and the Pi 3 is one of the hardware platforms supported by the developer preview of Android Things. The Raspberry Pi 2 introduced an add-on board standard named Hardware Attached on Top (or HAT, for short) and the Rainbow HAT is such an add-on which has been specifically designed for Android Things. It is available from Pimoroni (in the UK), and Adafruit (in the US). It’s wide availability was the main motivation for me using it for this series of posts.
It is worth pointing out that although the code accompanying this series is specific to the Rainbow HAT, most of the principles are actually pretty generic so the techniques covered here will certainly help in developing for other hardware combinations. Moreover, the example code is actually totally agnostic of the Raspberry Pi itself and we’ll be using Rainbow HAT specific drivers to actually perform the communication with the components on the
I won’t go in to details of how to get Android Things up-and-running on a Raspberry Pi 3 as it is already well documented here. It’s actually pretty straightforward to get it installed and running.
Let’s begin by considering some of the differences between Android Things and the mobile / tablet / TV version of Android that we’re all familiar with. The first major difference is that there is no guarantee that a device running Android Things will have a display our user input devices connected so any apps we write will not have a UI in the same way that a traditional app would. Of course the Pi has an HDMI out and USB sockets so we could connect a display, keyboard, and mouse in order to make use of the Android UI Toolkit to implement a full UI. However, not all devices running Android Things will be so equipped, so we may need to build our own UI in to the capabilities of the device itself.
In our example app we shall build a very simple UI using just the Rainbow HAT components. The Rainbow HAT contains a number of input and output devices which can easily be accessed and controlled from Android Things and we are going to use are: One of the capacitive buttons to exit the app; the temperature and barometric pressure sensors to gather the data for our weather station; the array of 14 segment alphanumeric LEDs to display the temperature; and the seven APA102 multicolour LEDs to display the barometric pressure.
Although our app will not require any Android permissions it is worth considering the implications that the lack of UI has on runtime permissions that were introduced in Marshmallow. These rely on the system requesting permission using the standard UI and this will clearly be problematic. For this reason, permissions revert back to the traditional mechanism of simply declaring them in the app Manifest and the user will review them at install-time.
Another standard Android feature that we cannot depend on being supported is the Notification framework, so we should avoid using Notifications.
Also, many of the standard Android apps will be absent from Android Things devices, so we should avoid using system providers for things like Calendar, Contacts, Documents, MediaStore, Settings, Telephony, UserDictionary, and VoiceMail; as well as DownloadManager.
It is also worth bearing in mind that many other features will depend on the hardware capabilities of the device itself. While very few mobile devices will lack capabilities such as internet access and Bluetooth the same will not necessarily be true for Android Things devices.
A number of Google services are available for Android Things (subject to to the previously mentioned hardware caveats) – a full breakdown of precisely what is and isn’t available can be found here.
So that’s high level overview of what Android Things can and cannot do. In the next article we’ll start diving in to some code and begin building our Weather Station.
There is no code to accompany this post as we haven’t written an yet – but there will be in the next post, I promise!
© 2017, Mark Allison. All rights reserved.
Copyright © 2017 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.
