 So, hi, I'm Nico. I like to do KDE things and that includes bringing KDE software to Android and that's what I'm going to talk about today. But before we talk about Android, we need to talk about the topic we all love the most, the year of the Linux desktop. I have good news and I have bad news. The good news is the year of the Linux desktop will come. The bad news is it will be because Linux people will be the only ones left using desktop machines. Now, of course, that's a bit of an exaggeration. But I hope you all know where I'm coming from because over the last decade, more and more of our computing world moved to phones and other handheld devices. And the classical PC phone factor gets less and less important and that trend is only expected to continue. And to see why this is important for KDE, we actually need to take a look at KDE's mission. KDE's mission is stated as we envision a world in which everyone has control over their digital life and enjoys freedom and privacy. And in a world where our digital life to an increasing degree takes place on mobile devices, if we as a community don't provide solutions for the people to gain control over their life and enjoy this freedom and this privacy, then we as a community are failing our very mission. And I hope most of you know about Plasma Mobile and that it is the overarching goal of bringing KDE software onto a completely free phone operating system stack. But bringing our software to existing Android devices is an important stepping stone in that mission. So today I want to talk about first why do we actually care about Android because after all it's a competing product to Plasma Mobile. Where are we now on the road to supporting it? How hard is it to do? How is it done at all? And can we improve the process of doing it? So first of all, why do we care about Android? Android right now has over one billion users. I do not need to tell you how much more this is than we have at this point. And it also includes a very lot of us. And by bringing our own software that we like and we want to use to the devices we actually use in our daily lives, we enable the eat your own dog food testing that is so important for our way of development. And by bringing our software to this very, very, very large user base, we actually automatically increase our number of potential contributors. So first of all, where are we now in supporting Android? If you look at binary fact digit KD.org, you will see that we have nightly builds for 30 different KDE applications on Android. And those nightly builds are uploaded to a KDE owned after a repository which you can add on your phone and then you can install all of them. But it's mostly for testing purposes. So those things are not meant to be production ready. Seven of our apps are actually featured on Google Play, which is the main way of getting apps on Android. The most prominent one being KD Connect with users in the realms of hundreds of thousands. The other apps sadly don't really come to that. And three of our apps are on Afro, which is the go to store for free and open source software on Android, which includes KD Connect, she can pre and K trip. And as you see, we have way fewer apps in the stores than we actually could have. And bridging that gap is an important thing in light of our all about the app's goal. So the next question is how hard is it to do? The answer is, of course, it depends. But let's talk about on what it depends on. So thanks to the cross platform nature of Qt, it can be very easy to get an and get get a Qt at working on Android. But there are some things that make it hard to do. The major thing that makes it hard is, of course, mobile unfriendly design. If your application relies on a large screen and keyboard and mouse input and is in the response of a touch friendly, then you won't have fun using it on Android, even though you can compile it. And Qt widgets perform particularly bad in this regard, unless you really take care of it. Qt quick tends to perform a lot better with regards to touch input and these kind of stuff. But of course, you still need to think about the layout of your application to make it properly work on a mobile screen. Another thing that makes it hard is using D-Bus because D-Bus as a concept does not really exist on Android. The IPC mechanism that Android has are quite different. So using D-Bus and Android just doesn't make sense. The binary factory builds have a hack to get Qt D-Bus working on and or building on Android, but just forget it exists. It's not useful. Another problem can be applications assuming behaviors of G-Lipsy because Android uses Bionic, which is a different Lipsy implementation. And if your app tries to use features that are specific to G-Lipsy, then it's not going to work. Fortunately, at least in our software that's not really of an issue, but it can be in lower level components. What's also tricky is exotic build systems like hand-rolled bash scripts or make files that have no proper support for tool chains or cross-compiling. In general, things that you see make tend to work quite well. So again, our stuff is usually quite fine. And something else that can make it hard is apps that use complex multiprocess architectures like we see, for example, in KIO or in Akonadi. The way multiprocessing works for Android applications is again very different. So the concepts we see on the Linux desktop do not match there. So how is it actually done? It's actually quite easy. You just take CMake and call it with the right arguments. Done. Thanks for coming to my talk. Well, okay, if you get into the details, it is not that simple. So the rough overall steps are, first of all, you need an Android SDK and NDK. The SDK contains stuff like the basic Android system libraries and the tools you need to create applications. The NDK, the native development kit, contains stuff like the C++ compiler and tool chains and all of that. So you need that when using C++ code for Android. Then what you also need is a build of Qt for Android. You can even build that yourself if you have a lot of time. If you don't, then you can just use the officially provided binaries. Then what you need to do is build all of your app's dependencies for Android using the tool chain provided by the Android NDK. Unfortunately, there's not really a concept of package management here. So you actually need to do this sometimes tedious work of building all of your dependencies. Then of course, you need to actually build your application using the Android tool chain. And finally, there's a tool called Android deploy Qt, which you use to take your application, your dependencies, your assets and everything and create a final APK out of that. KDE does provide some tools to help here. For example, extra CMake modules contains a CMake tool chain file that you can use to build things for Android, which takes care of all the compiler setups. So you don't need to worry about that. And it also provides some wrapper around Android deploy Qt. So in the end, all you need to do is call make create dash APK. And if everything goes fine, you have an APK in the end that you can install on your phone. Setting the whole thing up to work properly can be quite tedious and error prone. So KDE provides a ready made environment to do that in the form of a Docker container. It's what powers the binary factory builds and you can also use it for local development, which is nice because you can one to one replicate the environment you see on the binary factory. Then code wise, Qt and the KDE frameworks abstract a lot of things so you don't need to worry about them. For example, K notifications provides a backend for Android. So you can have notifications on Linux and on Android without writing any platform specific code. And if you want to learn more about KDE frameworks on Android, I can only recommend focus talk from last year's academy. So let's say we have an application that already works on Linux and we want to bring it to Android. The first step is we need an Android manifest.xml You can kind of think of it like a desktop file in the sense that it contains application metadata like the name, a description, an icon and these kind of things. So what I usually do is I go to some other KDE Android project, copy the file, replace the names and put it in my project. I usually put it into an Android sub folder because quite often you will need extra files that are specific for Android and have them all in one place. Next, in order for the system to be able to find the entry point to your application, you need to declare your main method as exported, which you can do by putting Qdeckli export in front of it. And as a final first step, if you want your app to have a nice icon in the launcher, you need to put one in your Android sub folder slash resources slash drawable. So now your simple app hopefully will start up on Android, but you will see there are no icons anywhere. Where did they go? So the way we usually load icons on Linux is we load them from the icon theme with like Q icon, colon, colon from theme, but on Android that doesn't work because breeze icons isn't installed on the Android system. The solution here is we need to bundle all of the icons that we want to use in our APK, which we can do with the Kirigami package breeze icons macro, where you pass all the names of the icons you want to use in your application, and it takes care of including them. In order to be able to render them, you will need to include Qt SVG, which you can do by linking your application against the Qt 5, colon, colon SVG target. So what else might need to be done? In KDE, we really love to use plugin systems for everything. And they need some special care, because Android deploy Qt needs to know which plugins should be included inside the APK. And there is a solution for this, which you can see in the two code examples I have linked you here. Another thing that can go wrong is on the desktop, we sometimes rely on finding assets at runtime somewhere on our disk, which usually won't work on Android, because they don't get installed or we don't have access to the file system. And to work around this, you should consider shipping all the assets in your resources and access them from there, then it will work. Another tiny gotcha is that QStanerPath generic data location is usually not writable for your application, unless you request the user for permission to access the file system. So in that case, consider using QStanerPath's app data location instead. So Qt and KDE frameworks provide a lot of abstraction for common cases, but sometimes you don't get around to writing Android specific code. In CMake, you can do checks for this with if Android or if not Android, and then add your Android specific or Android exclusive code in there. In C++, you can achieve this by using a pre-processor directives with if QoS Android or the equivalent. And Qt Android extras provide some nice classes for some common things that you will encounter when dealing with Android, for example, permission management or things like launching new activities. But sometimes you don't get around to actually call into the Android system API to do some things where no wrapper for Qt exists. You can do this using the Java native interface, because the Android system APIs are all meant to be used from Java. And this can be quite painful. Fortunately, Qt Android extras provide some wrapper classes that make the over-process slightly less painful, but it's still quite ugly. So if you find yourself in the position of having a nice solution for potentially recurring problem in calling into the Android system API, then please consider upstreaming your solutions to KF5. Many people will thank you for that. Unfortunately, my talk is about to end. And there's a lot of topics that I don't have covered yet. So where can you learn more about this? Of course, the code is documentation enough. Well, I'm obviously joking, but there's some truth to it. I learned a lot of this by simply studying how our binary factory image works and how everything is set up. And I recommend you to do the same. Qt itself obviously provides some documentation on writing Qt applications for Android. We also have a page on the community toolkit that has some information, but it really needs some love and attention to be really good. And if you want to contact me or anyone working on bringing KDE software to Android, you can join us in the KDE-Android channel on Matrix. The last question I want to raise for today is, can we improve this process? Because it's simple in theory, but it can be tricky in the details. So what we need is better documentation for it and better tooling for it. Also, the aspect of distributing the apps, so getting them into Google Play and into Android at scale is still a thing that needs to be discussed. So I invite everything who is interested in that to have a booth sometime this week. I don't have a date or time yet. So if you're interested in this, hit me up and we will find a slot. Thank you for your attention. Thanks, Nicolas. Yeah, applause in the chat. And I think we have some questions. So I'll start going through them. Okay, are all of the apps on the binary factory in a releasable state or have releases? Unfortunately not. Some of them don't even build at this point on the binary factory. They just need someone to give them some care. Some are very proof of concept. So there's some obvious things missing like missing app icons that are really easy to fix. Some of them are quite okay. And there are some candidates that definitely are potential candidates for bringing them into these stores now. For example, Katie itinerary is one of the candidates where I think a proper store release should happen soon. I'm actually in the process of bringing it to fdroid right now. But unfortunately, not all of them are in this good state. Okay, the next person is thinking that maybe the solution is to have another app like a KDE app store. So you need only to get the people to install the one app, right? I don't think this is a solution because in our circle, fdroid is the go-to place for this kind of software. And we should stick to that. And I don't think having our own app store would improve the user experience in this regard. Okay, next question. How would you recommend handling background tasks like what a music player needs? I don't think there's a way around dealing with the proper Android API for that, which is like background task things. This might be a thing where we could have something in frameworks. There is not yet, but I would be interested in exploring that because we probably are going to end up needing similar concepts on Plasma Mobile. So if you're interested in that, talk to me. Yeah. And then would you recommend any in-depth guide or research in Satica, an Android tool chain in Qt Creator or KDevelop? Not really. As I mentioned, I learned most of the things, but just looking at how the binary factory works. And I was meaning to make a good write-up of that, but I haven't gotten around to do that, unfortunately. Okay. Is there documentation for the simplest test case? What's the link? Only Community Wiki. There is some instructions on how to get that done. I think it's community.kd.org slash Android. There you should find something. Okay. Next question. Should we try to incubate free open source software native Java apps into KDE? I'm not sure. I would say if there wasn't an app like that coming to us and asking to join KDE, I think we should welcome it. But from a technical point of view, a lot of the merits that KDE provides are because our apps share a lot with regard to their tech stack. And having an app that is completely different this regard cancels out some of the benefits that the KDE community brings. Okay. Now this is a longer one. Is the slash output path refactoring for APKs in the Android SDK is still going forward? And then we have using ECM to generate APKs directly instead of doing make and make create APK and potentially rebuilding stuff twice. So the refactoring I was doing this regard is done, I believe. I don't really understand the second part of the question. Because all that make create APK does is essentially calling Android to plug Qt with the red arguments. So I'm not sure what to do different there. There is some upstream Qt stuff happening in the last releases with regards to the the C make support of there and red stuff, which is worth exploring. But I haven't had a time to do that properly. Okay. We also had some questions about the correct room in IRC and Matrix, but someone is helpful with that and already answered in the shared notes. We have some time. So there was a question I skipped. Someone is asking about showing your brother. Well, come here to be us. Okay, that's the room. I think it's a native matrix room and I'm not sure it's even possible to access that from IRC as of right now, but I'm not sure on that.