Video
Slides
Summary
On February 23, 2017, Geeta Krishna and Anisha Kulkarni gave an introductory course on Android Things* at the Embedded Linux Conference + OpenIoT Summit in Portland. The following is a transcript.
Transcript
Geeta Krishna: Thanks for coming to our Android Things* talk. My name is Geeta Krishna. I manage the code enabling team at Android Things at Intel. My team has been working closely with Google* to provide board support packages for some of the IA-based developer boards. My co-speaker is Anisha Kulkarni. She's an experienced developer for Android* and is leading the bootloader component of Android Things in the team right now. We also have a talk later at 11 a.m. in the same room by Sanrio who would be diving into the peripheral manager and providing more details for you on that, so be sure to attend that as well.
The outline of the session today is we will provide you with what Android Things is, its deployment model, get into the technical details of the architecture, walk you through getting started on a developer board, provide code samples, online resources, and then take questions in the end.
Android Things is the new OS from Google. It's based on Android and targeted for the Internet of things market. For those of you familiar with Brillo ... How many people are familiar with Brillo here? Quite a few. It's a successor to Brillo and is a rebranded version of Brillo. The main difference between Android Things and Brillo is that Android Things brings back into the stack the Android APIs and the Android run time, plus Android Studio, which was missing in Brillo. Another key difference is that the deployment model is very different from what Brillo was. In essence, Android Things is Android without system apps and the content providers. In addition, it adds functionality which is necessary for the IoT development.
The key functionality is peripheral manager, which allows for apps to interact with sensors and actuators through APIs and industry standard protocols like GPI and I2C. A developer's console, which helps register the device and control it. Metrics and analytics for monitoring and maintaining the health of your fleet of devices. Weave, which is an open, secure communication protocol between the device and the cloud. 6LowPan and Threads low power network protocols. It also supports A/B style OTA updates, which allows for the update to happen on an alternate partition and features rollback on failure and also less downtime on an update.
As Android Things loses a lot of the baggage that comes with the apps, the memory footprint is much lesser than what would be for Android*. It can run in about 500 megabyte, or less than 500 megabyte, as opposed to Android, which requires almost two to three gigabytes.
As I mentioned, it's a fairly new OS. The first developer's preview was released two months back in December, which featured basic OS functionality and support for four developer boards. The second developer's preview was released just two weeks back on February 9th. It added two more developer boards to it and had some bug fixes and support for USB audio, code sample for TensorFlow. And that's pretty much it.
Google has committed to providing developer's preview every six to eight weeks, and you can participate by downloading the image and playing with it, filing bug reports. You can also provide feature requests. There's discussion forums, both in stack overflow and Google+ forums.
So, as you can see, there's quite a few key features that still missing from Android Things and will be in future releases. One of them is Weave, which is the communication protocol between the device and the cloud. Weave is the secure, open communication protocol from Google. It provides for an IoT developer console, which you can use to register the device with the Weave server. Provides bidirectional device-to-cloud communication. Also, once connected, the device can leverage all of the Google services like Google Assistant and state Storage in the cloud.
Another thing that Weave tries to address is the issue of device interoperability. It provides commonly used schemas for devices, which the device manufacturers can base the device on so that devices can talk to each other.
For those of your familiar with Brillo, you would remember that Weave was an integral part of the OS. For Android Things, it has been de-coupled, and will be installed as an APK. So it will have its own release cycle, which may or may not match with that of Android Things.
If you attended Imad [Sousou]’s keynote on Tuesday, he talked about OCF and IoTivity. OCF publishes open IoT standards, and IoTivity implements the standards. So there's nothing stopping you from using IoTivity with Android Things, even though Weave is the preferred protocol. In fact, if you go to the Intel showcase upstairs, there's a demo reel running Edison-based jukebox based on Android Things and being controlled by IoTivity.
Gartner projects that there will be about 200 billion IoT devices by the year 2020, which is 30 times more than what we have today. However, IoT development is fairly challenging right now, not in its maturity at all. There's complex technologies that require a wide range of expertise. Device interoperability is a major issue. Devices from different manufacturers, even the similar devices are implemented with different features, or the features are implemented differently so that the apps and users have to interact with them in different ways.
There's security vulnerabilities because of the always-connected nature of these devices. Scalability, both in deployment and maintaining long-term. We saw that Android Things addresses some of these issues by bringing in the Android development framework to leverage the Android ecosystem. The peripheral manager makes the hardware prototyping easier. Weave addresses some of the device interoperability issues, plus provides a secure communication protocol. The device security comes for free with Android, with the Android security module, and its features like verified boot and secure boot.
In addition, Android Things offloads the burden of customizing the OS and maintaining it by employing a deployment model of OS-as-a-service. In this model, Google will generate all images and maintain all the OS images. They will also sign the images and provide all of the OS updates through OTAs.
There is also introduced a concept called system on a module, which would incorporate the SoC, the BIOS, PMIC, memory, storage, and networking so that there's an encapsulated hardware module for you to use, which is well tested with the OS image.
Intel or the silicon manufacturers will provide Google with the boot support packages. OEMs or the device manufacturers will provide the HAL for the sensors and actuators, and also provide the applications that provide the differentiation to the device.
This works very well for the low- and mid-scale companies because they can focus all their energy into what is differentiating for their device, rather than having to maintain and develop an OS.
Google is also going to support the OS trained releases long term. They will be supporting multiple OS versions at the same time. The devices can get security updates for these OSes whether you choose to stay on the same OS for the lifetime of the version or you can jump to a different version as well.
The IE-based boards supported on Android Things. There are three of them which are based on Edison: The Arduino board, the SparkFun Blocks, and the mini breakout board. The developer's preview two also added support for the Joule Compute module, which is one of our high-end compute modules. It also features a GPU, and we have enabled the graphics stack for it as well.
The other boards supported are Raspberry Pie and a couple of NXP boards. We have the Intel boards here for your to play with afterwards and also some of the sensor kits that have been developed for them.
In summary, Android Things makes the development for IoT simplified and also accelerates it, so you choose prototype developer board, which meets the needs of your product, both cost-wise and technology-wise. Then you can quickly prototype on it by taking advantage of all the tools that Android Things provides, work with the silicon manufacturers to scale, and then deploy the product with all the Google services behind you, including long-term OTAs.
I'll now pass it on to Anisha to go with the architecture.
Anisha Kulkarni: Thanks. Thanks, Geeta. My name is Anisha and I work in the Android Things group. I've been working on Android for the past three years and Android Things for a year now. So I hope I can provide you guys with a good technical overview of Android Things, probably, and also compare Android and Android Things. I'm going to leave you guys with a few steps on how to get started building applications on Android Things.
What is the Android Things stack look like? This is a figure of the Android Things stack. As you can see, it's quite similar to that of Android. You have the Linux kernel, on top of which sits the hardware abstraction layer. And from the OS, you communicate to your hardware through the hardware abstraction layer. So in case you want to enable graphics, you would have to program a graphics HAL to talk to your graphics driver from the Linux kernel.
In comparison with Brillo, Google has enabled the Java API frameworks Google services on Android Things. What this means is that you are now able to write Android applications for your IoT devices. And the API level that you would be working on is 7.0, which means you can write Android applications at N dessert for your IoT devices.
Also, in addition to the Java API framework, and the Google services, Google provides you with the Things Support Library, which enable Android developers to speak to their hardware like sensors and actuators using a peripheral manager. I'll be talking in more detail about the Things Support Library.
Another key difference from Android [Things] is that OTAs are received directly from Google. Earlier in Android that was not the case. The BSP provider would have control, would have to release their own OTAs.
So what are a few of the other differences between Android and Android Things? Most of us who have worked on Android must have seen this stack before. What's different is that Android Things does not come with a set of pre-built system apps. Basically, when you have your Android phone you have the calendar app, or an email app, which come by default. Android Things does not have that. Also, there's no concept of content providers. You cannot communicate from one application to another using content providers.
Most of the Google APIs which are supported on Android are supported on Android Things, except for the caveat that all of the APIs which require user authentication have not yet been enabled. This is probably because we're still on developer preview two, and all of the security features have not yet been enabled.
One of the key differences between using an Android phone and using an Android Things IoT device is the way that the user experience is. You don't have navigations on the Android Things device to move from one app to another. Android Things introduces a concept called the home activity, which you'll use an intent. Basically an intent is a concept in Android where you can say, this is what I want to do. So you provide an intent, saying I want to use the IoT launcher intent, which means this application would be the first app which runs once you boot your device.
The whole user experience is a way that only you're interacting with a single application. But you can still run more than one application on your device. Another thing is that you don't have a concept of a Play Store where you could go and download an app. Whatever your device comes with, those are the apps that would be running. You don't download new apps on Android Things.
I mentioned about the Things Support Library. What does an IoT developer want to do? Mainly he wants to be able to programs sensors and build cool apps using sensors and actuators. Android Things introduces two types of APIs which enable you to do that.
These are the peripheral IO APIs and the user driver APIs. Basically, what you do with the peripheral IO APIs is talk to the Linux Sysfs and program through interfaces like GPIO, UART, I2C. One would say I could directly program the Linux Sysfs. Why would I want to go through peripheral manager? This adds a layer of security through SE-Linux policies and provides mutual exclusion in that, if a sensor is using a GPIO port already, peripheral manager gates you from using that very same port.
The other type of APIs are the user driver APIs, in which you can actually write a sensor driver and have other applications use the driver through these exposed APIs.
One of the key concerns or challenges in IoT devices is security. Although Android Things is a fairly new OS, it borrows a lot of majority from Android. You would basically be running with the same level of security that your Android device which is running Nougat would be running. I'm going to walk you guys through a few of the security features that the Android Things, basically Google requires Intel to implement.
Whatever kernel your Android Things device is running has to run with SE-Linux enforced. In addition to the DAC policies, which the Linus file system has, you would additionally be enforcing mandatory access policies through SE-Linux enforcement.
That covers the kernel-level security. In addition, Google introduces two of the key concepts for hardware-backed security. Verified Boot is basically a cryptographic chain of trust right from the hardware root of trust, up until the system image that guarantees you the integrity of the image that you're running. Basically, on first boot, you have the BIOS which is trusted by IFP keys, the hardware root of trust. The BIOS only boots the boot loader, which it trusts. The boot loader would only boot the boot image or kernel which it's trusting. And then, right up through the system, the OS image, you have this cryptographic chain of trust.
Also introduced in Android is the Google Android Trusty. Trusty OS is basically Android's trusted execution environment. What is a trusted execution environment? When you want to do a few secure operations, you would want the main OS not to be able to access these resources. This is why you would run either using a secure processor or a virtualized environment. Google actually provides a reference implementation for trusty which is based on ARM and is called Trust Zone, but Intel has its own solution for the trusted execution environment.
Here is a stack of Intel's solution for Trusty. All of the components in blue are the ones which are implemented by Intel, and all of the components in orange are what Google provides you through the AOSP tree.
As you can see, when you run with Trusty OS enabled, both Android OS and Trusty OS run as guest OSes on a secure monitor hypervisor. Google provides you Trusty drivers, which are added to the Linux kernel in order to talk to Trusty OS. Basically, it's very similar to just starting an IPC and communicating. Android OS passes across messages to Trusty OS. Also provided by Google are the Trusty libraries, which are helpers for the various apps in order to call in to Trusty.
So how is Trusty OS given this hardware root of trust? There's the following sequence of events which happen to pass the Trusty root key from the hardware using the CSE. CSE is a consolidated security engine, which basically is a secure entity which is the only one who can access these IFP keys. The CSE is basically firmware in the IAFW, which is the Intel BIOS. The CSE generates a Trusty root key and the bootloader passes the trusted root key from the CSE to Trusty OS.
The communication from the bootloader to the CSE happens by a protocol called HECI. Once the Trusty root key is in Trusty, it's used by Trusty for various other trusted apps. Basically, that's the primary key from which keys for other apps like Keymaster, Gatekeeper, etc., are used.
So what is an application of the trusted execution environment, and when would you use it? A very common example is that of DRM keys. You don't want anyone be able to steal your secure content. All of the encryption and decryption, the DRM keys are stored in Trusty and all of the encryption and decryption happens in Trusty. All of that data is never stored in the Android memory.
Another example where you would use Trusty is for full-disk encryption. With the introduction of the Java API framework, also came the enablement of the graphics stack on Android Things. The graphics stack for Android Things from the AOSP perspective, is exactly the same as it would be for Android. On the Joule module, we have enabled both 2D and 3D apps. Following the same protocol, all of the blocks in blue are those which would be implemented by Intel, and all of the ones in orange are that from Google.
You have your hardware, and we use the I915 driver for the kernel and the various HAL components are the Lib DRM, the DRM Graloc and the hardware composer. The cool thing about this is that the entire graphics stack is open source, following Mesa. There aren't any proprietary binaries being distributed.
Now that you guys have an overview of the key features added in Android Things, what is it that you could do out there to get started and start playing and writing Android applications? The first thing you would do is go to this site and download the images based on which device you have. We have links for these at the end, and resources too, on the resources slide. On this page you'd also find the images for the other non-Intel supported platforms like Raspberry Pi or NXP.
Once you have downloaded this image and you have a Joule or Edison module, right now I'm using Joule as an example, you'd also need the following hardware. You'd need a micro-USB cable, a USB type C cable, a power adapter, an HDMI cable, and a microSD card reader.
Whatever image that you obtained in this link, in comes with a fast boot disk image. All of these instructions are actually there on the side. I'm just walking you guys through it so that it's easier for you guys once you do get started doing this.
So you flash that image on the microSD card and hook it up to your Joule device. Before you do that, you would also need to update the BIOS on your device, and there's links for that too, in the instructions page.
Once you have the image on the SD card and you have the BIOS updated, once you power on your device by connecting the power cable and connecting your host to the USB type C cable, and you can optionally hook up a USB keyboard in order to interrupt the BIOS.
Once you have that, you would enter into fastboot mode. Basically, fastboot mode is a requirement to be implemented for all Android devices, where you can enter and basically flash your device. So you would enter fastboot mode and follow these instructions. All of these images are part of that initial zip file which you guys downloaded. You can obtain ADB and fastboot from the Android SDK.
So what do you have once you run this command and run fastboot reboot? You would boot into Android Things, and this is how the Android Things startup looks like. You can see a cool reflection of the Joule here. Once you have that hello-world experience, you're able to bring up your Android Things device. Google provides you with a few code samples which you could use to get started and basically play around with the device.
My colleague, Sanrio [Alvares], who's in the audience now, is going to be delving deeper into the code. But what I'm going to be showing you guys is just how to flash, build, and install the application and how to actually get the app started.
The hello-world example which I'm going to use is very standard to IoT, is like blinking an LED. This is from Google's sample code. It's called SimplePIO and I'm going to be explaining the Blink application. What you need for this is Android Studio running at Android API level 7. We have links at the end for the sample code. You'd clone the code and import it to Android Studio. The hardware that you need is in addition to the Joule and the cables, which I mentioned earlier. You'd need an LED, a resistor, two jumper wires, and a breadboard.
This is the connection that I've made. Basically, this is ground, and this is a GPIO which flows through the register, I mean which is connected through a resistor to an LED.
Once you have the app, this is a sample, so you're not going to be making any changes to it. You'd basically open Android Studio, press Run. Or if you prefer using the command line, you'd run gradlew blink: installDebug.
What this does, it doesn't start your app already. It builds and flashes that app onto your device. Once you run "ADB shell am start" and start your activity, your activity is brought to the foreground, and then you can see that LED blinking.
I hope you guys got a good overview of Android Things and how to get started with Android Things. Basically, an important thing to note is that with this framework, you already have so much experience and so much [inaudible 00:28:42] in the community about Android applications, so it would be very easy to get started writing Android Things applications. I hope you guys try it out and start playing, contribute to the forums.
Thanks a lot. Any questions?
Speaker 1: Can you go onto the security site [inaudible 00:29:10]
Anisha Kulkarni: Sure.
Speaker1: The OTA that would replace [inaudible 00:29:23] kernel or also for the application?
Anisha Kulkarni: It would also be for the applications.
Speaker 1: Then the application has to be in the store.
Anisha Kulkarni: Basically, the BSP or the OEM would provide the image back to Google and they would push it onto the device. That's the relationship we have right now with Google. We send them our BSP and they push it across.
Geeta Krishna: It'll be part of the OEM partition.
Anisha Kulkarni: Yeah.
Speaker 1: But those will be [inaudible 00:29:57] sign by Google?
Geeta Krishna: Yes.
Speaker 1: Even the ... Okay. That's interesting.
Speaker 2: Is Trusty OS open?
Anisha Kulkarni: Yeah. Yeah, the source is open.
Speaker 2: And how much of that is different from Linux?
Anisha Kulkarni: Trusty OS? Linux's TE...
Speaker 2: [crosstalk 00:30:28] totally different [inaudible 00:30:31]
Anisha Kulkarni: I'm not sure I get the question.
Speaker 2: Trusty is a separate domain, right?
Anisha Kulkarni: Yeah.
Speaker 2: It has its own operators, right?
Anisha Kulkarni: This is a little kernel. It's not the Linux kernel. It's a stripped-down ... The kernel which Trusty uses is called little kernel. How different is it from Linux? It's much more lightweight than Linux.
Speaker 2: Okay, I'll take a look at it.
Anisha Kulkarni: Yeah.
Speaker 3: Going back to the updates of the [inaudible 00:31:11] the application, you send everything to Google, and then they update [inaudible 00:31:18] update the OS by themselves [inaudible 00:31:22] update you will send the images. Are these two updates separate, or is it a single update? Can you update the applications separate from the system image, or is it just single monolith thing that gets updated? That's part A of the question.
Anisha Kulkarni: Okay.
Speaker 3: Part 2 is, if I did want to deploy a new application, I could potentially add it to the image, push it to Google, and then I could have, let's say I had two earlier and now I can have a third application. Is that correct?
Geeta Krishna: We don't know the details of that yet. They have not been disclosed, how that's going to work.
Anisha Kulkarni: Yeah.
Speaker 4: You mentioned system on module before. Is the intent that Android Things is only going to support SOMs, or is it going to be available for tighter integration?
Geeta Krishna: For high volume, Google will be open to working directly for the vendors. There's also a concept of having some open source design that you can flatten out onto your board. But it's basically going to be SOMs.
Speaker 5: If Google is providing to us [inaudible 00:32:34] update image, does that mean that as a device manufacturer, I can no longer make custom changes to the kernel or the HAL layers in Android?
Geeta Krishna: No, you can provide those as APKs.
Anisha Kulkarni: No rights.
Speaker 5: If it's changes to the kernel [crosstalk 00:32:50]
Anisha Kulkarni: Oh, the kernel itself, yeah.
Speaker 5: It's in the system [crosstalk 00:32:54]
Anisha Kulkarni: How it's been working now is we send updates, whatever changes we have, we upstream it to them and they push it across. [crosstalk 00:33:09]
Sanrio Alvares: To elaborate on that point, the SOM [inaudible 00:33:13] whatever is in the SOM, it's controlled by Google. They want to control the kernel, the HALs and the framework. So what that means is they're going to send the package [inaudible 00:33:24], sign it too. So you cannot add a driver to the kernel unless Google accepts it, and you will have to do that through Google, even anything that is on top of the framework: user drivers, applications. Those are things you can install. Another thing is they have separate keys for OEM applications that the OEM will sign using Google cloud, but it's a separate key. So the OEM can install that on the device, so the device is meant to do only one thing here. So one application can be meant for one thing, one kind of device, another application for another. So it's signed by OEM [inaudible 00:34:10], but it has to go to Google cloud for now. I think there is scope to do it with [inaudible 00:34:17] that's not tried yet, but for now it's only Google cloud to which you can [inaudible 00:34:22]. Does that answer your question?
Anisha Kulkarni: Yeah.
Speaker 3: I'm still not clear on this whole process of [inaudible 00:34:36]. Let's say I have an app. So if you say, you send the DSP to Google, but then as an independent developer, am I going to send it to Intel to send it to Google? [inaudible 00:34:48] work for you guys. You have a scale issue. We don't want to be the ...
Geeta Krishna: Yeah.
Speaker 3: So there has to be a direct way that a developer who uses the BSP from Intel, which went to Google and got signed, it has to be some flavor of an app store. Maybe not the ability to download on [inaudible 00:35:10], but the provisioning has to be very similar to what happens on Android. Anyway, you should have clarity on this, and I know you published a whitepaper or something [crosstalk 00:35:19] because it's going to come up over and over again.
Sanrio Alvares: They haven't done any work on it yet. We haven’t seen any documentation on how they're going to do it. It's still a developer preview, and it's just the second one that's come out. Things are changing a lot even some [inaudible 00:35:35] they've added.
Anisha Kulkarni: Yeah, all of this is still in a developer preview stage. In fact, on Android Things, OTAs have not yet been enabled.
Geeta Krishna: Yeah, there's no OTAs, there's no Weave, so right now it's in a very nascent stage.
Sanrio Alvares: The good part about it is they have promised a release every six to eight weeks, so this really is coming pretty fast. It would be a good time to get involved.
Geeta Krishna: Yeah, you can have discussions on the stack overflow or the Google forum.
Speaker 6: So if I am I understood this correctly, Android Things is not for constrained devices. Is that correct?
Geeta Krishna: The Weave is, but yeah, Android Things itself will not run on MCUs. It will run only on MPUs. But the Weave library you can put on a device, and then it will become a Weave device.
Speaker 7: But the Weave is not [inaudible 00:36:42] independent?
Geeta Krishna: It's implemented as a library, a set of APIs.
Speaker 7: So the URS [inaudible 00:36:51] can be any ...
Geeta Krishna: Can you repeat please?
Anisha Kulkarni: Yeah, you can run it on any OS. It's supposed to be ...
Speaker 7: [crosstalk 00:36:58] and put Weave on that, is that correct?
Geeta Krishna: Use it as what? Zephyr, oh. I'm not sure.
Anisha Kulkarni: Yeah, but they say that Weave is supposed to be OS agnostic.
Geeta Krishna: Weave also, the full version is not there. That's also just been announced. There's a small library which implements the device APIs, but the rest of it is not there yet.
Speaker 8: [inaudible 00:37:48]
Geeta Krishna: Yeah, that's changed. There is a Weave website. If you go there, it tells you more details. Right now there's just one library which is called libIOTA.
Speaker 9: You mentioned some other platforms other than [inaudible 00:38:05]. Can you say what they [crosstalk 00:38:06]
Anisha Kulkarni: The Raspberry Pi and NXP Pico and ...
Geeta Krishna: Argon and Pico both.
Speaker 10: [inaudible 00:38:25]…the security monitor, the hypervisor, for Intel. Is that open source?
Anisha Kulkarni: No, it's not. It's not open source. All right, thanks a lot.
Geeta Krishna: Thank you.
END
Learn more about Android Things on Intel Architecture.