Google launches developer preview of Android Things

https://techcrunch.com/2016/12/13/google-launches-developer-preview-of-android-things-its-new-iot-platform/

by type0 • 10 years ago

134 68 10 years ago

From what I've seen, the automatic update system is sweet. I'm really glad the team decided to tackle one of the largest blockers to adoption (IMO) which was providing security updates.

taneq3• 10 years ago

So all of my network-aware things are now going to have an excuse to demand internet connectivity so they can dial Google on a regular basis? I'm not sure that's worth the tradeoff.

bitmapbrother2• 10 years ago

What exactly did you think the "I" in IOT stood for? Also, like Android there's no need to use Google services. Just patch it and update it yourself if you're so inclined.

IshKebab4• 10 years ago

If they're using Weave they are going to need internet connectivity anyway.

frozenport• 10 years ago

This seems like a security vulnerability, especially when running up against a state actor who can demand you receive a specific update.

bjackman• 10 years ago

That is true but the risk of backdoored updates by state actors is a reasonable price to pay for security fixes to avoid every device being a node on a script kiddie enormous bothnet, or a WiFi ingress point, IMO. If the software is broken and not updated, a state actor can hack it anyway.

angry-hacker• 10 years ago

I believe if you want to avoid state actors, android and smartphones are not for you. This is sad reality. I don't know the alternative.

With this model at least you're not part of botnet for sale, so that's a good thing.

If you want to avoid state actors you have to live the lifestyle of Stalman or something similar.

ndesaulniers2• 10 years ago

Meanwhile security researchers publish security exploits against your now outdated device. Damned if you do, damned if you don't [upgrade] it seems.

digi_owl3• 10 years ago

I guess it will be built around the system they use for ChromeOS and also introduced with Android 7. Meaning that you have two OS partitions. One is active, another on standby. When a update gets pushed it gets written to the standby partition. Then on the next reboot, the two partitions switch roles. If the new and updated partition fails to boot, then it falls back to the old one. If not the old one enters standby and will be overwritten when the next update gets pushed.

Thing is though that on ChromeOS, there is a core part that never gets updated. This is why only certain newer Chromebooks could get Android app support. Because the way they implemented it required a minimum Linux kernel version.

And over on the Android side you still have the issue of OEM and carrier meddling in the update process.

So i fear that this platform will be beset with similar issues once it starts to spread beyond the realm of enthusiast dev boards.

pgeorgi2• 10 years ago

Thing is though that on ChromeOS, there is a core part that never gets updated. This is why only certain newer Chromebooks could get Android app support. Because the way they implemented it required a minimum Linux kernel version.

It's possible to update kernels in ChromeOS (there are A/B partitions for them just like for pretty much everything else). The main question is how much effort should be invested in bringing "ancient" (in computer time) SoCs up to speed to support a use case (Android) they might not be powerful enough for (both CPU speed and memory availability).

mtgx• 10 years ago

From what I hear not only will all Android Things collect data for Google, but also all devices that use the Weave protocol (for which the device makers have to use Google's servers).

That's crazy, if true. An IoT communication protocol shouldn't rely on Google or any other company to work. Imagine if your Wi-Fi router only worked if Samsung got to collect all the data that passes through it.

This sounds even worse than when people complained that in some cases data from AMP pages would go through Google. At least then developers could still use the open source independent version of AMP.

theDoug• 10 years ago

Any sources? I ask in good faith, but it's also easy to say "from what I hear" then "that's crazy, if true" for nearly anything.

taneq3• 10 years ago

Well, a fair few smart TV functions only work if you allow the TV to phone home (and agree to them using the built-in mic and camera to capture and upload audio and video at any time and use it for any purpose).

This is another step beyond that, where your light bulbs have to phone home to Google and to their manufacturer.

lai• 10 years ago

Has anyone tried to get Android Things (Brillo) to work with other micro-controllers than the ones they support out of the box?

lgleason3• 10 years ago

I'm not sure I would call these platforms micro-controllers. With that being said there is support for weave on a select number of micro-controllers.

anujdeshpande• 10 years ago

Brillo is for microprocessors (think Raspberry Pi, BeagleBone Black, etc) whereas Weave is for micro-controllers (think the newer Arduino's which are running a Cortex-M of some sort)

IshKebab4• 10 years ago

Nope. Brillo (Android Things) is the OS. Weave is the communications protocol. You can have Weave without Android Things, or Android Things without Weave.

pikzen• 10 years ago

I know the entire IoT sphere is completely pants on head stupid these days but... Android. On an embedded product. Even with no UI (assuming it will all be controlled through one gateway), Android doesn't scream "efficient with its resources" to me. 1GB of RAM on a microcontroller to get it running efficiently (what the Edison seems to have)?

And joy oh joy, another Google-made API to use. You can feel me bursting with joy at this prospect. They are of such good quality.

I guess automatic updates are sweet.

astebbin2• 10 years ago

Google Weave, aka libiota, is targeted at lower-capability MCUs like the Marvell MW302 with its 512kB of RAM:

https://developers.google.com/weave/guides/overview/what-is-...

Based on these two links (including the parent), it wouldn't surprise me if a Google Weave API was soon exposed on Android Things.

lgleason3• 10 years ago

From what I've heard it will be eventually.

Eridrus2• 10 years ago

The performance issue stood out to me at first too, but with no UI and Dalvik really only being optional and Google's background services stripped out, this is mostly just a weird Linux, so I'm not sure why this would perform significantly worse than any other Linux-based OS.

Sadly I don't know enough about hardware economics to say whether hosting a whole OS is crazy or not, but we've been trading off CPU time for less developer time in every other area of development, so I don't see why it would be different here. To the extent that the OS itself is not what is causing you problems, you can keep optimising your app code as you go and release on cheaper and cheaper hardware if you want.

cbdfghh• 10 years ago

So what's the advantage of using Android over straight Linux?

Normal_gaussian• 10 years ago

If you don't have a tight power budget hosting a 'whole OS' isn't crazy (though it doesn't mean it isn't wasteful).

Most chips will use an RTOS for the timing guarantees, and they generally provide better power resilience than other OS's.

lgleason3• 10 years ago

The Pico is a half a gig of ram. That is not micro-controller size, but it is still a little better.

mszcz2• 10 years ago

That's what I've always wondered. What the hell are those things doing with these resources? I mean if you take a step back and just look at what their purpose is - operating a light switch or reading the temperature - the amount of resources they use seems ridiculous.

I've been tinkering with the ESP8266 and it's got 64k RAM and that seems enough to get a TCP/IP stack, WiFi and even a simple web server.

pjmlp5• 10 years ago

The issue is of scale, it is just a few euros difference.

So unless you are mass producing and need to save each cent per unit, the comfort of using something more productive will always win out in total project costs (hardware cost + development time).

pjmlp5• 10 years ago

I know the entire IoT sphere is completely pants on head stupid these days but... Android. On an embedded product.

That is what people asked for, apparently.

The initial plan for Brillo was to replicate some of the Android frameworks in C++.

"We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK), Google Play Services, and Google Cloud Platform."

https://android-developers.googleblog.com/2016/12/announcing...

fest• 10 years ago

The general trend for embedded devices is in the direction of richer ways of user interaction.

That usually involves adding touchscreen LCD.

Once you add LCD, you want nice graphics, animations etc. While you can use microcontrollers for low-res LCDs, when you get past, say 640x480px resolution, due to increasing memory and CPU requirements it often makes sense to go with system-on-chip solution running high-level OS.

The existing libs/frameworks to create nice looking, polished UIs for embedded Linux devices are not as easy to use, well understood and having large base of developers as Android is.

So this leaves device manufacturers seriously considering Android. Working on software stack directly with SoC manufacturers is PITA (although they want you to buy chips from them, they don't want to spend time on support), so having a flavour of Android geared towards embedded devices is a good value proposition from Google.

IshKebab4• 10 years ago

I agree. The minimum requirements for Brillo were already infeasible for most products. Now they want to use Java? Most IoT devices run on a Cortex-M or similar with less than 1 MB of RAM.

That said, you don't have to use Android Things. I guess it's more a case of "if you have a system that runs Linux anyway, why not use Android Things?".

jfoster• 10 years ago

It's interesting, but I'm skeptical of Google's first attempt at anything, particularly Android. It took them a few attempts at TV and Auto, and they're probably not done with those yet.

It's great that they've got something for IoT, but I wouldn't want to build anything serious with this yet.

monkmartinez2• 10 years ago

Chromecast is pretty darn awesome! Google Assistant ("Ok, Google") is miles ahead of many of its competitors. You don't really need Android Things (Brillo 2.0) to build IoT stuff using Google services. Also, not its first attempt.

IshKebab4• 10 years ago

Technically this is their third or forth attempt. There was Android@Home, and Brillo which was also based on Android, but didn't include the Java stack. I'm pretty sure there was another attempt that I've forgotten too.

ClassyJacket• 10 years ago

Google's willingness to drop their projects really gives me no confidence as a potential developer.

What happened to Brillo? Why start a new project with a new name instead of just making Brillo 2.0? Should I invest anything in this or will they just drop it again?

Navarr• 10 years ago

From what I understand, this _is_ Brillo. Just rebranded with some upgrades (e.g. "Brillo 2.0")

ddeck• 10 years ago

Yep. From the article:

It combines Google’s earlier efforts around Brillo (which was also Android-based, but never saw any major uptake from developers) with its Android developer tools like Android Studio, the Android SDK, Google Play Services and Google’s cloud computing services. Support for Weave, Google’s IoT communications platform that (together with Brillo) makes up Google’s answer to Apple’s HomeKit, is on the roadmap and will come in a later developer preview

pjmlp5• 10 years ago

Not just rebranded, they dropped the plan of having the frameworks redone in C++ as discussed at Embedded Linux talks, and took the Java ones from Android instead.

sker• 10 years ago

I wonder what will MS come up with to counteract this: Microsoft Windows Ultimate Surface Things.

monkmartinez2• 10 years ago

I hope it is something cool. They have shown a remarkable willingness to contribute "something" to just about "everything" in recent memory. A lot of has been open to boot!

I do not want to let you down, however, and will provide an equally inflammatory remark: We do know that Apple will continue to build walls around Homekit making it virtually useless to anyone outside the already fortified walls of iOS!

dano• 10 years ago

MUST - nice acronym

pjmlp5• 10 years ago

They already did, UWP support for Window 10 IoT is older than Brillo/Android Things.

hardwaresofton4• 10 years ago

As long as this version of android stays as open as regular android I think I'll be happy.

It is super sad that Mozilla decided to leave this space though (even if trying to pivot FirefoxOS was nothing but trying to buy time). Wish there was a less insidious company trying to get into all my devices.

Also, why "Weave" instead of just using Thread? ( https://en.wikipedia.org/wiki/Thread_(network_protocol) )

[EDIT] - It looks like Weave IS built on Thread, though it's a little sad that it took me so long to figure it out:

https://www.silabs.com/products/wireless/Pages/nest-weave-th...

My knowledge of the Thread Group's management/scheme layout was lacking, it looks like it's INTENDED that thread is meant to be below one layer of abstraction, managed by different vendors (sillicon labs, nxp, etc)

rohan1024• 10 years ago

How about Canonical https://www.ubuntu.com/internet-of-things

hardwaresofton4• 10 years ago

Thanks so much, haven't kept up with Canonical since switching off of Ubuntu, didn't know there was another option like this

[EDIT] After spending some time looking at Ubuntu Core... is it just a smaller Ubuntu distro + managed updates?

I do like the "snap store" concept... marketing jargon aside, it seems like Canonical is paying attention to both developer and user ergonomics more than ever

[EDIT2] Ubuntu core & snapcraft.io are pretty exciting

astebbin2• 10 years ago

Thread provides a network, but no application-level semantics. In other words, Thread is to 802.15.4 as WiFi is to 802.11. Once you've set up a Thread network, you still need an application layer like CoAP or Weave to control your connected devices.

hardwaresofton4• 10 years ago

Thanks -- I just realized this, looking at some of the thread groups white papers and some of the cooperating companies' sites. Updated original post

bfrancis• 10 years ago

With regards to Mozilla, see https://connected.mozilla.org/

Mozilla is working on IoT products and an IoT platform based on the Web of Things.

digi_owl3• 10 years ago

That seems like a catch all blog, that at least to me gave little clue as to what they were working on.

On that note i seem to recall them working on a small web server and auto-discovery system that allowed any mobile device to share something. To me that seems like the perfect IoT starting point, as now you do not need an app for every damn device.

alexandros• 10 years ago

Wish there was a less insidious company trying to get into all my devices.

Sounds like a call for a shameless plug! We have recently released resinOS[1] as a stand-alone OS after a few years of development and production deployments on resin.io[2] connected devices.

[1] https://resinos.io [2]: https://resin.io

tyingq• 10 years ago

As long as this version of android stays as open as regular android I think I'll be happy.

I can't seem to find a license anywhere. It does seem to include access to some Google services that the open source android libraries do not: http://i.imgur.com/IEZYLwN.png

winter_blue• 10 years ago

What's the benefit of using Android on a micocontrolller? Since these devices will likely have no UI, a significant chunk of the Android API will be irrelevant.

Is the pro that you get to use Java with a (hopefully) friendly API vs writing in C or C++ as in the old days?

BoorishBears• 10 years ago

Why do you assume they'll have no UI? The displays are optional, not disallowed.

For what we do at my workplace this is a godsend. We design installations for retail environments that need to have very rich interfaces. For us it's not MCU vs Android, it's embedded PC vs Android hardware.

We were already doing similar things with stock Android except we had to use custom boards interfacing over USB to do anything involving sensors to stay somewhat free from specific hardware.

We were running into limitations in Android that centered around the fact that it is targeting consumer devices first and foremost. Android 6 brought COSU mode, but it still showed signs of the steady march towards a more locked down Android.

Besides the pro of supporting our usecase in a first class manner, having access to the Android UI framework or a web browser is big for those complex interfaces.

The productivity gains vs trying to build up that stack from a bare ARM MCU are immeasurable in the literal sense (a separate company contracted to do something like that would probably have more employees than we currently have working on software)

And of course, being able to hire Android devs and take advantage of the ecosystem doesn't hurt.

brutus12132• 10 years ago

I work in this space. While this platform looks a lot better than previous Google efforts, this is no way a solution. A key problem with IoT is too many standards that don't play nice with each other. And this is not a technical problem - everyone just wants control of the platform. If you think Android is open, you are being naive. In recent months, I thought things were going to get better with major consolidation between Iotivity and AllJoyn. This is not a step in the right direction. Oh .. and obligatory xkcd: https://www.explainxkcd.com/wiki/index.php/File:standards.pn...

XorNot• 10 years ago

What I want is my IoT devices to get IP addresses and respond to a simple HTTP REST api. The semantics of it don't matter much to me, provided it supports SSL and avoids session-management BS as much as possible, but I'll deal.

If you want to offer a cloudy service on top of that, I'll buy your cloudy-service box which offers to do that, but it better be using the same API to control those devices because maybe I don't want your cloudy box and want to integrate them with vendor B's devices or vendor C's + some homebrew stuff.

brutus12132• 10 years ago

I'm curious what kind of API would you want? There are so many devices out there, it makes things challenging. Best proposals I've seen define a base API for discovering what are other APIs that a particular device supports.

Google launches developer preview of Android Things

Related Stories