Android Things

Written on December 29 2016.

Google announced the developer preview of Android Things. You have maybe heard about Brillo last year without knowing what it really was. The promise was so vague and abstract that nobody really cared (at least in my circles). With Android Things the promise is clearer. The big title on the project homepage says:

The ease and power of Android If you can build an app, you can build a device

It means that you can leverage your experience and tools to develop products. If you've already built android apps you'll be at home. You can reuse Android Studio, reuse your existing Java code and deploy this to a device with or without a screen.

Good enough

But was is the difference with the myriad of other products in the market? It's very easy to boot a Raspberry Pi, write some Python code and control the GPIOs to drive almost everything. The hobbyists already have all the tools they need to tinker and to build something useful.

When targeting Android Things, a developer can prototype on a board and easily deploy on another one. It seems that Google has certification process for Android Thing. Switching the underlying hardware and reuse the code is already possible with other OS of course but certified boards/microprocessors could greatly improve the experience.

Unless an hobbyist is a hardcore android developer there is proably not a lot of reason to pick Android Thing for your next project. Setting up the Android SDK, learning Android Studio and all the associated tools (e.g., adb, logcat) is not straightforward if you are doing it for the first time. It's probably faster to connect a screen, keyboard and mouse on your Pi and start coding.

Updates

In an industrial setting the requirements are quite different. Processes are in place and you want to leverage battle tested tools. Products can have a very long lifetime, 10-20 years is common and you might need to mass produce them. If the business is not life critical, a Raspberry Pi and your code on it is probably enough. If the product is connected to the internet, you must be much more careful about what you do and you should have a transparent update mechanism to upgrade the device remotely. Beware that this update mechanism can also be abused to compromise the deployed devices. This really is a nightmare today.

In the eve of 2017, automatic and transparent updates are vital. This year, we've seen a lot of security issues from companies selling IoT devices in the fire and forget style. Consumers don't realise that their connected lightbulbs, coffee maker and fridge are actually dangerous items that can be used in huge Denial of Service attack. Manufacturers have no incentives to level up their security and update practices.

Updating the OS running the devices is critical. Software companies are working hard to make this easier for developers and product manufacturers. For example, Canonical builds Ubuntu Core which provices a foundation on which products can be built. This is also where Android Things can shine. It is still vaporware but Google announced that they will provide the infrastructure to remotely update deployed devices. If done well, this could be a huge win as it would remove the burden that is currently imposed to product manufacturers. It also means that a product now relies on Google's goodwill. If they shut down the service, you're screwed.

Locked OS

With Ubuntu Core, you have complete freedom over the OS. You can start a webserver, tune the processes that are started at startup, if you have some linux administration skills, you'll be right at home. With Android, this is another story, as a user you have much less flexibility. The OS is made for phones/tablet thus it is quite hard for apps to manipulate the system. On a phone, you don't want third party app to touch the system. When a developer builds its own system, she wants to tune it exactly to fit her need.

Of course this is more dangerous but an IoT device does not have an app store. The code is loaded into it and then it should run forever (and get updates if it is connected to a network).

Bare metal

Now of course, all this only applies if:

1. The device does not need connectivity to the outside world,
2. The device does not need a full blown OS. Linux (or any non-specialized OS) brings a huge overhead: you need a more expensive and more power hungry processor and it's harder to put the electronics in deep sleep mode. If realtime processing is a requirement, an OS might not be the best choice neither.
3. The device is life critical. That the software runs on top of a huge pile of software layers that the developer does not control. In life critical systems you need strong guarantees that the system handles failure.

In those situations a lightweight approach might be better. Something bare metal without an OS at all or with a specialized embedded one (e.g., FreeRTOS) will be more power efficient and cheaper to produce.

Conclusions

• Android Things is trying to solve the same problem than Ubuntu Core (or other similar effort)
• The first question when developing a product is whether or not you need full blown OS. Considering the following criteria:
  • Cost
  • Network connectivity (and thus security)
  • Updates (both the application code and the underlying system)
  • Realtime constraints
  • Lifetime

We will see in the following months which hardware partners Google will have and which guarantees they will give with the update mechanism.

To me, Android Thing would be the killer OS if it was more moldable. There is not a lot of documentation on how to tune the system for a specific need. I guess this will come with time and experience.

Exciting times.