I recently had the pleasure of interviewing the man behind one of the most popular Android kernels ever, the Franco Kernel. Currently, the kernel is available on many different devices, including various Nexus & OnePlus devices and the Google Pixel / Pixel XL.
In this part, we talk about Francisco Franco's journey into kernel development and his opinion on the changes Android has undergone over the years.
I'm Adam Conway here on XDA to interview Francisco Franco, developer of the Franco Kernel! Do you want to introduce yourself?
Sure, my name is Francisco, as you just said, and I guess I've been on XDA for 1 million years already! Been doing all sorts of stuff. Kernels, apps, and lately I've been slacking a little bit more on kernels because it gets tiresome after a while, but I'm still full force on most of my devices.
Okay, so I guess lots of people would be familiar with your work, but a lot of people wouldn't be familiar with the actual person behind the work. So I guess really do you have any kind of past experience before kernels? Like any computer science degree or anything like that beforehand?
I've always been passionate about computers, as any kid while growing up I guess. After I turned 18 and I decided to go to university like everyone else, and I think I was taking computer science or something but after a year or so, I figured that not what I was actually passionate about. After that year my expectations were starting to drop low because it was all talk and no action, and I was starting to feel bored - not because I was better than anyone else, I was just average - but the actual disciplines weren’t exactly what I wanted. So I talked to my parents, and they were aware that I wasn't very happy in that. During the Christmas of 2010, I got my first Android phone. An LG P500, that's a budget phone, very cheap, but I knew it was running Linux, and my favorite discipline in university was computer architecture or something, operating systems. And we were learning a little bit of shell and talking a little bit about the Linux kernel, and what was part of the kernel and all the connectivity in the kernel, and the actual operating system, and that was fascinating for me. And then I started to rebuild the Linux kernel for my old laptop together with a friend. We crashed our laptops like 100 times doing that, but we learned through the process. And then I started to play with my LG, and I guess the first thing I did was trying to push a little bit more performance because that device was actually pretty crappy. So the best thing I could do was just go through the standard Linux kernel parameters for the actual memory management and stuff, and just try to find something a little bit better than what was already there. I had fun a little bit then.
I think I haven't told this before in previous interviews, but back then that device was using an old file system called YAFFS - that means Yet Another Flash File System, but it was pretty slow when we tried to mount like a RAM-backed swap disk so, I don’t remember specifics, but we did all sorts of different experiments with that and we ended up mounting the Dalvik on top of the memory RAM that had to be rebuilt every reboot because, as you know, RAM goes away every time we reboot. But it made opening applications and running benchmarks quite faster so we were happy. So after that, I started to go a little bit deeper, and try to compile LG's kernel sources for the device, and I made all sorts of bad judgments and all sorts of mistakes - Wi-Fi network, whatever - everything that you can possibly imagine from someone with no experience. This was fun, I learned a lot. I guess after a year or six months [of] doing that I was a little bit more focused, and I knew a little bit better what I had to get the downloads. That's what we all want at the end of the day. After that, I managed to get some donations and move up to other devices. I guess the Nexus S, then the Galaxy Nexus and then after that period, I managed to get my first app out. I guess I've been very fortunate and I've been able to finance myself buying new devices, and it blew up from there. So I guess at the end of the day I owe everything to, I wouldn’t say XDA but the platform that XDA provides us.
And the community kind of behind it and all that.
Yes yes, I mean the platform, that's the community and the actual forums. For anyone listening, this isn’t a paid sponsor or anything, I’m not being paid to say this, it's just true!
There’s no video, the people don’t see the gun being pointed at your head, it’s alright.
Hahaha, yeah but someone will say that I'm being paid to say this so I'll just say it! But yeah, yeah it's been a marvelous platform for me to build cool stuff, learn a lot, I've learned everything there by mostly doing mistakes and in learning I still do my fair share of problems. I destroyed my Xiaomi Redmi Note 3, uh, the bootloader is just destroyed. So I have to connect it again with my Windows computer that's sitting back there and have to reflash everything and it's been sitting here for like three months. I'm getting all sorts of hate from everyone that I'm not paying attention to that device, and so I still make [mistakes] I guess, so even after all these years there's still stuff to learn and I've been very fortunate to have been through this journey and it's been awesome.
Well, I guess seeing as you started with the... LG P500 was it?
Yeah, yeah.
How many years ago was that? Because that must have been around the original versions of Android right? Around Froyo or something?
Yeah, that shipped with Froyo and it was upgraded to Gingerbread couple months afterward. That device I think was 2010, beginning of 2011, probably earlier. I know my account on XDA was created in December 2010 but I had the device beforehand. So I guess probably around that time, yeah.
How has Android evolved performance wise since then? Like how has it changed for you writing kernels back then and writing them now? And I suppose what your opinions are on the changes.
Kernel wise, I think we have evolved with the actual Linux kernel and all the changes that the Android team actually wanted to implement for a certain Android release, so they dictate most of what special features the kernel will have, based on what they want to ship. But I guess actual performance, more cores actually help a lot because back then you didn't have any real way to move this thread (sic), or imagine network requests through a background thread, or at least actual real-time threading. I think that was the biggest change throughout the years, having more ways to spread out your work, and not have Android just slow down because everyone is trying to grab that little bit of CPU share. More than anything I think multi-core and actual real multi-threading backed by Linux. I thought that [was] the biggest change.
Ah okay, so what’s your opinion then on HMP vs EAS? Because obviously EAS is only new and only being used in a few devices -- like you use a Google Pixel right?
Yes, currently I am using a Galaxy S8, but I have a Pixel too. I don't know both in that [much] detail, they are just different implementations of how a multi-clustered device should act based on what's happening on the device at certain times. Running two different clusters with two different power consumptions, it's quite hard. You have to meet expectations of tasks moving up and down, and there's a latency involved in there and HMP was the first real implementation of a real multi-clustered architecture for ARM, because if I remember correctly, before HMP was in real-world usage, Samsung had an initial implementation where either you were using the first four cores, like low power cores, or four high-performance cores but they were never running at the same time. But then afterwards with the HMP the cores were ready to be used at any time and tasks just moved from one cluster to another and vice versa and that worked out, but you didn't have that much information from the scheduler to show this to the governor to actually decide what kind of frequency would be used at that specific time, so you had to deal with, like, trying to understand what happens in [about] 20 seconds and then based on what happened there, you decide what to do. EAS, it's more [about] understanding what's going to happen in the future and deciding in real time based on the power outputs of each core, and then it's a bunch of calculations and complicated things in the background
Like energy models and so on to back it all up.
Yes, I guess so, it's quite complicated, I don't know all the specifics I've read a bunch of documents but it's quite complicated and it's not just turning a switch on and having that ready to use. I get that question a lot can you implement EAS on XYZ phone. My replies are always “It's not turning a knob, it's not like that, it took a whole team of Googlers and guys from Linaro to implement that and you have to move stuff around, doing stuff, test stuff and that's just too much work and kind of going blind" and… yeah. It’s hard.
So you have to know exactly what you’re doing, it’s not a one man job kind of thing?
Yeah you have to know what you’re doing, anyone can pick the patches and merge them but actual testing and making sure it's working correctly and you would need a proper machine to detect the power usage of each component and there's a bunch of tables on the kernel where you can write the power of each core, and based on that the code will decide what to do. It's quite complicated. I don't think it's a definite solution for all the problems, but it's definitely the best we have right now.
So you see it as an improvement?
Yeah sure, miles miles miles away. It’s a definite improvement from HMP or any other architecture, because if you can understand what's going to happen in the future you can react much faster to any request or whatever is happening on the device, that's why the Google Pixel is so fast and so smooth, because everything is happening almost in real-time. It’s moving the frequencies up and down which is the easiest way to hit expectations of performance.
I guess with that then, if there’s more adoption in the future of EAS, how do you see that affecting your own development as regards kernels? Would you still stick with HMP or would you go with already released energy models? For example on the OnePlus 3, [ROM developers] are re-using the energy model from the Google Pixel for EAS. Could you see yourself doing something like that?
I probably won't do that, if the device doesn't ship with EAS to begin with then I probably won’t implement it in any way or form because as I said it's quite a lengthy process and no one in XDA knows better than all these engineers, so we are just trying to play God I guess.
On that note talking about the future with Android and kernels, what’s your opinion then on the recent Android Oreo release? Do you think the changes are good? Have you looked at any of the new kernel commits?
There weren't as many changes on the kernel side on the Nexus 6P and the Nexus 5X, just little fixes here and there. On the Google Pixel, they were iterating on the EAS implementation, and they spent some time improving the binder section, because now the binder, together with Project Treble, it's like splitting different packages, so they have to go through 50 or 100 different patches to improve the binder and get it separated into different processes. Other than that, it was just normal work for a big release. When there's a new platform release, you usually don’t mess with the kernel that much, because messing with the kernel you actually need a lot of QA, if you sometimes change one thing you hear it affects something in another subsystem. That's what they usually do, that's why you don't have a kernel version bump between platform upgrades. It is just a lot of work. Usually not worth it but yeah, it was mostly binder stuff, a little bit of the scheduler, and the usual security fixes. I went through them all, but nothing really caught my mind. My attention was only brought to the binder.
Ah okay, so just the standard stuff really.
Yeah, they're quite complicated and don't ask me for specifics!
This is an entirely different topic, what's your opinion on F2FS against ext4? Because you'd see a lot of people will say that F2FS is unstable and stuff and causes issues, I'm just kind of wondering what's your take on it.
I don't know either [about] specifics because file systems are quite hard, there are a lot of moving parts here and there. I'll just quote a Google engineer which says that based on their test, F2FS doesn't perform any faster than the ext4, and on top of that when they were testing stuff for the Google Pixel, F2FS didn't provide support for… I think it was file block encryption, while ext4 for supports it. So that alone means -- just scrap it. You have to think about two things, ext4 is being worked on for like 20 years with a lot of very smart engineers from different companies and they know what they're doing. F2FS was, if I remember correctly, implemented by Samsung. It's quite a new file system so things as complicated as these take time to improve and iterate, as you can see from the Apple file system that was just released on iOS, and they are going to do the same for Mac OS. Things take time, you need a huge team to do these things correctly. I'm a big supporter of “if it's working, don't touch it” and what we have right now -- it's working, and I don't think it gives you any performance problems so I don't see a reason to mess with it.
Ah okay, that’s fair enough! What about SDCardFS being switched to from FUSE? What would your opinion be on that?
That happened because the older FUSE file system was one of the worst things that happened on Android. The performance was horrible, there were a lot of system calls between the kernel and the user space and now with SDCardFS it’s done properly. It's a normal file system to deal with this, again I don’t know the specifics as it's a very complicated thing, but what I've read and seen and heard from different podcasts from the Android team is, it basically fixed all of the problems with the old system. That was quite horrible, performance was horrible.