 Thanks for coming to our Android Things talk. My name is Keeta Krishnan. I manage the core-enabling team of 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 AM in the same room by Senrio, 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. So 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. So 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 Runtime plus Android Studio, which was missing in Brillo. Another key difference is that the deployment model is very different from what Brillo was. So 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 the sensors and actuators through APIs and industry standard protocols like GPI and I2C, a developers console, which helps register the device and control it, metrics and analytics for monitoring and maintaining the health of your fleet of devices, Veeve, which is an open secure communication protocol between the device and the cloud, Six Lowpan and Threads low-power network protocols. It also supports AV-style OTA updates, which allows for the update to happen on an alternate partition and features a 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 2 to 3 gigabytes. As I mentioned, it's a fairly new OS. The first developers preview was released two months back in December, which featured basic OS functionality and support for four developer boards. The second developers 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 is committed to providing developers 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 the Google Plus forums. So as you can see, there's quite a few key features that's still missing from Android Things and will be in future releases. One of them is Veev, which is the communication protocol between the device and the cloud. So Veev is the secure open communication protocol from Google. It provides for IoT developer console, which you can use to register the device with the Veev server. It 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 Veev tries to address is the issue of device interoperability. So 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 you familiar with Brillo, you would remember that Veev was an integral part of the OS. For Android Things, it has been decoupled 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. A few attended Imard'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 Veev is the preferred protocol. In fact, if you go to the Intel Showcase upstairs, there's a demo rear running Edison-based tube box, which based on Android Things and being controlled by IoTivity. So 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. So 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. We've 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 model 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. So 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 bias, 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 board support packages. OEMs or the device manufacturers will provide the help for the sensors and actuators and also provide the applications that provide the differentiation to their device. So this works pretty 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 train releases long term. They will be supporting multiple OS versions at the same time and the devices can get security updates for these OSs 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. So the boards, I based board supported on Android Things. There are three of them which are based on Edison, the Adreno board, the SparkFun blocks and the mini breakout board. The developers preview two also added support for the dual compute module which is one of our high end compute module. It also features a GPU and we have enabled the graphics stack for it as well. The other boards supported are Raspberry Pi and a couple of NXP boards. We have the Intel boards here for you to play with afterwards and also some of the sensor kits that have been developed for them. So in summary, Android Things makes the development for IoT simplified and also accelerates it. So you choose a prototype developer board which meets the needs of your product both cost-wise and technology-wise and 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 architecture. Thanks, Geeta. My name is Anisha and I work in the Android Things group. I've been working on Android from 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 and probably and also compare Android and Android Things. I'm gonna leave you guys with a few steps on how to get started building applications on Android Things. So what does the Android Things stack look like? This is a figure of the Android Things stack and 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 hell to talk to your graphics driver from the Linux kernel. So 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 that is 7.0, which means you can write Android applications at end desert for your IoT devices. So also in addition to the Java API framework, we also add the Google services. Google provides you with a Think 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 Think Support Library. So another key difference from Android is that OTAs are received directly from Google. Earlier in Android, that was not the case like the BSP provider would have control over the, 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. So what's the difference is that Android Things does not come with a set of pre-built system apps. So basically when you have your Android phone, you have the calendar app or an email app which come by default and Android Things does not have that. And also there's no concept of content providers. You cannot communicate from one application to another using content providers. And 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 too and all of the security features have not yet been enabled. So 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 as the home activity, which you 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. So the whole user experience is meant that 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. So I mentioned about the Think Support Library. So what does an IoT developer want to do? Mainly he wants to be able to program sensors and build cool apps using sensors and actuators. And 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. So one of the key concerns or challenges in IoT devices is security. And although Android Things is a fairly new OS, it borrows a lot of maturity from Android. So you would basically be running with the same level of security that your Android device which is running and as Nougat would be running. I'm going to walk you guys through a few of the security features that the Android Things Google, basically Google requires Intel to implement. So whatever kernel your Android Things device is running has to run with SE Linux enforced. So in addition to the DAC policies which the Linux file system has, you'd additionally be enforcing mandatory access policies through SE Linux enforcement. So that covers the kernel level security. In addition, Google introduces two of the key concepts for hardware backed security. So 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. So 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 the kernel image which it's trusting. And then right up to the system, the OS image, you have this cryptographic chain of trust. Also introduced in Android is the Google Android trustee. Trustee OS is basically Android's trusted execution environment. So what is a trusted execution environment? When you're running, when you want to do few secure operations, you would want the main OS not to be able to access these resources. So this is why you would run either using a secure processor or a virtualized environment. Google actually provides a reference implementation for trustee which is based on ARM and is called trust zone, but Intel has its own solution for the trusted execution environment. Here's a stack of Intel's solution for trustee. 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. So as you could see, when you run with trustee OS enabled, both Android OS and trustee OS run as guest OSes on a secure monitor hypervisor. Google provides you trustee drivers which are added to the Linux kernel in order to talk to trustee OS. So basically it's very similar to just starting an IPC and communicating and Android OS passes across messages to trustee OS. Also provided by Google are the trustee libraries which help us for the various apps in order to call into trustee. So how is trustee OS given this hardware root of trust? So there's the following sequence of events which happen to pass the trustee root key from the hardware using the CSE. So CSE is a consolidated security engine which basically is a secure entity which who 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 trustee root key and the bootloader passes the trusted root key from the CSE to trustee OS. The communication from the bootloader to the CSE happens by a protocol called HECKE. And once the trustee root key is in trustee it's used by trustee for various other trusted apps like basically that's the master key from which keys for other apps like Keymaster, Gatekeeper, et cetera are used. So what is an application of the trusted execution environment and when would you use it? Suppose you have a very common example is that of DRM keys. You don't want secure content to be, anyone to be able to steal your secure content. So all of the encryption and decryption, the key, basically the DRM keys are stored in trustee and all of the encryption and decryption happens in trustee. So all of that data is never stored in the memory of, in the Android memory. Another example where you would use trustee is for full disk encryption. With the introduction of the Java API framework also came the enablement of the graphics stack on Android Things. So the graphic stack for Android Things from the AOSP perspective is exactly the same as that it would be for Android. On the Joule module we have enabled both 2D and 3D apps. So 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. So you have your hardware and we use the i9-15 driver for the kernel and the various HAL components are the lib-drm-drm-graloc and the hardware composer. So the cool thing about this is that the entire graphic stack is open source following Mesa and there aren't any proprietary binaries being distributed. So 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? So the first thing you would do is go to this site and download the images based on which device you have. So we have links for these in the end and resources too in the resources slide. So on this page you'd also find the images for the other, the non-Intel supported platforms like Raspberry Pi or NXP. So once you have downloaded this image and you have a Joule or Edison module right now I'm using Joule as an example. So 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 micro SD card reader. So whatever image that you obtained in this link it comes with a fast boot image, fast boot disk image. And all of these instructions are actually there on the site. I just thought, I mean I'm 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 micro SD card. Micro SD card and hook it up to your Joule device. So before you do that you'd also need to update the BIOS on your device and there's links for that too in the instructions page. So once you have the image on the SD card and you have the BIOS updated the first thing 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. So once you have that you would enter into fast boot mode. So basically fast boot mode is a requirement for to be implemented for all Android devices where you can enter and basically flash your device. So you would enter fast boot mode and follow these instructions and all of these images are part of that initial zip file which you guys downloaded. And you can obtain ADB and fast boot from the Android SDK. So what do you have once you run this command and run fast boot 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 jewel here. So 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. So my colleague Sandhria 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 starting. So the hello world example which I'm going to use is very standard to IoT is like blinking and LED. So this is from Google sample code. It's called Simple PIO and I'm going to be explaining the blink application. What you need for this is Android Studio running at Android API level seven. So we have links at the end for the sample code. You clone the code and import it to Android Studio and the hardware that you need is in addition to the jewel and the cables which I mentioned earlier you'd need an LED, a resistor, two jumper wires and a breadboard. So 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. So once you have the app, this is a sample so you're not going to be making any changes to it. You would basically open Android Studio, press run or if you prefer using the command line you'd run gradle w blink install debug. So what this does is 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 could see that LED blinking. I hope you guys got a good overview of Android things and how to get started with Android things. So basically an important thing to note is that with this framework you already have so much experience and so much word in the community about Android applications. So it would be very easy to get started writing Android things applications. So I hope you guys try it out and start playing, contribute to the forums. And yeah, thanks a lot. Any questions? It would also be for the applications. So basically we will, the BSP who is or the OEM would provide the image back to Google and they would push it onto the device. So that's the relationship we have right now with Google. Like we send them our BSP and they push it across. So it'll be part of the OEM partition. Yeah, and the OEM. Yes. Yeah, the source is open for trust. Trusty OS. Linux is T. I'm not sure I get the question. Yeah, it's, yeah, so 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. The image or is it a single monolith thing that gets updated as part A of the question? Part two is if I did want to deploy a new application, I would potentially add it to the image, push it to Google and then I would have a, let's say I had two earlier and I now I can have third application. Is that correct? We don't know the details of that yet. They have not been disclosed. How that's gonna work. So for high volume, Google will be open to working directly for the vendors. And 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 Psalms. Now you can provide those as APKs. No, right? So the kernel itself, yeah. It's in the system. Yeah, yeah. Like how it's been working now is that we send updates, whatever changes we have, we upstream it to them and they push it across. Yeah, salary and all that. So 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. So the device is meant to do only one thing here, right? So it can, one application can be meant for one thing, one kind of device, another application for another. So it's signed by OEM, I think, but it has to go to Google Cloud for now. There is, I think there's scope to do it with Google on the system, but it's not signed yet. But for now it's only Google Cloud. Yeah. So I'm still not clear on this whole process of ODA. 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? So that's gonna work for you guys, right? You have a scale issue. You don't want to be the... Yeah. So it has to be the right way that it's a developer who uses the DSP from Intel, which went to Google and got signed, which there needs to be, it has to be some flavor of an app store, maybe not be able to download on there, but the provisioning has to be very similar to what happens on there. Anyway, you should have clarity on this and then maybe publish a white paper or something. Yeah. It's gonna come forward over again. Yep. They haven't done any work on it yet. Yeah. I haven't really made any documents on how they're going to do it. Okay. So it's still a developer preview. Yeah. All of this is still in a developer preview state. And in fact, on Android, things OTAs have not even, not yet been enabled. Yeah, there's no OTAs. There's no Veeves. So it's, right now it's in a very nascent state. Yeah. There are the, you can have discussions on the stack overflow or the Google forum. The Veeve is, but yeah, Android thinks itself will not run on MCUs. It's, it'll run only on MPUs. Yes. But the Veeve library you can put on a device and then it will become a Veeve device. It's implemented as a library. So set up APIs. Can you repeat that? Yeah, you can run it on any OS. Any OS? Yeah. It's supposed to be. Use it as what? Zephyr. Zephyr. Oh. I'm not sure. But they say that Veeve is supposed to be OS agnostic. Veeve also is the full version is not there. That's also just been announced. But yeah, there's a small library which implements the device APIs, but rest of it is not there yet. Yeah, that's changed. So if you go to the Veeve, there is a Veeve website. If you go there, it tells you more details. Right now there's just one library which is called a bio TA. The Raspberry Pi and NXP, Pico and Argonne. Argonne and Pico both. Argonne, yeah. No, it's not. It's not open source. All right, thanks a lot. Thank you. Thank you. Thank you. Thank you.