
Google launches developer preview of Android Things - type0
https://techcrunch.com/2016/12/13/google-launches-developer-preview-of-android-things-its-new-iot-platform/
======
pikzen
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.

~~~
Eridrus
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
So what's the advantage of using Android over straight Linux?

~~~
Eridrus
The advantage seems to be that you don't have to worry about the details and
you get updating for free. Writing good update code is hard and thankless, but
you can certainly do it yourself.

Not a tonne of benefits, but not a tonne of costs either. I'm sure Samsung
won't use this, but this might be good for projects just getting off the
ground.

------
hardwaresofton
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)](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...](https://www.silabs.com/products/wireless/Pages/nest-weave-thread.aspx)

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
How about Canonical [https://www.ubuntu.com/internet-of-
things](https://www.ubuntu.com/internet-of-things)

~~~
hardwaresofton
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

------
ndesaulniers
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.

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

~~~
bjackman
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.

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

~~~
anujdeshpande
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)

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

------
jfoster
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.

~~~
monkmartinez
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.

------
winter_blue
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
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.

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

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

------
brutus1213
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...](https://www.explainxkcd.com/wiki/index.php/File:standards.png)

~~~
XorNot
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.

~~~
brutus1213
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.

------
ClassyJacket
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
From what I understand, this _is_ Brillo. Just rebranded with some upgrades
(e.g. "Brillo 2.0")

~~~
ddeck
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_

------
mtgx
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
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.

