Google Scrubs Brillo, Reveals Android Things

Another week goes by and another new IoT platform surfaces. Google has announced Android Things, a build of the mobile operating system designed for smart devices rather than the latest slab of mobile eye-candy. The idea is that the same Android tools, framework and APIs that will already be familiar to app developers can be used seamlessly on IoT Things as well as in the user’s palm.

Of course, if this is sounding familiar, it’s because you may have heard something of it before. Last year they announced their Project Brillo IoT platform, and this appears to be the fruit of those efforts.

So you may well be asking: what’s in it for us? Is this just another commercial IoT platform with an eye-watering barrier to entry somewhere, or can we join the fun? It turns out the news here is good, because as the project’s web site reveals, there is support for a variety of Intel, NXP, and Raspberry Pi development boards. If you have a Raspberry Pi 3 on your bench somewhere then getting started is as simple as flashing a disk image.

The Things team have produced a set of demonstration software in a GitHub repository for developers to get their teeth into. Never one to miss an opportunity, the British Raspberry Pi hardware developer Pimoroni has released an Android Things HAT laden with sensors and displays for it to run on.

The IoT-platform market feels rather crowded at times, but it is inevitable that Android Things will gain significant traction because of its tight connections with the rest of the Android world, and its backing by Google. From this OS will no doubt come a rash of devices that will become ubiquitous, and because of its low barrier to entry there is every chance that one or two of them could come from one of you. Good luck!

19 thoughts on “Google Scrubs Brillo, Reveals Android Things

    1. I like that someone is feasibly trying to unite all the different things, instead of trying to make millions with a IoT board. This should benefit from the security efforts already put into Android.

      1. no its not. not really. it was hamstringed so much its not linux anymore.

        can you upgrade single components? view all source for things that run on it? can you patch it? can you change the bootloader and root it, for ALL android phones? can you remove things you don’t want?

        linux is one thing, but I refuse to consider android a ‘flavor of linux’. its a stripped down CHANGED version of linux that is not linux anymore. sure, it has historical roots in linux but google messed it up so badly and fragmented the market so badly, its now a horse’s ass of an o/s.

        when you can upgrade security bugs on ‘abandoned phones’, then lets go back to calling it linux. until then, its a mostly closed system that does what a particular set of vendors want it to do; and one of the things they want is NOT to empower you. quite the opposite of what a real linux distro is.

        1. True calling Android Linux is like calling iOS BSD.
          But being tied to tied to server side resources and subject to becoming an orphan device over night is one reason I do not like so called smart devices very much.
          A true smart device will still have most of it’s functionality without the cloud services which should only be for increased capability.

      2. It is not, not even remotely similar. It just uses a heavily tainted Linux kernel surrounded by a dumbed down system which is designed to treat its users as such. It is also not to be considered open source since it heavily relies on closed proprietary drivers to work on every device it is installed on.

        Android based IoT devices are a terrible idea only Windows ME based routers could beat in stupidity. …Maybe.

      3. Technically, Android is Linux distro but IMO, we need more precise naming like Android/Linux or arm-linux-androideabi.

        Android and normal GNU/Linux, uClibc/Linux shares Linux kernel but they’re not ABI compatible each other. Unless binary is statically compiled, they cannot run binary from different ABI.

        1. I think the main obstacle is/was the GPU driver. I know Broadcom realeased some sort of sourcecode, but the official developers weren’t that interested in porting Android to it.(aside from some very early efford to make it run) So, its all up to other developers to port Android in their free time.

    1. Java isn’t that bad anymore, Android has a lot of optimizations, and API churn isn’t an issue, seeing as you can make an Android app targeted at API 1 and it’ll still run on the latest firmware. They deprecate APIs for new apps but they still work for older apps.

    1. The Intel Edison module includes both an Atom and Quark core connected via a shared memory architecture. It ships with a Poky Linux distribution which runs off the Atom. There is a separate MCU SDK and RTOS (Viper) that allows you to implement real time functionality on the Quark core. Don’t really know how Android Things glues these together but am sure Android Things runs on the Atom core, not the Quark. If the port is clever then they would have partitioned some of the sensor/protocol stacks and have them run on the Quark.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.