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.
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).
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.
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.
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.
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."
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?".
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.
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)
> 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.
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
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.
Unfortunately, I'm a little wary of trusting mozilla to support their groundbreaking/interesting-to-developer projects anymore (for better or for worse, many people applaud their renewed focus on Firefox)
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.
>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
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.
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.
> 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).
My impression was that it was more a case of drivers (much like with getting older Android devices updated to recent Android) than the hardware capabilities themselves.
After all, the SoCs in use are much the same ones that are powering said Android devices already. The overhead of the ChromeOS addition should be minimal.
A configuration with a 3 year old SoC, lower end RAM setup and a very small disk (because Chrome OS is supposed to be stateless, unlike Android) might not provide a good environment to run Android in, especially if there's some overhead in having two display managers around that need to be coordinated.
Also, there might be additional requirements for the GPU - all that map-Android-display-to-Wayland stuff that is used to get Android output into Chrome OS windows requires a bunch of capabilities that aren't necessarily efficiently implemented on older SoCs. Rendering to offscreen buffers is a feature that GPU designers provided and improved bit-by-bit and only with lots of market pressure.
A couple hundred hours of work to bring the kernel forward (and test that it doesn't introduce regressions) for a feature that will only frustrate users (because it's there, just not practically usable) may not be a good investment.
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.
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.
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.
I was kind of hoping it meant "internet" in the sense of "I can connect to and control the device from my phone", not "the device will be sending data to its manufacturer". Hopelessly naive, I know.
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)
Nope. Brillo (Android Things) is the OS. Weave is the communications protocol. You can have Weave without Android Things, or Android Things without Weave.
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.
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.
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.
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?
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.
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!
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...
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.
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'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?
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
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.
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.
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.
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.