 Good afternoon, everyone. My name is Karim Yagmour. And I will attempt to go through 60 slides in 50 minutes. That's right. Been there, done that. Before I go anywhere, let me just get a feel of the room here. So please raise your hands for the following questions. Who's got any sort of embedded Linux experience? Cool. All right, that one's at the door. Android platform experience. Cool. Any people here played with the Brillo? A couple? All right. Anybody played with Android Things? Cool. All right, you're probably in the right place. iOS, right? OK, I will put these slides up afterwards. Don't bother looking for them. They're not yet up. OK, so in case you don't know my background, I wrote the embedded Linux book for Riley way back when. And a couple years back, I wrote the embedded Android title, most widely known for having written the Linux Trace Toolkit and maintaining it for a couple years. Fortunately, some other people, including Steven here, have been doing a much better job than I was at tracing. And it's in good hands. So I'm happy not to take care of that anymore. And if you grip the kernel sources around, you'll find my name until somebody finds that what I wrote has bit-blotted and then takes it away, which should eventually happen. And whatever, when I'm not doing these lectures and playing with funky stuff in kernel and Android and elsewhere, I'm helping customers do all sorts of weird things with Android, which gets me into these kinds of interesting presentations. I am not directly involved with Android Things. I was, in a past life, involved in a modular phone project with Google. But Android Things is not one thing I'm participating in, which is cool, because that means I can say whatever I want. And so I will try to take this conversation into different directions. So one obvious caveat is Google has not yet released the sources for Android Things. So everything that you see here is really just based on my perusal of the binary releases that they have made. And I will try to take a few minutes to just show you around and point out differences with the mainstream Android and such. OK, so let me start with just a bit of background here and try to take this out of the way quickly, because as I said, I've got plenty of stuff to show you. So first off, if you try to define embedded Linux, the best I've come up with, even though I wrote a 400-page book on the thing, is that it's set up ad hoc recipes for creating essentially a file system around the Linux kernel. I mean, that's pretty much the thing that you can nail it down to. And then you can say, well, there are some usual suspects. Usually you'll have U-boot. Usually you'll have busybox or whatever else that you care for, the GNU tool chain and some other stuff like that. But usually it is up to the system designer to decide what goes into the Linux system. And obviously, people have created packages to make this simpler. Yachto, Buildroot, you name it, OK? So when, say, I left the scene of embedded Linux in the mid-2000s to go pursue some startup that I was interested in, the one thing that was lacking with embedded Linux was a serious UX or UI. There just wasn't anything out there that was the standard user interface. And Android kind of solved that to a very large extent. It is a very rich environment, both for users and developers. And the nice thing that Google has done that was not possible in the embedded Linux world is they've standardized an API. And they maintain that in time. And they maintain it in a coherent fashion. And if they have to essentially take some things out of the API, then they advertise that ahead of time. And then seamlessly walk people through to the exit. And they have made a number of interesting contributions to, say, the embedded world in general. ADB, I think, is my favorite. So you could do similar things than ADB before ADB with, say, SSH. But it's a bit heavy, all right? ADB kind of just makes it really simple. Here, I've got my, say, Nexus 9 here plugged into my laptop over a USB cable. And I can shell into it with ADB shell. Some trivial stuff, OK? And really, the key here is the development environment. It's really, really easy to get started with Android development. And there are a tremendous amount of developers out there. And I guess I don't need to necessarily show you this, but I kind of like just to market share of Android versus other stuff out there. It's just eating the entire pie. So people will counter argument and say, well, no. But Apple's actually making a lot more profits than these other whatever vendors. OK, so what? The number of devices out there that are running that specific operating system are way much more than anything else out there, OK? By the way, I get better as I get questions. This is easy stuff. But you're welcome to interject at any point. So this is a bit of a funny kind of picture I put together for presentation I did at the Android Builders Summit in 2012. And I had actually headlined it with some quotes from Quentin Tarantino. But interestingly, so the story behind this is before I made this talk, I had a customer come to me and say, hey, we'd like to run Android on a headless system. And at first, I thought this was hilarious. I was like, really? Seriously? If you want to run a headless system just for go Android, go with Embedded Linux. It does the job. And they said, no, no, no, we want to have Android. And I said, OK, well, explain that to me. So there are two reasons that he wanted to go with Android. The first one was they have multiple platforms. Some of them have a user interface. Some of them don't. And they did not want to have to maintain three, four different operating systems. They wanted to standardize on a single operating system and use that as their core thing, which is pretty good. And the other thing that he mentioned is that if he was going to use Android, then he could essentially get any app developer off the street and have them start coding for their embedded system without that developer needing to know anything about Embedded. And those are pretty compelling arguments from a business perspective for adopting Android, even though you might not have an actual UI. Now, back at the time, there was nothing that Google was doing in this area. So you can go look at my slides. I kind of went around and trimmed out the surface flanger, shut the window manager off and played around with a bunch of things, destroyed the crap out of it. But it worked. I was able to get the thing to boot and actually start stuff. Now, six months later, I was doing a presentation at Lenaro Connect Copenhagen remotely. And somebody in the crowd said, hey, have you checked out the RO Config Headless flag? I was like, no. I don't know what that is. And so in the interim, between my first presentation and the second one, Google had come out with the Nexus Q, which maybe some of you don't recall, but there was this like, Spheric thing, which was a multimedia player. It wasn't really a big commercial success, but it was essentially running some kind of form of a headless Android. So there was at least, starting at that point, some interest within Google to actually take a look at that. And that flag remained in the stack for a while. I haven't checked recent versions if it's still there or not. But essentially what it did is it essentially disallowed you to start activities. You just couldn't start activities. You could do pretty much everything else, but not activities. All right? Now, at some point later, they came out with Brillo. So they announced Brillo, and I was there at Google IEO, and they started sending you a slash, oh. Click, click, click. What the heck's this? And so they never really officially released it. It was always just a developer preview, but they did put sources out. So you could actually download this thing and start using it. And the way it worked is it actually was having applications stalked through the house directly to the hardware. So there was no, as I'll show you in a few slides here, traditional separation of privilege between applications and system services. It was just straight load the sensors how and start talking to your sensors if you want to do that. And then you can connect that over weave to some cloud infrastructure. And just late December, essentially, or mid December, they announced Android Things, which is the successor to Brillo. And whereas I'll show you with Brillo, they stripped away the entire system, and they only had the native layer with Things. They're bringing back everything again, including the privilege separation of applications from regards to services and the core infrastructure, and so on and so forth. You can still use C&C++ programming, but it is the standard route, which is NDK. So it's not build your own thing into the AOSP or the bastard-eyed AOSP into your Things. So as I said, the sources aren't available, but you can get essentially images for a bunch of boards. So there are some from the Raspberry Pi. There are some for the Edison and two other boards as well. I've tried really hard to get it to work on the Raspberry Pi, and it kind of works, except I can't shell into it, so this is pretty useless. So the trouble with the Raspberry Pi, and it's not Google's fault, is it doesn't have an OTG port. So you really have to follow the recipe they have there. Intel's done a pretty good job with the Edison here. I can just plug it off the USB OTG and get myself a shell and that kind of stuff. Okay, really quickly, since all of you have experienced with this stuff, we're gonna go really fast here. Gray stuff is in C, other color things is not in C. So in a classic embedded Linux system, I got a Linux kernel, a C library, some stuff in user space, mainly Busybox. Android looks a bit more like something like this, completely different from what you may know of other operating systems based on Linux. Linux kernel, native layer, and then the bulk of the intelligence is in this stuff called the system services, and they have, in modern day androids, about 100 or so system services, they keep adding half a dozen, say, every release or something like that. And so any intelligence that goes on in the system really happens in those system services. This is not the canonical diagram that you will find from Google. This is what I discovered by looking at the sources and I feel pretty confident that's what it looks like, but you might have different opinions. So that's your standard stack here. Your applications are running in between your applications and your hardware, you have about seven or eight different layers of software that are being crossed, say, for example, you try to get the sensors or camera or whatever. If you zigzag all through this, you're going through a lot of software, okay? And that's what they, as I'll show you in a bit, had taken away with Brillo. Now, one of the key things to Android, and I'm not gonna go through this one in detail, you can watch some of my videos online, is the binder mechanism. It's the IPC mechanism that holds Android together. It's essentially a driver that's in the kernel that does IPC, think of it in the sockets, but essentially for local use only, all right? You have a name resolution service that keeps all the glue together. And the best way to look at this is actually look at a real live device. So let me show you what I've got, say, on my Nexus 9. So we've got this tool that's on our GitHub. You can go grab this. It's open source. We call this binder explorer. And what it does is it shows you all the system services on the periphery here and the actual applications in the middle. And the lines are actually the communication between the apps and the system services. So for example, I can hover over, say, I don't know, the window manager and see who's trying to talk to it, right? And then I can click on the window manager and even get the interface for that actual system service. That's the AIDL in case you're familiar with Android. So as you can see, there's a vast amount of stuff happening here. And so, for example, this guy here is the service manager, which is the name resolution service. So it's connected to everybody, okay? So this is the best we've been able to come up with to give a snapshot or a bird's eye view of, hey, what does my Android system look like? All right, what's in here? What's happening, okay? And conversely, you can click on any of those apps and see who they're talking to and that kind of stuff, all right? So the system services that you see here, okay? There are about 100 or so, all right? They are essentially running in a handful of processes. There isn't a process per system service. They happen to be, say, the system server process, service flinger, and a bunch of other guys. And that really hasn't changed in, say, Brillo and so on. Another key property of Android is this concept of a HAL, hardware abstraction layer. They shove a bunch of stuff in user space. They had it away from, yeah, whatever, from the kernel, so to speak. And then, essentially, the system services use those HALs to talk to hardware. That, again, is the same for, you know, Brillo and Android things and so on, okay? So far so good? Not going too fast? All right, okay. Cool, so what does Brillo do? First off, Brillo actually comes off of work that had been done by, apparently, some people in the Chrome OS team. Because it was, in the beginning, it was really, really, really heavily tied to D-Bus. The IPC was D-Bus and everything was going over D-Bus, all right? Eventually, they scrapped that and they moved it over to Binder. And the one thing they did, which I thought was really cool, was they actually added, so who's, if you ever used the AIDL tool to generate Java from AIDL descriptions, in the older days, it could just generate Java. And if you wanted to do C system services or C++ system services, you had to go and craft the AIDL stuff by hand to marshal the, you know, do switch cases and stuff like that. And so what the Brillo guys did is they actually added support for taking AIDL files and generating C++ code. And that's really cool. And that's actually in seven, I think, in the sources. So what Brillo did is it actually did away with everything, all right? The entire stack. And your apps were sitting essentially literally on top of the native layer. That's all you had, okay? And what Weave does or did was essentially allow your device to be connected through the cloud to, you know, applications that were talking Weave, all right? And so you can get notifications straight from the device or through the cloud or whatever it is, okay? And there are plenty of pointers in my press presentations if you wanna see the protocols of how that stuff works and so on and so forth. The sources, the way it was laid out is when you wanted to get the sources on, there was a manifest file, but it was a different manifest file from Android and it was trimmed down. So what you would get was just these directories, which is a whole lot less than what you would get in standard Android. So stuff that was removed was example like art, you know, all the Java stuff. All the Java stuff was completely gone, all right? SDK had gone, so on and so forth. And if you'd looked at external, this is the stuff that they had removed from the AOSP. I mean, everything that's Java related was gone, all right? So there was just no Java environment whatsoever. And in external, they added a handful of things. Again, you know, you can see the traces of Chrome kind of being around. And the fact that Chrome also uses Gen2 to build, the Gen2 build system to build itself and so on and so forth. The interesting thing though, and that's really where I wanted to get to, is if you look at the size of the images, the Brillo image was about a 10th of the Android image. They're not equivalent architectures, okay, whatever, I'm cheating a bit, but you get the general idea here, okay? The Brillo image was about, you know, 160 megs or so compared to, say, 1.x gigs for an actual system for the AOSP. And that's pretty considerable, all right? And what I liked personally about Brillo is not, I mean, okay, so there's one thing I want to make clear here is, personally, I am looking at what Google's doing with this IoT stuff in a very selfish way. So I don't care about what their market goals are, but I wish them best of luck. I mean, they're a really nice company and they're doing really cool stuff, but I'm looking at this from the perspective as, okay, I'm not necessarily looking for the branding. I don't really care being part of their ecosystem, but I really like to do embedded stuff and I want to see what I can use from what they're doing, okay? And so one thing I really liked about Brillo was that they gave me a standard embedded Linux distribution that I could use to build stuff on without having to actually specify libraries and recipes and stuff like that, okay? In terms of user space, if you looked and you shelled into the device, so that's in the background, what you've got is the traditional file system layout for Android and so they had stripped away, say for example, the apps and framework directories from the system, which are really kind of like the central thing where all the jars and apps are found and they had kind of put the RAM disk and the system image together, which usually they're kind of separate, okay? Kind of a bit of a detail. They had a whole bunch of daemons they added, so, and this is gonna be a bit tiny here, but I'm just gonna read out some of them. So they had this shill thing, which actually comes from Chrome. This is how Chrome kind of distracts the portals so that you can connect to the internet and that kind of stuff. And they had WeaveD and WebServeD, so the way it works essentially is you get a connection to the WebServeD, which hands it off to WeaveD and then hands it off to the applications. So in other words your REST API was being handled here and then hand it off to Weave, which would then dispatch it to whoever had requested handling for this kind of functionality or whatever for that device, okay? Right, which gets us to Android Things. So Android Things essentially just does away with most of what Brillo had taken away. It just brings a lot of it back. And the architecture is very much the same as we had before, except they've added a bunch of bells and whistles here and there to cater for the IoT nature of the system. Now we, okay, in the case of, oh, by the way, I'm sorry, I skipped one step. So just to give you an idea, remember this is my next nine, all right? And this is a Brillo instance, okay? So you still have system services, but it really is a lot smaller in terms of coverage of system services and such. This service manager is always there. It's intrinsic to Binder. If you stop service manager, there's nothing running on the system, so. All right, sorry, going back. So, how are we doing in time? Okay, I need to speed up a bit. Okay, so, right, so Weave is no longer in the file system. We've used to run straight off of the RC files in the case of, in the case of Brillo. And as the folks from Intel mentioned earlier this morning, essentially that's being moved out as a separate component. The site is still on. So in other words, if you go to the URL where Weave is, it doesn't redirect you to things. It still has the standalone Weave site. So that, for me, from my perspective, seems to be a still TBD in terms of releases and stuff like that. They still use essentially the same concept of HALs. You essentially have the inner studio platform, development platform, all that kind of stuff, and you may or may not use display, that's up to you. So I mentioned those two boards. There's also the jewel and the, the NXP board that's there. So the one thing that for me, from my embedded roots, really hurts my eyes is when I look at the RAM requirements for those boards. You know, it's like one gig of RAM. All right, three gigs of RAM. You know, another gig of RAM is like, oh my God, we're using this for embedded. So that's one thing that for me, you know, is at the forefront of my mind when I look at these kinds of efforts, when we're looking at actually using, you know, boards that have this kind of firepower for IoT capabilities. Now it's not to say that they're, that they don't have their place, they do, but what I'm trying to figure out is where, how do I bridge the gap here between something that is this powerful, okay? And needing something like this to just flip my lights on and off. I mean, that doesn't make much sense, all right? I mean, it is interesting for Google to put out examples that use this and breadboards to show people how they can blink lights and stuff, but I'm not deploying this all through my house to replace all my power, you know, just to flip lights on and off. That makes no sense at all, all right? There has to be something that goes in between and I'll get to that a bit later, all right? Okay, so what does things bring to the foreground? And so this is my earlier diagram with the bits and pieces that come from Google for Android Things. I'm gonna slow down here just a bit to kind of walk you through some of this stuff. The peripheral IO how? Whenever Google adds support for new kind of hardware, they add a definition for the how, all right? So if you're not familiar with this, let me just give you really quick introduction to this stuff. So actually, let's go for this. Let's make this bigger. And let me go into my, say, seven sources, okay? Flounder and, cool. So no apologies for those who use Vi, I'm an Emacs person. So if you go underneath hardware, lib hardware, include hardware, you've got all these header definitions. And any kind of hardware that you can think of that Android supports usually has a formal how definition in those headers that says the how module, which is de facto a SO file, has to provide these kinds of callbacks in order for the system services to be able to talk to the hardware. Now if I go back to my diagram here, the thing that you need to understand about Android is Android does not care about what driver you're using in the kernel for GPS. It literally doesn't care. It doesn't even know it's there. All it cares about is it found, you know, GPS dot foobar dot SO or whatever it is or any sort of, you know, how module that will then do the necessary talking to the actual driver underneath it, okay? So they've added, you know, a, sorry, going back to Emacs, wherever that is. There we go. They've added one for the peripheral layout, okay? Now the source is not being available. One wonders where we could get a version of that. So luckily a peripheral manager actually existed in Brillo as well. So you do have the sources for that snapshot, which is a bit dated, but it's still there. So if I go out here and go to, I'll just take this out of full screen and create a new window. Let's go to android.googlesource.com. So this is obviously, you know where the repositories are. I'm gonna go looking for peripheral manager. And so again, this is dated, so probably not where they're shipping right now into Android Things, but if you go underneath HAL hardware, peripheral IO dot H, this is the HAL definition for the peripheral IO, so to speak, module, all right? And if you go on the devices, so for example, I am shelled here or I am not actually shelled, but give me a second, I will be. ADB, let's do this. Clear, ADB devices. Oh, great. So I've used different server, those of you who've played around with Android know what's going on, but anyway, it doesn't really matter. All right, let's shelled back to this guy. So if I go, actually let's do this first. Root. All right, if I go to system lib hw, I've got myself a peripheral IO Edison dot SO, this is the Edison board here, okay? So that's the module that would be loaded by the peripheral manager to talk to the IO that's on that specific board. And you can actually see that by doing something really stupid here. You can do a look for peripheral manager, PID, do a cat proc 167 maps grep, say just hw, there you go. And you can see that the HAL module that we've got here is loaded in the address space of that process, which is the peripheral IO manager, which happens to be in C++ by the way. It's not actually in Java like other system services. So that's for, sorry, that's my HAL. The peripheral manager, I put it up there with the rest of the system services, but it is in C, it's not actually in Java. And then that system service has an EIDL which exposes its APIs and then there are classes that expose those APIs off to applications, all right? This is just that part here. Let me actually see if the highlighting works. No, it doesn't. Okay, let's try it this way. So this part here, that's just classic Android plumbing, okay, none of that is really revolutionary, okay? The interesting thing is they've replaced actually the bulk of the standard applications with this thing called IoT Launcher. In fact, there's an IoT Launcher APK. And that IoT Launcher is, again, I don't have the sources, but seems to be the party that actually starts off the default application, Android Things application that you would create which would have its own set of intents which are slightly different from the home application. They also have this, I mean, so looking at the right hand two boxes on the top there, they have this concept of user space drivers and also this peripheral driver library. And very honestly, I find this very confusing, like the distinction they're making here. So the idea is there are some system services who could benefit from input coming in from your custom hardware. So sensors, GPS, user input, okay? And so they have an API that allows your applications to feed events off to the system services like, okay, here's a GPS location, here's a key press, here's whatever, okay? But they also have in user space, this thing they call a library, which if you've ever used any capes on these boards or any kind of like whatever, like you plug them in LCD off to Arduino, right? The way to control those LCDs or buttons or so on, it can be involved. So what they did is they wrapped around some of the stuff or some of these components into libraries and then you can call into that once you plug it into the board instead of actually having to manually say manage the LCD panel. And they've called this a peripheral driver library and they have examples of that on GitHub. But from my perspective, that's still a user space library. So whatever, there's some kind of name confusion there going on. Any questions thus far? We're good, all right. In terms of image sizes, so bringing back some of the stuff I had before and adding say the Raspberry Pi and Edison images, we're not in the realm of Brillo, which was, as I said earlier, about 160 megs. We are say two 2.5 times that size, but we're still not in the one point X gig range. So we've trimmed down the size quite a bit still, maybe a third of the original image size in terms of storage, okay? Which is not too bad. I mean, keep in mind that you've got the full AOSP underneath your feet here, okay? This is the full thing. It's not this trimmed down image with just a bunch of native libraries. Okay, as I said, the user space is mostly the same. In fact, if we just go back to my Edison here for a second, let me just give you a really quick tour here. If I go to the top level, this is actually, let's do this. So this is my, you know, OCD playing. There we go. Okay, so the file system layout, pretty much the same as a standard AOSP. If I would challenge it in AOSP, I would find pretty much the same kind of stuff, right? You need to get prop, you get all the properties. I mean, the layout is pretty much the same, okay? I'm not gonna waste your time walking you through the details of how Android works, but that's pretty much what you've got. So you've got here, you know, product name, model. Interestingly, this is marked out as, I believe, 7.0. So this is an actually 7.0-based tree. So presumably they will merge that back either in 7.0 or 8X, I don't know. I have no idea. What else do I wanna say here? Yeah, okay, if you look at the list of processes for a second, sorry. So most of the stuff that's here looks like Android. Too a few exceptions. So they have obviously the peripheral manager, which I mentioned before. You still have Surface Flanger in there, Audio Server and that kind of stuff. And some of the apps are there, but key ones are not. So there is no status bar application, all right? Although you still have, and although you still have a, or is it again? I believe I saw the settings app running here before. Okay, I can't see it anymore. I saw the settings app running, but the actual content, the settings content provider is not there anymore. What else do I wanna point out here? Yeah, this is the IoT launcher I mentioned to you, which is essentially the main starting point for Android things. Oh, sorry. So peripheral manager mentions, oh yeah, you can actually do a dump sys on the peripheral manager, which is not too bad. So if you're not familiar with dump sys, it's a way to actually get, so if I do the service list. So remember that binder explorer I showed you, which all showed you all those system services as a kind of like a Star Wars formation. You can do a service list and see them on the command line and the peripheral manager happens to be one of those. So if I do something like this, it's a periphery and it do, no, sorry, this will help. There we go. And if I do a dump sys on this guy here, that it will tell me the actual pins that are laid out for what kind of purpose. So GPIO, I square C and so on and so forth, which is not too bad. And if you use some of the traditional ones, if you do something like dump sys, GFX info, so you can see out here that actually almost nobody's got any surfaces. So these view root impulse would correspond to an actual activity and you'll see that they're mostly zero except, except, except, this is, so IoT launcher, which actually if you plug this into a monitor, you will see an actual display of, this is Android things and the key guard. I'm not sure why this is actually running a surface, but whatever. So the house I mentioned, the SO I mentioned. All right, the APIs. So if you go to the things web address, you will find the actual APIs that they have available for developers. So I'm not sure whether you can see this pretty clearly in the back, but you know, GPIO, I square C, PWM, so on and so forth. Cool. And this is the user driver classes which correspond to the user driver box that I had in my earlier diagram. All righty. Oh yeah, there was one thing I wanted to kind of show you around, I think, oh no, I got it down further down, there we go. I told you about IoT launcher, so IoT launcher interestingly, if you do something like this, so where's my APK, I have this somewhere on my desktop, just give me a second here. So if I do this, and let's make it bigger. Things, binaries from Edison, so I've been playing around here. So if I do an AAPT, L, and then dash, oops. Why does he keep coming back to this guy? Ah, he's full screen, there we go. Off you go. Sorry, L dash, oh, he's full screen now, cool. Dash, A, I, O, T, launcher, APK. So this is essentially just dumping the manifest file of the APK. You'll see that it's still got category launcher and category home, so these are actually the intents that you would actually need to use to get yourself a home screen. So in other words, the stack, the internals of the system services, at least for the activity measures, it doesn't seem to have changed. The activity measures still sending the same intent as before, except it's being caught by IoT launcher instead of being caught by launcher X.APK, whatever that is, would be the default inside Android. If you look at the spec for how you write in Android Things app, you will see that actually they tell you to use a different actual launcher, it's IoT launcher, I think, is the intent to make your IoT application kick in. And I believe that it's probably that that does the actual sending of that IoT launcher intent, because if you do a strings from the GNU tool chain, and you look around for that in the ODEX file, because it's compiled, you will find that in there. Okay, so I mentioned SAS bar is gone, blah, blah, I showed you the GFX info, which gets me to the last part of my presentation, which is essentially, where is this IoT stuff taking us? Because as I said, this RAM stuff is pretty intensive, okay? So this might seem like a segue, but you'll see it comes back to the original topic. So this, once upon a time, I was involved in a modular phone project. So aside from being super cool, there were a few things that we did in ARA that are still very interesting, okay? So the architecture that ARA had was that you had a application processor. So this is like your bleeding edge, SOC, whatever it is, okay? Talking to a switch, all right? Two modules on the other side, okay? So this is the Unipro bus, and I'm not gonna delve into that, whatever you can look that up. Essentially, since the modern ASOCs do not talk Unipro, what we had was this thing called the AP bridge, and what it did is we would plug it into the USB, say, HSIC, and it would take that and convert it over to Unipro. And on the other side, a module would take, we'd have a GP bridge, which would take that traffic and convert it into I2C, PWM, GPIO, standard stuff, okay? That's the hardware side of it. And a module would look something like that. It would have an interface, which would have C ports, C ports are like sockets, so you could have a module with, say, a camera and storage, and that would have its own interface, and the other thing would have another interface, and that kind of stuff, all right? The software architecture, at least initially, looked something like this. So on the Android side, we had these HALs, we had these user line drivers. Talking through the kernel off to modules on the other side, okay? All of it layered on top of the hardware, which I just mentioned a second ago, all right? Out of this work came Graybus, all right? Which has been merged, last I checked, I think. And so what does Graybus do? So Graybus does two things. First, it defines, essentially, class drivers, and this is like USB. If you're a USB storage device, it doesn't really matter what you are, and so far as you conform to USB storage, the USB storage driver can talk to you, right? Same concept here for Graybus. If you are a Graybus conformant camera, you would be able to talk to that camera no matter what the module, theoretically, was, okay? And it also had, interestingly, interestingly, this, bridged five protocols. So in other words, you could have an application on Android talking I square C straight off to the I square C bus on the other side of the module, right? And the stack was none the wiser. It was all tunneled over Graybus, okay? Which gave us something a bit like this. So, and this actually is, I'm stealing this from Greg Cage. So essentially, if I was trying to talk I square C, all right, I would go into the I square C subsystems, sorry, which would be tunneled over the Graybus core, going to the AP bridge host controller off to the USB subsystems, because we're tunneling Unipro over USB in that design, and this goes off to the actual module on the other side, all right? On the software side, the, and these are all public slides that I had in my previous presentation, so none of this is really confidential. If you were trying to talk to an I square C device, you would talk to the I square C manager. You would get yourself essentially a link to that thing and off it would go, all right? So how does that have anything to do with Android things? So this brings me to this presentation by Alexandre Bayon at ELC Berlin last fall, okay? So I strongly encourage you to look this up. I mean, is this, I mean, okay, no offense to anybody doing presentations at conferences, but I go to a lot of conferences and they're very, very often it's stuff that I've seen before. In this case it was like, wow, that's really neat. I've not seen this before. So what Alexandre set out to do is to actually take Graybus and remove the Unipro stuff and put essentially just IoT underneath it, okay? And so I'm stealing this slide from his presentation. So the way he laid it out was to essentially have, you know, this is your say, Linux host, all right? Talking over BLE to some microcontroller on the other side that is Graybus enabled, all right? And in that fashion, right? The Graybus tunneling capabilities make it such that I can control something that is remote, right? Straight from my Graybus host, okay? And what I personally would like to see is something like this where essentially you've got your Android things layered on top of Graybus on a, you know, phone grade hardware kind of device talking to MCU enabled devices that are all talking Graybus because that would be really cool, all right? And that would do way with my, you know, kind of knee-jurking reaction of, oh my God, I've got a gig of RAM on this thing, right? So the gig of RAM becomes justifiable, right? Because this device here then becomes not only itself a IoT device, but it also becomes an IoT gateway. And then essentially I can use all of the Android Things APIs that are given to me and I can control these MCUs all over the place with the code that's running on this guy. All the other things that are connected to it only need to talk or speak Graybus, all right? And this is not too far-fetched. I mean, most of the groundwork has already been done by the Graybus stuff. So it's a matter of obviously, you know, making it, if nothing else, just getting a, say, Graybus stack on Zephyr or whatever else that you want to decide to put it on. But if you can pull this off, this can be very, very interesting, all right? And so this connects back to my, one of the first things I said about my interest in what Google does is, you know, is it's very much, you know, self-centered. Like, what could I do with this? You know, and this is one thing that I would definitely see myself doing because, you know, at some point in time, you know, okay, Google continues to maintain Android things, they will eventually use a kernel that has Graybus support inside of it. And then the question will be, okay, what if I turn that on and then have the stuff on the other side actually responding to this Graybus traffic? All right? So that's, so again, I encourage you to go look that presentation up, but that's pretty much my take on Android things. And if you have any questions, I'm more than happy to take them at this point. Yes, sir? How, what? Okay, so how would we fit into this picture? Okay, well, first of all, just one thing I want to correct. So the suggestion from Alexan was to use BLE. It could be anything from my perspective. You know, just imagine some kind of networking fabric. It doesn't really matter. But how does we've fit in all this? We've can still run on my Android things device. I mean, it's pretty cool, right? Whatever, it just, it can still talk, weave on the other side. And then on the device stuff, talk Graybus. I mean, that's perfectly fine. It doesn't really, I mean, the fact that my Graybus enabled MCU on the side here is not physically connected to this makes, should make no difference. And so far as this advertises that device over to whatever has to be advertised to. So, yes, perfectly, perfectly legitimate question. What about security? And so, we've had a lot of discussions about Graybus in general, in terms of security. But yes, this is something that you have to care for. But there are lightweight security mechanisms that can be deployed for, you know, I underneath, underneath, you would run, you would, so, okay, it's not the proper, you know, kind of comparison. But imagine you've got SSL underneath Graybus, right? Or, you know, some similar secure communication mechanism with your MCU enabled gizmo on the other side. Yes, sir? Yes, sir. Sorry? Lane C. Lane C. Yes, a lot of the stuff is time sensitive. I'm with you on that. You know, that was, that is definitely something that you would have to keep in mind in doing those things. But it's not, from my perspective, insurmountable if you've got the proper, you know, networking connection to your host. So, yes, there is a cost to pay for that. The devices would have to tolerate those, those Lane Cs or have the fast enough connection to deal with them. Okay, that's a very good question. And I would have hoped that Alexandre would have been here to answer that one. But so, the question is, you know, how lightweight is Graybus? Or how can you fit that onto an MCU? So, Alexandre actually looked into that a lot more than I have. So, I can't answer it directly to myself. Yes, sir? Sure. So, what's the adoption like for Android Things? Right now, it's a developer preview. So, they're really just looking for, and they kind of literally say in their documentation, you know, we're looking for early adopters, people that want to play with it. They're not yet ready to push it full, you know, full-fledged to developers. So, we can't really say today what the success will or will not be for that. Yeah. Well, they do, I mean, they do seem to, at least from the documentation I've been able to see, they do encourage vendors to get in touch with them and participate as a vendor. No, can you run Android Things on a random custom device? No, the only thing that Google puts out is images for specific boards, which are the ones I showed earlier. So, I can't take that and say run it on, I don't know, one of those ship $9 computers, right? That's not happening, because the sources aren't there. Sorry? The manufacturer has to have a BSP, right? I mean, you could play around with stuff, I mean, you could grab the images off of some of this stuff and repackage it with the custom-built sources of AOSP, but it's... Sorry? If you have a different hardware, you have to get in touch with them to participate as one of the vendors. As in Google, correct, yes. They do provide security, I mean, so the thing with IoT and the folks from Intel did a fun job at kind of explaining this a bit earlier The issue is the updates, right? I mean, you have millions of devices in the field. Somebody somewhere is gonna have to maintain them, and so Google actually seems to want to actually actively participate in making that happen, and then I think should be welcomed, generally speaking. Obviously, you can always take the angle of, oh, evil corporation can do bad stuff, but generally speaking, I think they're trying to take the responsible task of making sure devices are up to date. Yes, sir? Over here, they're growing things as well. Correct, so yeah, I mean, in my proposed layout here is the Android Things kind of acting as a hub. Yeah, so it could be acting dual purpose as an IoT gateway, and as well have stuff directly connected to it. I mean, this layout doesn't preclude me having hardware directly connected into this box, but the idea is this is a fairly powerful piece of machinery, right? Flipping lights on and off just with this directly, I mean, that's overkill, right? But if this thing was talking over to some kind of just really simple RF mechanism to turn my lights on and off with an MCU on the other side, that's a win. Possibly. Yes, sir? Correct, yes, totally. I mean, so this layout that I've got here doesn't actually require Android Things, but I think where really it becomes compelling is by the addition of Android Things, you get all these APIs that Google gives you, and that I think should not be discounted. So Gravis could be used and in fact, that was the purpose of Alexandra's presentation. You could use this as a general purpose IoT thing for controlling devices remotely, but you're still stuck with, okay, what's my API? Oh, yeah, please. I have a question, just stop for poking, thank you. Oh, thank you. All right, thanks folks and have a good end of conference.