 I hope you're all having a great time in DroidCon. Today I'm going to talk about Brillo and Veef, the title says, the next thunderstorm. Let's see if that gets justified at the end of the presentation. A bit about myself, I work with a company, TechGenie. We do a couple of cool stuff over there, one of them is what I'm going to present today. Let's move on to our agenda. We're going to understand what the ITU space is about. We have been hearing a talk a lot towards Android Centric. This is also something related to Android, but it has a lot to do about IoT and based on IoT OS and the communication layer. We will understand the overview of Brillo and Veef, which is Brillo as an operating system and Veef is a communication layer, followed by what security protocols are coming along with it, down the line what developer tools have to offer us as a platform, and then we'll see what we have learned out of there. IoT is basically, in general, it's like whatever we interact with day in, day out, a car, then could be a bulb, your thermostat, stuff like that. Basically, when we talk about IoT, we want to focus, especially from the perspective of Brillo and Veef, we want to focus towards a set of devices, from the category of human augmentation, then towards the robotic side of it, where we discuss about how we can put and for Brillo and Veef to robot devices and stuff like that. Then obviously the enhanced objects, this is where the lot of cool things are happening around towards the refrigerator, washing machines, microwaves, you have a home and day in, day out tubes. What's the scope and advantage of it? With a very simple example, I want to brief it out and we'll try to understand it in that way. Let's say if I go out and buy a printer and I come back home, first thing I need to do for the setup is I have to figure out, do I need to insert a CD, DVD, or do I need to go to a certain link to download a driver so that the printer can start walking? This leads to a heckle in the user experience of the particular product. What we are expecting with the IoT and how it's supposed to work is, especially with Brillo and Veef, the moment you come down with a particular new product, which is based out of the IoT platform, you may get switched it on. It directly interacts with your mobile device, which is Android based and automatically figures out the Wi-Fi setup, it consumes it, then picks the password, which is there, and download a particular driver, which is required for it. This happens with a hardly two clicks or three clicks on set of a mobile application, which is configured for that setup. This kind of experience, we want to bring it along on certain other set of devices as well, and this is where the IoT is going. Now we'll talk about more for Brillo and Veef. What Brillo is, let's focus on that. It is an embedded system, which is an operating system, it's a stack of software, we'll see down the line. Similarly, like what you have seen in Android, something of that is stacked, but we are using a couple of things, and it still is a lot more different from what Android is. So again, it provides as a combination, since Veef is a built-in support with the Brillo, it provides end-to-end support for any Brillo and IoT-based devices. And let's say, if I take an example of a bull, it's like an IoT-based. And today if you see in the market, there are a couple of devices which are available, which works in certain this way. But what happens at the end of the day, every manufacturer has their own set of either OS or some firmware, which is doing this job. It's not common in line, it's not center-aligned. And that's where the focus of that particular platform is going to be. In this Brillo picture, if you see just a use case, if I want to bring it along, you have LED bulbs in your home, and at some point of time, just want to change the light color, you can be able to do it if it's an IoT-based device based on a click on a mobile. That all can happen with the help of the Brillo and Vee's set up that comes along. Let's focus on what Brillo is inside part of it. The first one is about the Android-based OS. Then we'll talk about the core services followed by what security is coming along with the Brillo system. This diagram must have, everyone must have visited a million times. But this is the new one. This is what Brillo is about. We have used from the same Android setup a couple of things, which were there in the native setup and try to reduce and remove all the Java kind of stuff along with that using the Linux channel and the Brillo the same setup. In detail, something it looks like this. You have a user space on top of it, followed by a product-specific code. When I say product-specific code, it could be like today Honeywell is coming along with some thermostat. They can fix their own setup. Tomorrow LG is coming with something and they want to do something with their specific to a certain range of AC. They can do figure out in that particular product-specific code. It has a connectivity metric crash. Now, that's a very important part. Whenever we launch any device, we want to see the behavior of it. And that is what we calculate out of that metric crash and we'll see in detail what it is. Set-up ports are available by Intel, couple of other manufacturers, including MIPS, Qualcomm. These boards are very much ready and any new device that you want to, which you are building or any particular manufacturer is building, or for a test purpose you want to play around, the board can be set up easily into your device and you can configure it. Currently, there are already existing devices, a lot of them. Like one of the example I talk about was thermostat. Now, what will happen down the line? Similarly, the trend you have seen in Android, either the couple of manufacturers started accepting the Android OS, or kind of they were out of the market. Similar kind of trend you will see down the line with Brillo and Veeve. The manufacturers are going to adopt this model and it provides a direct support from the Google, and it can be adopted by any third party existing IoT device. It has a built-in support for Veeve. Veeve does a job of communication across devices. If you have 10 devices in your home, which is Brillo and IoT base, the Veeve will take care of it communicating with each other. In the next level of core services, we'll understand more about the metrics and crash reports, then Veeve and what the OTA update has to offer. Metric and crash reports, basically whenever you launch a product, we want to understand how the product is performing over a period of time. And with that, we want to understand what kind of user behavior that device is coming across to and what kind of scenarios in which the device is not able to perform. Those things come under metrics and crash reports and can be easily tracked in the Veeve developer console where the manufacturer can take the business decisions what needs to be done around it. When we talk about IoT, definitely nobody wants to fall into this situation. It also logs to a doc feeder and where it comes like, who is not there? Moving on to the security part of it, it has enhanced Linux approved. That's whatever boots we release, like over a period of time, one form we are already existing on an IoT device, which is there in the market and users are using it. Tomorrow if I figure out, I need to modify it and I update it. I again can push the particular firmware which is very authenticate signed by the manufacturer and it handles the security part for it. The AB updates are there. What do we handle by the AB updates? It simply means in terms of IoT is, let's take an example of a washing machine. There's something or a microwave. It's continuously in use or your AC. Now what happens is you don't want any other thing to get interfered into it and this device is stopped and you can't use it for a longer time. So what happens is whenever is there new update of the firmware is available on one side, whenever manufacturer pushes it, it comes as a OTA update in the sideline. The new version of the firmware gets downloaded. Once the complete download is happened and next to start of that device takes place, then only the changes will reflect and new firmware will start working. So it does not interfere with the working of the current setup. User account controls, very much important thing in your IoT device where you are, let's say, home appliances. I don't want to give a full control of, I have four devices to my tenants as well. Could be a washing machine and microwave. I don't want to give access of microwave to my tenant for some reason and washing machine, I still want to make it available for all the people in the house. So these kind of thing, how they can access, like they can check on their mobile, whether it is available or getting used by someone, can be achieved easily with the help of user account controls. You can define the rules and the permission and access levels, what kind of action they can perform in this. The data communication which happens across these Veeve and Brillo-based devices, it is transparently secured and cryptographic secured has been implemented into it. Talking about the Veeve, which is heart of the Brillo, which helps in any point of communication that takes place, it helps linking device and it could be one device or two devices. Now think of a scenario where, let's say, on your mobile phone you are reading a recipe application and you're reading about some pizza recipe. Now what happens is, let's say you flip over some pages and you're showing interest into this particular recipe. The application automatically figures out that you are interested into this recipe and think about a scenario where it issues a command to your microwave to get set ready on a particular temperature which is required for that. So this kind of imagination and this kind of achievement we are trying to achieve with the help of Veeve and Brillo-based devices and the tested couple of devices is already been there which is inside Google. It has not been officially known at this point of time. Common way of communication helps removing any product-specific thing. So as an independent developer, I am developing a particular application. I don't need to be in a particular manufacturer's domain to understand what commands their particular set of device can understand or cannot understand. As an individual, I can define an application and user has a choice to use. They are not bound to use only an application which is issued by a manufacturer. Third is about the authorization. Whenever any command gets issued, it is authorized. We check what kind of account it is being used and are you permit for that action which is you are issuing to that particular set of device. The very important part out of Veeve is it takes care of the communication and it helps doing it fast. So the user at the end of the day does not need to figure out whether the local API will do the job or it has to go via cloud. Are you in your home in the local network or you are traveling somewhere or at your office? What it helps at the end of the day is the basic things. Since it's an embedded device, a small chip gets printed into an LED bulb, your AC, something of that sort. It helps doing discovery of a device, helps it provision it and finally do the setup out of it. Which very much do a catalytic thing for a user experience of that particular product. Basic set of commands that goes around could be checking the state of a device whether it is available or not available. Somebody else is using it at this point of time. It updates a particular device could be based on a command like switch on the light, switch off the light, whether the light is on, whether the machine is still running. Seeing the device state back to the mobile application. So the user who is actually going to use the or issue a command, they know what kind of state of the particular device is. The protocol is implemented to device side libraries. What I'm talking about is Veeve SDK which is available for mobile developers like us where we can develop applications which can issue commands and these commands will be common in nature. So even I can figure out an application which can handle a different set of devices which is built by third party manufacturers. This is a particular link it's there where you can request and invite down the line since it's not open for all at this point of time. This kind of which I have put across just to give you an idea how the Brillo boards look like. These are the manufacturers currently who have tied up with Google to provide these Brillo boards. Many more are in the pipeline and they'll get what are the developer tools available with Brillo and when we talk about it. Veeve developer console is there which helps you do the device metric part. You can analyze the behavior of a particular device as an IOT how the device is reacting, what is the performance. You can test your new set of devices. Let's say I'm building a new device and I want to check how does it perform with Brillo and Veeve. How does it perform in a production environment. All that thing can be happened and can be tested with the help of Veeve developer console. This is a command line interface which is available. People who wanted to do and go through it run a script particularly to do automation testing of that sort that can also be happened with the help of command line interface that's available in Veeve developer console. One of the examples there are not much thing around it and my personal believe is that if you remember the presentations if you have attended in 2009 and 10 or 8 where the android started coming into it. If you are talking about the structure then from that time to this time we have come so long and we have seen the kind of bold thunder that it comes along with it similar kind of thing you can figure out when you see this example. It is a very beautiful example it has something to do with the LED bulb where it issues a command request things and again syncs back. Quickly go through what we have figured out today in quick session that is what is the IOT what scope it has to offer you. There is something very premature at this point of time when we are bringing it up on the table but that is going to be the next thing Brillo and Veeve as in like the system which is going to change the world if you will see you can imagine anything the next level how you can take it to android Veeve helps you even to further go one more step ahead and do something about android variables as well there is also something in that space is happening around. Our developer tools we have understood about Veeve developer control particularly you can start with Brillo and Veeve by checking out that particular example and you can definitely request and invite that is my contact these are the two links important and for Q and A I think he wants to ask some questions Can we use this in android studio or in eclipse In android studio ID you are saying Yes Yes down the line it will be open you can use the plugin there is the idea of providing a plugin which can be used within your android studio and generate a build out of it but at this point of time nothing much is there in the outside world so you can't have access to docs So they do have a different ID for this thing At this point they don't have the direct different ID the idea is later they want to somehow make it aligned with android set of things so it could come with android studio In android studio do I have to add this SDK or it comes So currently actually it's not available directly you'll need to request and invite and when you request and invite you'll get a SDK set up with you and once you get that you can start integrating like any other library and build your application So to whom I need to send the invite The links which I showed just these ones on the Veeve you can go on this particular link and request and invite Now you talked about the Brillo development boards being available by Intel So I just want to know how interoperable they are with other development boards like How? How much interoperable they are with other development boards like Arduino or Raspberry Pi What happens is when we are using a particular Brillo board as of now what I know about it with any particular set of device which you have otherwise can also be portable if there is already an operating system you'll only need to portray the Veeve part of it but if there is no operating system we are currently existing with that IoT device then you can use the complete board What is the advantage of? Advantage of running an android on a development board instead of a normal embedded Linux We are still running Brillo, it's not properly android It's not properly android right? Based on android few things that's a native part of it and the advantage of it is because it is designed in a way because it has a built-in support hand in hand with Veeve which can easily communicate to all set of android devices that's where the scalability comes into picture whereas if I use the direct hardcore Linux thing as an embedded OS I'll need to provide a certain SDK which will only communicate to a set of device Coming from a Google background this will have more scalability as having a particular Linux. Any more questions?