 Thanks for coming to this talk. I know there's a really hard competition at the moment. And we will just close the door, and you can understand me better. OK, this talk is about KD Frameworks 5 on Android. If you wonder what this K5 means, I'm talking about the progress we did in the last two years, and also a lot about work in progress. I will start with a little bit talking about me and then giving a little bit of the talk as I'm directly starting with it. So my name is Andreas Katlanfair. You can find me at a lot of IRC channels with Nick and Kola. I'm within the KDE project since about six years. This spring, I finished my PhD in ad-lib game theory and network creation games. If you want to know more about that, you can ask me in the break. Since then, I started working at a class E system. That's a company that's doing these big, nice machines. And if the picture's not that good, but you can find me at the picture there in the cabin. It's a really nice, big thing. However, this talk is about my KDE involvement. So it's my KDE head on today. And I want to talk specifically about how can we deploy KDE Frameworks 5 on Android? How can we use them there? And probably also at the beginning, what are KDE Frameworks 5? Then I will give a high-level introduction. What do I mean with acute and Android application? And then I'm getting to the major main part of this talk about our approach, how to get the KDE Frameworks 5 there. How do we tool-chaining? How do we set up a build system? Or how do we provide an easy-to-use build system? The availability of frameworks and, of course, quality assurance and continuous integration. And then I will talk about what is on the plate right now. So KDE Frameworks 5, if you never heard about that, you could either ask David, the main tailor, or you will look at the websites, or I will try to explain to you. In the world some years ago, when we had still the KDE 4 times, we had this bit monolithic KDE Libs library. And then we started to split these libraries to parts that really fit a problem, or that really are problem-specific. So nowadays, we have a big set of libraries that address certain problems, like creating an archive, like getting more proxy models for a widget-based application or doing localization, like KIA 18N. Since these libraries might have dependencies with other KDE libraries, we introduced something we called tiers, which means all frameworks that I have tier on only depend on Qt and must not depend on any other framework. So for you, the message to take home is in an ordinary C++ application, you can take any tier one framework and use it. And you don't have a dependency to any other framework. That's awesome. And that extends you or your application with a certain functionality. And that was a really small footprint on memory and that stuff. These frameworks are available on, of course, Linux, Windows, Mac OS. We have monthly incremental releases, so you get patches really fast and you only get small changes with each release that's well-tested. Everything is LGPL 2 plus 1 plus license, so you could even use it in automotive. We have CMake as build system, but we also provide support people who want to use Qmake. So we ship pre and profiles. So in general, that's something that's a really interesting thing for any Q developer who has some problems like solving certain tasks and can simply take the library, put it into her application and get new functionality. These libraries are not only interesting on the old platforms, but also in the mobile world. That's why we are looking at Android. A typical Android application is within Java and in many cases there's probably no reason to use any C++ library and problems in such cases you shouldn't do it. But there are reasons when you really want to introduce and use a C++ library. That might be that you have a specific functionality that is already implemented in C++, well-tested, is really fast and you don't want to write this functionality again from scratch in another language, since you already have it. That's a very valid reason to use such a library that possibly brings business logics that you want to use again. Another reason that's mostly within the KDE project where we have applications or the small applications like in KDE Education that are well-fitted to be provided on Android devices, since that's really a possible target platform where you don't want to write the whole application from scratch. You want to only adapt it a little bit, possibly write a new UI that fits to a mobile device and then port it to it. And for that reason you need such libraries that you already depend on since you don't want to cut the functionality out, you want to port it. And that's the second main reason why we try to provide as many as possible frameworks on Android at least such frameworks that make sense on Android. And I hope you are now with me that it's reasonable to use, that there are reasonable use cases for frameworks 5 on Android. Before I go deeper into the talk, I want to give a small, really high-level understanding of what an Android, or what the Qt and Android application is. And it's probably not completely accurate, but it's enough to know what we're doing here. So from a really high-level Android application, simply this zip archive, this apk file that contains some Android-specific parts like a manifest file into it in a very defined folder structure. But that also can contain C++ libraries, so some shared libraries. And well, that's what we consider as an Android application. Where you have several layers, the center you have the Android part, the Java part, then you have possibly some C++ parts and somewhere there's also the Qt part. Creating such an application takes a lot of tooling, some tooling. There are three important tools for creating such an application, that's the SDK, the indicate, and the Qt and Android framework. The SDK is used for, I think, any Android application that has libraries, that has an emulator, that has a debugger, that has anything, any tooling to really create an Android application. That's not really interesting for us, we only use it. The more interesting stuff is the NDK, that's the native development kit. That provides us with the availability with the power to use C++ libraries. It gives us the tooling to use GCC and Clang. It gives us standard libraries that we need on such a platform. For example, a version of the standard C library, that is unfortunately only cut short version called Bionic and lacks a lot of functionality, but that's the version we need. And other basic libraries. And that's what we are usually operating on. So we have these NDK with the SysRoot, with a compiler tool chain. On top of that, we can compile our C++ libraries and applications that are then embedded into an Android application. And to make everything nicer to use, and also to embed Qt, there is a Qt and Android framework that on the one hand provides a platform extraction layer. So you can consider it like another box that you can draw around the picture I put at the right side. And that also provides interfaces to directly operate deeply with the Android corns. There's, that's called the Java native interface. And Bogdan Vatra, the founder of the Judo and Android initiative years back and still in the KDE project. We'll talk about that at Sunday. And I think that's really really deep interesting technical talk. So that's all I want to explain about what's roughly in Qt and Android application and going to the more interesting stuff of this talk. Namely how we try to provide frameworks for Android. And for that I want to talk about four topics. The tool chaining, the built environment, the availability, already the availability of frameworks and our plans for quality insurance. If you ever looked at Qt and Android, you know it's using Qt and Android. Wherever in the KDE community, we usually prefer CMake. And that's the reason why we start to look into a CMake tool chaining for creating Qt and Android applications. CMake has a built in mechanism for doing cross compilation. That's called a tool chain file. And such tool chain files define something like the compiler, the compile flex. So where the system root is with all the libraries you want to link to. And such a tool chain file, we are currently shipping with the extra CMake modules, which is released alongside with the frameworks file. It is a set of extra features for CMake that already gives your, well, nearly already completely set up system for doing a cross compilation for Android. For this tool chain file, you only have to set the path to the SDK, the NDK, and where Qt is found. And this tool chain finds it automatically defines for you the compiler, the linker flex, the linker, the linking libraries, and also adds a target to generate an APK file out of it. So if you only use our tool training file, everything should work. And well, I put the comments there that's usually all you need to do and also add the path to your source code. Then you already get your make target and can simply do make APK package and you have your APK file out of your application. And you can look up the documentation at that link below. And that's everything we need to use from our CMake and from the tool training. Of course, we have the alternatives where you use Qmake, where you use a really nifty Qt creator integration that we currently unfortunately still lack for CMake that would be really nice to see in KDevelop at one time, I think, or Qt creator possibly. But currently we are more living on the shale interfaces and doing a comment line code. The second point is we want to make it easy to start working on Qt and Android application. It usually takes a lot of time to download all these tools like Qt and Android, SDK and DK, install it as the correct path and also configure these things. And the SDK has a lot of stuff you can install and really put it as the correct places. And to make that easy, we simply introduce the Docker container to doing all of that. And using this Docker container is most simple. I put all four commands that you need that you need to use it on that slide. You need to clone a repository where you only find a Docker image file and a small set of scripts, such scripts that we use for setting up the SDK, a script for correctly extracting the Qt 5, well, we can use Qt 5.6, Qt 5.6 and Android, and installing it at the correct location. When you build a Docker image, you create it to use and then you log in and usually you also mount a local folder where you have your sources or external things or want to put your application later on. So just writing these four commands and you have a ready set up build system to do cross compilation. And to make life more easy, we already set the environment that all the paths are already set up. And we already configured KDSourceBuild, which is a nice utility wheels as a Canadian community to build packages from source. You can even use it to compile everything of KDE. You can use it and build arbitrary libraries and applications. We set it up in a way with a configuration file that you can build all frameworks that are all available on Android yet. And that's also already set up. So you create a stock image, you run this one liner and you have all available libraries already compiled. They're installed in a shared install folder and from there you can simply use it for your Android application. And I think that's already a nice way to start development. And I saw it from some people who recently looked at it that it's really easy to start. Whoever, we are still lacking a little bit of IDE integration. So what do we have today? Today, we know for several frameworks that they already work on Android. I parted them in, I think, three groups. First part, I said, well, they're solving basic tasks. For example, the Attica framework, which gives you a nice Qt API to talk to the open collaboration services. For example, something, say, we'll talk tomorrow in the store, KD store talk. And what you find nowadays at KDapps.org, I think, or com. So this open collaboration service AP from the, well, the face that you can simply use. The probably most used, at most requested from, I think, K archive that gives you a really nice, really good integration for extracting and packaging stuff. And with a lot of file formats, and well, it simply works. And it's used in so many applications and I think also many applications outside of the KDE project. We have a Kconfig, which is I think advanced version of Qt setting. It provides a different approach. And provides this really persistent, platform-independent app settings. K codex is coming more from the PIM people. People looking at different encodings, for example, at mails. And doing a lot of encoding conversions. If you ever encounter such problems, look at K codex and you have all of the box solution probably for you. K codex is something that's a property of most interest within the KDE community. Since it's already used in a lot of projects since, well, it gives convenience advanced Qt core. For other projects outside, it's probably always a question, do I want to rely on another framework? If yes, get a lot of nice functionality that you can simply use. It's always a question if it's, it's worth another dependency. K image formats, if you have a lot of image formats that you want to export from Q image, that there are more. And with that, we have a really nice, high-level multi-spending library that does job-based multi-spending. We have N, the localization area, of course, Ki18N, which is a get text-based translation system. And as I know from the localization people, in many regards, advanced to what Qt is offering. But I think that goes really deeply on which language you can localize in which way. And also for the scripting, especially the scripting is a really important part there. And we have K unit conversion, which allows the conversion of, well, different physical units, different unit systems, all boring stuff that you don't want to implement yourself. And I also added the box of Qt widget-based, or Qt widget extensions, which you probably won't need that often on Android application, maybe for the initial porting, but if you do a GUI for a touch system, you usually don't use Qt widget nowadays, but Qt quick. But in case you really want to use it, you get advanced to Qt GUI, you get item models, item views, so a lot of extensions to cases when you work with widgets, and also text completion such widgets. That is something we know that is available today. But only compiling is probably not enough or to know that anything compiles, we also need to know that it works. The first step of it is we need to completely integrate in our continuous integration. Of course, we have this kind of container approach, where we can simply run KD source build and we know everything still compiles. Whoever we want to get it into the CI system and we are really close to that. I think actually we set everything up that it should work now, whoever. After the last patch, the CI system broke in a way that our Jenkins Docker plug-in is not compatible with EAR. We have a problem with upstream for the Jenkins Docker integration. Hopefully it will be fixed soon, but okay, it will be soon fixed. But everything is in place and it should really not work. Actually, we are using the same Docker image we are using for our development. So we really share that and in that way we also ensure that the Docker image is working. If you look into it, you see another second user, next to this is KD Android user, named Jenkins user who we use for the Jenkins ones. The more pressing question is I think the unit testing frameworks and there we are also quite close. What we wanted to do with unit tests, of course we run them already on the other platforms, but we also want to run them on Android and that's a little bit harder than just running it on Linux, for example. Since we have to pack the unit test into an APK file, get all the startup information to know that there's an executable unit test that you want to run. Upload it into an emulator, trigger the start, store the output at some file and download it again from the emulator and finally look at what did we get out of it. That's a long one trip and we finally have all pieces together that, well, it was several lines of per script, but what we have in place now is that we are parsing the C-test output. It's probably not the best way. Hopefully later it will be in the toolshade directly that we get a nice make test target, but currently we are doing that way to really know that it's working. So we are parsing the C-test files, find out which tests do we have. For each test we create the necessary files, package the APK, upload it, run it, download it and well, hopefully it doesn't take too long and we get it. Unfortunately, everything with the emulators were taking some time and it is at least successfully tested with Attica. Well, the smallest framework was only one unit test. Another ones will probably follow next week during the Academy boss. That's so far what we have in place and that's where we have to do more, but I think we are in a really good position now. And yeah, that's what is currently mostly on the agenda. What I already said, I would like to see better CMake toolchain integration for unit testing. We are doing a lot of stuff twice since we are doing it on the one hand in the toolchain, on the other hand, we are doing it in my unit testing framework since it's, if I have to do this C-test integration, but I think we can, should achieve doing that also like in the toolchain, that we have an easier way to get this testing target. However, that's nice to have at the end of the point. The more important, the more major challenges are that we have to finish our CI integration and getting the unit tests automatically run and see that hopefully everything is green. I expect some tests probably to fail, whoever, due to our work on other platforms, I think the most problems should be solved by right now. Especially problems where you are missing files that must be included since we are, nowadays using a lot of cute resources that since we had such problems on other platforms. And now we probably get only the Android specific parts. There's a framework called Knewstuff that is a really high level framework to only upload and download new stuff, new cool stuff for your application like training data for an edu application or wallpapers or such stuff with a really nice convenient IPI and that is used in a lot of KD applications but which is I think a TSV framework that depends on a lot of other frameworks, especially also KIO, and that makes it really hard to provide an Android. Currently, there's an effort to split this framework into two frameworks. One is a core framework that does only, well, provide a nice interface, for example, for Qt Quick to integrate into application. Doesn't use KIO and makes it really simple to get the core functionality integrated into application and the widget stuff stays in another framework. With that, we hopefully will soon have a solution to catering that use case. And another really big issue is of course KIO since it will use a lot of debas and debas is an extreme problem on Android since we don't have debas and we won't get it but we only have other inter-process communication protocols namely there's Binder and Binder is using a completely different approach. Debas is roughly working like a network and sending tasks somewhere and they are getting to queues and they are processed. Binder is a function call. You call something and then the other process something happens. And so you see it's a really different approach and it will take a lot of effort to see if we can integrate such a mechanism really into KIO and I really didn't look into it yet and I think it will be hard if it will be possible. KIO does use debas but only for extra stuff like cookies and whatever, right? The actual communication between the application and the slave does not use debas it uses a local socket but even that is a problem on Android, isn't it? Yeah, yeah. Also socket communication is a problem here. I think that there are two steps. We first have to look at what to do about debas and second how to share this information that we exchanged there. But this might be an easier path than to, I mean, if binder is the way to having the process communication then you could first look at an alternative transport for the commands to the slave having binder instead of the local socket that is a much smaller problem because it's a set of well-defined commands which really look like function calls before you go and attack debas which is a lot more, right? We even generate code out of the debas interfaces and that's gonna be a much bigger problem whereas just the commands to the slave and the answer is just packets on the socket, right? Yeah. So that should be easier. I think it really gets the main priority once we have the CI system completely in place then that we have to look at that problem and see how to address it. Of course it would be even better if Q-local socket would use binder. Yeah. Okay, but I think I'm done with my talk. I think I have to rest of the time. No questions? Yeah. Anyone more questions? I think we have a lot of documentation as websites. There you can see a lot. You can find me as a next race and I think until Wednesday at the academy if you have any other questions and probably we'll also make a buff to talk a little about such issues probably also about the CI integration but there was still a question. Well, in the beginning was a specific application. I wanted to get articulated working on Android and that was two years ago. Yeah, you're welcome. And now I'm still stuck at getting Knew stuff working on Android. But once we have that I hopefully will see a articulate there. But that's a usual case. You want to, well, Android is providing us with a really big opportunity to get such a big audience that is not available online currently. And smartphone users are, to get some really easy to test stuff and to give fast feedback. And we already have some applications KDE that get big audience there. For example, Je Compris. So I think getting a really big audience that's awesome. Okay. I guess that's it. Thank you, Andrea. Okay. Thank you all for coming. Thank you.