Brillo OS is Google's offering for the newly emerging IoT space. Last year in May, Google announced this new operating system in their annual developer conference event, Google I/O 2015. Essentially, Brillo is an Android based OS, meant especially for embedded development and is designed to run in particular on low power and low memory IoT devices. It can support devices with RAM as low as 32 MB and 64 MB internal storage. Due to low resource requirement, brillo can be the underlying OS in a variety of devices used for smart home appliances, health monitoring devices etc.
Along with Brillo, Google has also introduced a suite of core services for communication between devices knows as Weave protocol. Weave communication protocol will provide the devices a common language to talk to each other, to the cloud and smartphones. Brillo OS will have built-in support for Weave services. Additionally, it will be available to other operating systems such as Android and iOS in the form of client SDK libraries. The app developers will be able to develop their own apps to control one or more devices on top of weave library.
Brillo is a stripped down version of Android operating system where the entire application framework layer based on java has been removed. It consists mainly of the lower native layers of android i.e. kernel and HAL. There are a set of native libraries on top of HAL layer which facilitate some of the operations of brillo OS such as network connectivity, device monitoring, power management through wake locks etc. Due to the similarity with Android OS, brillo OS is automatically compatible with those SOCs which are capable of running Android. Brillo devices can be built on ARM, x86 as well as MIPS architecture. Also, the advanced security features of android such as sandbox application architecture along with SELinux MAC will also be available on brillo out of the box.
Figure 1 : Brillo Architecture (source)
With Brillo, OTA update, remote monitoring and configuration of devices has also been a major focus for Google. The developer console will allow to send updates over the network to some or all of the devices belonging to a product. For downloading and applying the updated firmware on the device, brillo maintains two parallel partitions on the root filesystem. Only one of these partitions will be in use at a time, while the other partition is used to dowload new firmware and apply the update in the background. Whenever the device is rebooted next time, the partition with new firmware is loaded for execution. This architecture of keeping multiple partitions has been borrowed from Chrome OS.
The developer console also provides aggregated metrices and crash reporting features on the devices deployed in the field. The developers will be able to see how their devices are being used, how many active devices are in the field, the version running and the efficiency of the active devices. For crash reporting, brillo uses breakpad which is another tool imported from chromium code base.
Brillo works on the concept of BSPs instead of devices and the applications targeted for specific BSPs are called products. It supports three BSPs as of now in their developer tree:
To the developers familiar with Android build system, it will be very convenient to build brillo OS for one of these boards. Brillo is open source and available on AOSP like Android. Fastboot and adb tools can be used to interact with brillo devices from the desktop systems.
For development of applications using brillo, Google has announced a developer kit called BDK which can be used to configure a new application and build complete device image for that application. However, this kit is available only through an invite based early access program to a set of developers. But since all of the code is open sourced on AOSP, anyone can build their own image. The only things missing would be the access to weave developer console, services like OTA updates, remote monitoring and documentation for all the tools. So basically it should still be possible to build brillo based devices which can communicate over local network only.
Weave protocol provides support for device discovery, authentication and provisioning. As part of Weave services, the client libraries will formulate a provision flow which is common for all types of apps. The common device setup will make it easier for the users to find the right application for a device. Using weave service, the devices can be shared easily between users and the owner of a device can control the level of access granted to their devices. So some users might have full access to the device, whereas some other users might have a view only access and might require further permission to use the device. It also allows the devices to send operational commands to and from the clients such as mobile phones.
Figure 2 : Weave flow (source)
As for communication transport, devices can communicate over Weave using Wi-FI and Bluetooth low energy. The current library works over Wi-Fi only. The support for BLE transport is planned however. Weave supports communication over local networks as well as over cloud. If the phone & device are on different networks, the message would go through cloud to reach device. However, if both are on same local network, the message would go directly to device.
There are three major components of weave communication protocol, cloud, device and client (mobile, web, desktop). Cloud service provides fleet management operations for devices, access management and push notifications to apps and devices. It will also provide a REST API for web apps and services. For device side, a weave compatibility library called libweave is available for developers. Libweave is a C++ library which provides abstraction over the OS level details and implements weave protocol. libuweave is another library which is designed for use over microcontrollers. Libuweave can be used over devices which are not capable of running a full Linux stack. Nordic nRF51 is one such development kit which supports libuweave library on some of their boards.
For Android app developers, weave support will be integrated in the Google play services library. On iOS, a separate library (Google Weave iOS library) will help developers to leverage weave features. There is also a possibility that Google will release support libraries for web applications so desktop clients can also make use of weave services.
These cookies are necessary for the website to function and cannot be switched off.
These cookies allow us to monitor traffic to our website so we can improve the performance and content of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited or how you navigated around our website.
These cookies enable the website to provide enhanced functionality and content. They may be set by the website or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Do you have an upcoming project and wantus
to help speed up your time to market?