Hacker News Reader

Comment by pikzen | Hacker News Reader

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.

View on HN

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.

From what I've heard it will be eventually.

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.

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

> the comfort of using something more productive

This is reaching levels of absurdity nowadays. I mean, Android / Android Studio and "productive", compared on how you work with ESP8266? With NodeMCU, all you need is simple Lua, few console commands and a text editor. We're replacing that with a huge cow Android Studio is, shit ton more of commands and complexity need to operate it, and what?

Now each new toaster, instead of shipping an uC, will ship a whole PC inside? :/.

I find the ESP8266 quite good, specially its successor ESP32.

Given the programming languages we already could use on MS-DOS, both those chips are quite good.

However, I bet Google is trying to put Android into those areas that are now moving from C and C++ to Java.

This is the same game currently being played in HPT, it is cheaper to get Java developers, even with the increased hardware costs, than to keep writing trading systems in pure C++. Hence the pressure Oracle has got into improving Java's story in regards to AOT and value types.

So if a business is just going to deploy a couple of units, the difference between $15.15 (ESP8266) and $39.95 (Raspberry PI 3) might not be significant, when adding the salaries and respective development costs on top.

Of course, the best approach for those that care about Java and IoT is to just use a plain GNU/Linux distribution like Yocto and standard Embedded Java, instead of Android Java fork.

But overall I agree with your dismay.

I get that the cost of the developers working with more high-level platforms might be lower and that an SDK in Java-like language probably will be more popular than one in C.

It's just that using 512 MB RAM and a quad-core processor for something as simple as a light switch just seems to be so very wasteful.

There's also security aspect - there's only so much you can exploit in a simple uC running some tight firmware. Number of ways you can hack an embedded Linux system is dramatically higher.

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.

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

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.

some are: access to media frameworks, there are more android app devs and resources out there compared to whatever linux GUI framework you might use.

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.

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.

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

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?".

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

Reply on news.ycombinator.com