 OK, let's start the next lighting talk. Let's welcome Chris, speaking of Android on Raspberry Pi. OK, well, good afternoon. It's dark evening. And here's my talk about Raspberry Pi. So first question, who here has a Raspberry Pi? Yeah, almost everybody. Who here has a Raspberry Pi running Android? Two, three. Who would like to run Android on their Raspberry Pi? OK, that's what we're about. So let's go for it. So let's skip that. Little bit of information here about me. I'm a freelancer. I've been training and teaching Linux and Android for a long time. But the main question then is why? Why would you want to run Android on a Raspberry Pi? And from my point of view, my motivation is really educational. By doing this, I learn a lot about Android. So it's not to say that the end product is actually all that useful, although it could be, with a little effort. But for me, the journey is the important part. The destination is not so important. So it's a good testing ground. And it's fun. Yes, it really, really is fun, so long that you enjoy long hours sitting watching things compile. So more generally then, what do you need to run Android? So you need this bunch of things here. You need a processor that Android supports, which is basically ARM, x86, and MIPS in various variations. It needs to have support for a fairly recent version of Linux. So if you're looking at Android Pi, then that requires Linux 4.4, for example. You need a reasonable amount of RAM. You can just about run Android in half a gig, although a couple of gigs works better. And you need a gig of flash memory, again, ideally eight or 16 gigs works better. You need some kind of display. It doesn't really make that much sense to run Android without a display, although there are people who do that. But generally speaking, you need some kind of display. And talking about displays, you need some kind of video drivers. So you need support for OpenGLES for Android to work at all. And that tends to be the sticking point. And I'll address that later on. So kind of things you can use. These are a bunch of dev boards that I picked off my shelf late last week and took a photo of. So there's a Beaglebone there. There's a Raspberry Pi. There's a Dragonboard there, I think, and a few other bits and pieces. So these are the typical things that I use to run Android at various times. So why out of that bunch choose the Raspberry Pi? So the Raspberry Pi makes quite a good dev platform. It's well supported. It's easily obtainable. You can go and order it from Amazon or wherever else you like. It's cheap, which is a good thing. It's hackable. But mostly because it's there, it's capable of running Android so logically it should run Android. So that's what we want to do. Hasn't this been done already? Well, yes, obviously. So I know it's the first person to want to do this. I just want to go through a little bit. I'll go back, it's going to be echoey. I just want to go through some of these things on this slide. So probably the most important one is the top one, the Android RPI project, which has been going for a few years now. And if you go look at the GitHub for that, you'll see it has been forked over 100 times. So that means there are at least a hundred different versions of Android running on Raspberry Pi. Next one, LinearJOS. So Consta has done a version of LinearJOS 15.1, running on Raspberry Pi. So some of that work is based on the Android RPI project, plus merging in, of course, the LinearJOS stuff. And what I'm going to show in the next few slides is kind of based on Consta's LinearJOS 15.1 version. Next on the list, so RT Android is another interesting one. So RT Android came out of a research project by Igor Kalkov. And the particular attribute of that was to run a real-time Linux kernel. So take Android, take RT, a real-time Linux kernel, you have real-time Android. And then he spun that off into a company that's now called Interior OS. And they have kind of commercially supported Android for Raspberry Pi. It's not open source, but there's a free version you can download if you so wish. And then last on the list, a little company called Google also do this. So Google have this thing called Android Things, which is their IoT version of Android. And one of their supported platforms is the Raspberry Pi. And as a result of that, actually, they did some work on the graphics. They did some work on this thing called Swift Shader, which is the graphic GPU that I'll be using. So if you want to go ahead and do this, what do you need? The main thing you need really is patience. Yeah, time and patience are the key requirements here, because you're going to end up building Android many times over. And if you've ever built Android from AOSP source code, you know it takes an hour, maybe two hours, depending on your hardware. So what follows then is kind of my interpretation of this. Now, the kind of reason I got into this is that I wanted, so I run training courses on how to pour Android to various things. And I wanted the platform to do this on, but it has to be running a current version of Android. So mostly what I've done is I've taken Consta's lineage 15.1, which is based on Android 8 Oreo. And I've updated that to run Android Pi. Hence, on the title slide, this is Raspberry Pi meets Android Pi. Things that tend to go wrong when doing this, or particular aspects of the Raspberry Pi. First of all, the graphics. We'll come back to that in a moment. Another little itty bitty thing which kind of is annoying is that the Raspberry Pi doesn't have a USB on the go port, which means that it doesn't support ADB particularly well. And if you are familiar at all with Android, you know that ADB is one of the key tools for developing Android. Yeah, this graphics thing then. So this is always a problem with mobile platforms. Most mobile platforms expect to require some kind of 3D acceleration of the graphics. But because of the complexities of the embedded GPU market, there is various amounts of support for the GPU. So generally speaking, what you end up doing is your first option is to take the OpenGL binaries from the vendor of the chip and hope they work. Unfortunately, Broadcom don't support Android, so there is no built-in support from them. So that doesn't work in this case. Another option is to use the soft GPU called Swift Shader. That should always work because that's purely software, but it's kind of slow. And then another option is to use the community open source MISA OpenGL libraries with DRM HW Composer. So HW Composer is the component in Android, which interfaces from Android to the video controller. And DRM HW Composer is a component which does that using the internal direct rendering manager support. So Swift Shader is kind of the simplest thing to do, and this is what I actually have currently in my Raspberry Pi Android implementation. So in this case, you build Swift Shader. It's part of the AUSP code base now. Although for various reasons, the one that's in AUSP isn't the best one, you really want to go upstream and get the latest Swift Shader. But plug it in, compile it. You end up with this bunch of libraries, libglesv1, libglesv2, Swift Shader. And it pretty much works. Or you can use the hardware-accelerated stack based on OpenGLAS. That uses a DRM HW Composer, and there's also a DRM Growlick component. And you'll also need DRM support for the video controller you have, which in the case of the Raspberry Pi is the VC4, the Video Core 4. That kind of works, except I couldn't actually get it to work in the last couple of days when I was trying this out, so I actually ended up using Swift Shader. And then the final thing is ADB. So ADB requires a USB port that is in peripheral mode, not in host mode. And usually it is done through the OTG hardware. Annoyingly, the chip itself, the Broadcom chip actually has an OTG port, but it's used internally within the Raspberry Pi to create the bridge to the ethernet and the actual USB host, so we can't actually use it. However, you can do ADB over ethernet. You use the ADBConnect command, and you can either put android.local, or you can give an actual IP address. If you know what the IP address of your device is, and then you do ADB shell, and hey, presto, you get a shell. So it kind of works, but it's a bit annoying. So currently what I have is this stuff here. So it's Android Pi 9 release 30. And there's a screenshot of my rig, as it was last Thursday. A little bit messy. Still, many things don't work. So don't expect this to be a fully working system, but it will improve over the next few months. This is a quick plug for myself. So I'm basically a freelancer. I work for myself. I do trading courses. I can tell you in much greater detail how to do this, not only for Raspberry Pi, but for other targets. Relevant links then. So the stuff I'm talking about is up on GitHub, as you can see there. The slides should be available on the FOSDEM website, but they're also on SlideShare. And if you want to contact me, directly go to tunet.co.uk. So we now have exactly two minutes. Does anybody have any questions? OK. Well, whatever. OK. Over there. Please wait for the mic. Do a little dance while you're waiting. Thank you very much for the talk. I was just wondering whether you have tried any QT applications on your port of Android to the Raspberry Pi. Have I tried QT on? No. Simple answer. No. Well, insofar as you can run QT on Android, it should just work. But I've not tried it. Anyone else? Right in the middle. The hardest possible place to be. Thank you very much for the great talk. I was just wondering, which are the recommended Raspberry Pi displays for this port of Android on Raspberry Pi? This place with touchscreen for Raspberry Pi? Well, I didn't put it on slide. I just use a cheap, the cheapest possible 7-inch touchscreen. So that, I think, is from a company called Elcro. There's also one called Wave Share or something like that. Just go to Amazon and look for the cheapest HDMI touchscreen you can find. It probably will work. It should also work with the official, well, actually, not true. This particular version won't work with the official 7-inch touchscreen because I haven't actually tested it. But with a little tweaking here, it could be made to work quite easily. OK. I think we're out of time, but thank you very much. Thank you.