 Hello. My name is Chris Simmons, and I'm a consultant in the UK and a trainer with the Linux Foundation. Today I'm going to talk to you about one of our courses, LF308, which is an introduction to embedded Android. The essence of the course is how to take Android and make it work on a typical embedded device. So we're going to take a couple of sections from the course so you get an idea of what it's about. OK, so let's get started. OK, so we're looking at using Android as an embedded operating system. First of all, Android itself then is designed by the guys at Google, and their focus is very narrowly on how to make the best possible mobile phone and tablet experience. So they've designed a thing that is designed for low power, slow speed CPUs, not very much RAM, flash memory, and so on. Another key ingredient, it has a touchscreen as the primary user interface. And for the application developer, the primary implementation language is Java. And finally, the whole thing is open source, which is very important to us. So that's regular Android. But what we really wanted to look at right now is how can we take that and make it work on a regular embedded device? So what do we mean by embedded Android? Android is, after all, basically an embedded operating system right from the very start. When we're talking about embedded Android in this context, we're really talking about using Android in places where, in the past, we would use regular embedded Linux. So embedded Android is Android being used outside of the smartphone and tablet area and used in a range of devices, which could be weighing scales, could be cameras, could be point of entry systems, could be a whole load of things. So why would you want to do this? What are the advantages? The key thing really is the familiarity of the system. From the user point of view, many millions of people are using Android devices. So the UI is familiar. People are happy with it. From the developer point of view, the APIs are well documented. They're available online. And there are many, many developers who know how to develop Android applications. And then from the developer's point of view, we have not only the well-known SDK and Eclipse tools, which again are available from online websites, but also from the lower level stuff, which is what we're really talking about here in this training session. We have tools like ADB and Fast Boot, which make developing and updating devices very easy. Add to that the fact that the Android operating system is very robust, it's well-designed. And finally, it is open source, which is crucial. We wouldn't be able to do this stuff if it wasn't. But there are some challenges when adapting Android to your new device. First of all, Android itself, the way it's put together, it's a monolithic system. OK, so there's some build options we'll look at later on. But essentially, what you get is what you get. Android is Android. Another problem is that the C library they're using, called Bionic, is not fully POSIX compliant. That makes it difficult to bring code in from outside and integrate it with the Android device. Also, the file system they're using, the file system layout they're using, is not fully FHS file system hierarchy specifically education compliant. And again, that makes it difficult to integrate code. And then there's some other nitty-gritty issues, like it doesn't handle ethernet particularly well, and the networking layer is its own particular thing. We're not going to go into that, but just be aware of that stuff. Final thing in this introductory section, a lot of people talk about using headless Android. In other words, can we take Android, strip out this display, and use it like that? The answer is yes, you can. It's not ideally suited for that. You need to do a little bit of work to make that happen. And I'm simply going to refer you to a project page here at cyborgstack.org. There's a whole load of information there. You can go and find out about it, if that's what you want to do. OK, so now we're going to look at how to create a device profile for using Android build system. So the situation here is you've got a new piece of hardware. You want to run Android on that hardware. It does the same kind of job that things like BuildRoot and Yocto do for regular embedded Linux. There is a fairly straightforward hierarchy. There is a subdirectory in the devices directory, one for the organization. And within that, there is a subdirectory for each product that organization builds. In the examples that follow, I'm using my-org for the organization and my-device for the device. Within that directory, there are five files that are essential. And I'm going to step through those fairly quickly. In the class, we go through these in much more detail. OK, the first one, the top level is a file called androidproducts.mk. In this example, we're just going to have a one-liner in here, which references the one product we are making. So we have product underscore make files equals local dear, my device. The next file we need to look at is the product make file. This does a couple of things. It defines the packages that are going to go into this product. And it defines some straightforward things like the name of the product. So in the example on the slide, call inherit-product to bring in a predefined set of packages. And in this case, we're bringing in a full underscore base.mk, which is the full Android definition. And then underneath that, we're bringing in our own customized set of packages, which are in device.mk. And then finally, we finish off by defining the name of the product and the model name. OK, the next one we need to look at, device.mk. This does a whole load of things. I'm just going to cover the very basic stuff we need to cover, the minimal stuff. And this allows us to define, again, more and more fine detail of what goes into our product. So we do that with product copy files, product packages, and so on and so forth. Product copy files. This allows us to define exactly which files are going to go into a product and exactly where they're going to go. And there's an example on the slide here. We're copying init.rc, which is a boot script. And we're putting that into the root of our target device. Next one, product underscore packages. This allows us to find a bunch of Android packages that will also be included. So typically, you'd use this to extend the definition with specific packages for your particular application. We're not covering packages in this little short intro. But if you look through the Android source code, dig out all the Android.mk files. And you'll find the name of the packages is defined in the local underscore module definition. There are a few hundred of them, but you can just do a find and a grab to locate that information. One other thing I want to look at within the device.mk, you can do product underscore property underscore overrides. This is a place where you get to define Android system properties, which define how Android behaves. And again, on the slide, we've got a couple of examples here, which are pretty common in this kind of thing. We have hw.noBattery, which says this device doesn't have a battery. And we have hwuiRenderDirtyRegions, which is a tweak which improves the GPU performance in this particular case. Next thing I need to tell you about, boardconfig.mk. Now, there's a lot of stuff that goes in here. I'm just going to cover, again, a few basic things just to get us up and running. Basically, we can use it to define what processor we have, what memory we're going to be using, and what flash images we're going to be using. So for example, for the CPU, you define what CPU architecture it is, which can be ArmyEBI, ArmyEBIV7A, x86. If it's an ARM Cortex-A processor, you probably want to add in the TLS register equals true thing. And likewise, if your processor has a neon co-processor, you can add in a further statement to enable that. And then finally, if it's multicore, you can have target CPU SMP equals true to say, this is indeed a multicore device. All of this stuff just modifies the way that the Android system is built and changes the runtime configuration to take advantage of all these things. And then I'm going to show you one more section which defines the system images that will be created and their format. So here, we're creating EXT4 format images. These will, in fact, end up ultimately on an SD card of a Beaglebone. And we define the sizes of those images in bytes. There are three images. There's the system partition, there's the user data partition, and there's the cache partition. And then the last one I want to look at is one called vendor-setup.sh. And this just has the one liner, add-lunch-combo, the name of the product, and then dash-enge. So that was an excerpt from LF308, Introduction to Embedded Android. And we look forward to seeing you in the course soon.