 Yeah, hello again for the last time at least Yeah, if you have seen Ike's talk earlier today, you have seen that there's Probably a few things we need to look into and talk about regarding Our libraries and our frameworks on Android and this is what this is about Why do we care about Android? You can basically for one list all the arguments that Have been listed for KDE on Windows, right? It has a huge deployment base It isn't Somewhat alien somewhat hostile platform But if you really want to reach end users There's Not really a way around it and then another Reason to look at it at it Android is not only the This evil Google platform, but there is Variants like line hos that are basically Android without all the Google stuff. So that is probably the closest thing to a Real-world usable mobile phone platform that is close to what We would like to see from a privacy point of view And then of course Longer term looking towards plus my mobile It's a nice proving ground that is that exists today in which we can do application development and test our frameworks for mobile readiness Before we actually have I mean some of us do but not all of us have actual working plus my mobile phones And Why do we need frameworks on on Android? Well, we have stuff like Kirigami as you saw earlier today from Ikea that's a great tool to actually build a touch-friendly Mobile interfaces and another reason is The platform abstraction API is in cute don't cover everything we need One prominent example is notifications You don't really want to have Platform specific code for that in your application, right? That's why you use the frameworks for and KD frameworks have a bit broader API coverage there Then cute us And then thirdly we have a lot of existing application code And It is much easier to reuse that and bring it to mobile if we can use the same frameworks So Android is basically Linux right so this should be easy No There is quite some restrictions that the Android runtime puts on us like the the very strict sandboxing and bundling of applications And some additional Restrictions due to how cute on Android works so the The restriction to a single process is actually mostly coming from cute While all the sandboxing restrictions are coming from Android, so you can't just randomly access files in the system You can only see the stuff in your bundle. So there's also no IPC no D bus, right? Well, there's there's Android specific IPC, but there's no there's not our IPC like D bus We can't just install platform stuff like we like to do on Linux The platform API we have to work with is in Java Which is Fairly, I mean it can be integrated with C++, but that is a fairly cumbersome process Then I mean cute widgets work there, but you don't really want them there And the window management is completely different, right? You basically work with full-screen applications and The platform is very restrictive regarding how you can control what kind of window should be in the in the front so anything we have that makes assumptions about windowing or Influencing the window management is also not applicable there So What is the current status regarding our frameworks? So many of the functional tier one frameworks that don't really rely on platform specific stuff They just work So that's stuff like a archive config holidays translations codex that kind of stuff, right? and Then we have some that actually have platform specific code platform specific adaptions like Kirigami That integrates with the system back button and and that kind of stuff or a notification which has an actual Android notification back end So this is those are basically good to go Then we have some that That would make sense because the the feature is applicable to to Android devices but where we are Either missing a back-end implementation for that platform or Where the current structure of that module pulls in dependencies that don't exist there or that Pull in architecture that doesn't exist or is not applicable to Android So the the first set here I specifically added the DNS one for for Ikea after this morning Those basically they map very well to existing concepts, but we need a back-end implementation The second set especially KO and declarative They need to be probably a bit more There we need some more invasive changes and Can maybe only support a subset of the features like KO installed some some platform services That Is likely not applicable to to Android and then we have the The second set There is a large amount of frameworks that are very Widget specific and that are more or less designed for large-scale desktop application like XML GUI Most of them actually compile fine and Well kind of work in to the extent they can work And those are actually useful To have you don't want to use them for new applications But if you look for example at the port of ocular to Android That's still depending on a lot of those frameworks up there It's not actively using them, but it's those they haven't been entirely separated out of the core of ocular so having them available is enabling Ocular to be on Android already without a major refactoring in their code base So I see those kind of as the porting aids of existing application code to to Android Then we have a set of frameworks That basically make absolutely no sense at all because they refer to concepts technologies or things that That simply don't exist so this is D-Bus elements for example because there's no debuts K-Valent because there is no valent Global accelerators because there's no keyboard Then K out and the KDS you because there is no concept of a super user, right? So you can't get elevated privileges. So the entire infrastructure for that makes no sense KDD that would require a system service. We don't have that Notification configuration UI that is part of the platform. So we don't need that and so on And then we have the third set there Those are the frameworks where I'm not entirely sure yet. Yeah, what we want to do with them Purpose is probably the most interesting thing because Android has a Very extensive concept of intense which is very similar to purpose But purpose is also kind of the implementation of an intent system not just the abstraction of it And wallet is a similar case, right? So it's the abstraction API for secure password storage, but at the same time it is the implementation of a secure password storage service So those might need some some more separation And I think that is already one of the major challenges we have with this frameworks They often mix The platform abstraction API Anti-actual platform implementation because on Linux we need to do the platform implementation And then we have an API on top, right? but on some of the other platforms We might just need the abstraction and then a platform specific back end Another common problem is the the the mix of Core functionality or some kind of logic with UI error handling specifically based on Q message box so widget based error handling That is something we haven't been doing in a new API since quite a while But in the older stuff That still exists and that then pulls in widget dependencies for example I mean I could show this morning that our stack is comparatively lightweight And I looked at that in in KDE itinerary and there we could Further reduce the package size by 20% if we would get rid of the unused widget dependency That is just pulled in due to Some frameworks depending on it in a way that we can't disable at the moment So that's another thing where we can make some improvements And probably most importantly all of that Also is necessary for plasma mobile, right? We don't want to have a Q message box pop up on a plus my mobile phone either and We probably need to have different platform implementations Like there's a file dialogue rate on desktop that looks completely different than on mobile So we have to the same need for separating platform implementation and the abstraction API okay, so that is basically the the overview of the Current status I think And as I can mention this morning as well the if you are getting into this with a With the usual Linux mindset of how stuff is built and how stuff works You will run into a few interesting surprises and in the following slides. I tried to collect some of the things I run into and that That cost me much more time than than it should have to to understand and solve so maybe some of those things are useful for other people looking into Bringing stuff to Android as well Set up I'm I'm not going to go into a lot of detail for that Alish has written Quite a bit about this and documented it in in the wiki and built the the whole Docker environment That's also the binary factory is built around That's probably the easiest way to to get them a set up environment You will then probably encounter a number of version numbers in In documentation you read about that And that's basically three different version numbers relevant in the Android setup Two of them are the SDK and the NDK version Those don't really matter. You always want to use the latest one That has no impact on compatibility The one that is relevant for compatibility is the API level and that is fixed to 21 in frameworks Which gives us like 99% of the deployment base um for cute always try to use the latest version because there's still Fixes being added or features being added for very fundamental things like file. I owe So there's there's no point in staying on something older Right and then I mentioned Platform API is Java right so we need to look into how do I call from C++ into Java and how do I call back from? from Java into C++ and the keyword for that is the Java native interface or Gini and The cute Android extras module provides us with some some help or methods and some entry points to actually use that That is actually a quite ugly way to interact because it's Heavily string based and we have an example here. So That's the class you are calling the method pass on and that is the Specification of the signature of that method So writing that stuff by hand is super error prone and you only get Runtime crashes if you have a typo in there But that's how you apparently call into Java The other way around is even a bit more complicated On The Java side you can declare methods as native and then basically have no Implementation implementation for them and for those methods to work you register on the C++ side The method that should be called When the Java side calls into that native method and that again is based on the same weird Gini signatures that you have to do in a Specifier strings and then we just say your function pointer and Unpacked the arguments in there In general that is probably looking at an example somewhere copy and pasting it and Trying it a few times until you have fixed all the typos in In those strings. I mean, there's there's some Really evil tricks in here like the namespace separator is a slash while in the Java code you write. It's a dot so Just because yeah My most common mistake is I write a dot there because that's exactly what I just wrote a minute before in Java But no you have to do this with a slash here There's a prototype in KDI Generary code that replaces all of that with some C++ code that generates the strings at compile time So that's maybe something to look at at the Android both if we want to have that globally But to get started that is probably the kind of stuff you have to do this Yeah, then a bit more higher level Um file access right since we are in a sandbox The only files you can access like you are used to are the files that live within your sandbox so to standard path Stuff for your personal files that works anything system right doesn't What the for example the file dialogue gives you for those files system right is content URLs Starting with Qt 5 13 you can actually open them with Q file And they are essentially a local file anyway But the due to the isolation you can't look left and right to them you can't folder list the parent folder right so it's Just that one thing that you can access And While that works with Q file there is a number of other APIs that deal with files that aren't prepared yet for receiving a URL that should be treated like a local file Particularly the method is local file that you usually use to separate between I can open this with Q file Or I need to go to a network operation Will claim that's not a local file And then there's higher level of things like you say file I think that we fixed that in 5 13 one, but that was choking on that as well and there's probably more Where we'll run into problems with this So that's something to be aware of You get those weird URLs and you need to handle that in code dealing with fire names Another concept you will run into and that would probably fill an entire talk in itself is the concept of intense and The closest thing we have to that on on the next desktop Is the mechanism to open files right in on the desktop you we have this System that you configure for this file type I Preter is opening that PNG file right and then as an application I just point to the file and say please open that for viewing or editing and Intense is a basically a more generalized version of that So you also have an URL pointing to some form of file or object. You have a mime type and you have an action Open or edit or share right? So it's a more generalized version of that slightly simplified, but and that's How you interact with a lot of the platform services including things like The file dialogues Assuming you have written that nice Gini code and have your your Java code on the site How do we build that Java part as part of a framework and and how do we deploy that and there's basically two systems? One is the jar files. That's what Qt is using Those can be built directly with the Java support and CMake And then there is the Android archive or whatever that stands for IAR files That's what we are using in notifications Those are a bit more complicated to build because they can only be built with cradle, which is the Java Android build system And that has nothing to do with how we are Used to build systems. So this is a Rapper for the build system You need to copy in your source code and it then downloads the actual build system which then downloads 400 megabytes of stuff and Then maybe build something But that's how that's really how it is supposed to be used So now when do you pick any of those? The jar thing cannot have any dependencies and it cannot have any additional APK assets or Manifest fragments that you might need to ship with it like give the thing more permissions or set specific settings that Android needs So for very simple stuff like the the typical case in Qt the jar files are enough Once you have further Java dependencies Etc. Then we need the Android archives Fortunately, you don't have to deal with all these bizarre build system stuff We have a CMake wrapper currently living in in the notification repository that actually Finds the gradle stuff in Qt copies that over in your build directory. So you don't have to check that in and then Runs that and you have to hope that the download servers are available and then it can actually build something Because in terms of dependencies one thing you might need is the Android compatibility library so that you can support a larger set of Android APIs Assuming we actually have that built next step is deployment and the The key word for that is the Android deploy Qt tool That's what What generates the APK in the end and that needs to collect everything that that you need for your application and It actually has quite some Heuristics and logic in there to to determine that so it looks at library dependencies basically walking the if dependency tree and copy all of that in it looks at QML imports and Imports all the the QML modules you're using For non-code assets and QML files for your application you have to take care of that yourself So the easiest way to do that is put that in a QRC file And then deployment is easy If you're working on libraries and you have Java dependencies or Other unusual stuff that needs to be included There are the Android dependency XML files that you can put next to the library and that is evaluated by Android Apology Qt Undocumented format so copy and paste from some example in Qt And that's for example allows you to specify my library needs those plugins and yes, I know we are not supposed to use plugins and Then those get added as well Depending on whether their dependencies are available and so on Yeah, then let's considering the lack of time skip that for the Android both Yeah, so as we saw in in Hikers talk and There is quite some stuff we have to build Good and useful Android apps But there is still a lot of work to do to be done to complete The full coverage of all our frameworks And then to bring more applications to to Android And with kf6 coming up in the wake of Qt 6 right there is a few things that We might want to reconsider in the frameworks Such as a much stricter separation between platform API or platform abstraction API and platform implementation There's things like moving the QML bindings to their corresponding modules rather than collecting them in Katie collaborative Because then by now Katie collaborative has dependencies on stuff that we don't have an Android So I don't get to the QML bindings for example for core add-ons, which perfectly fine work on Android Right, so there might be some some restructuring and we need to review the Vigid dependencies Yeah, I think I barely made it in time Thank you All right, but we do have time for a couple of questions About Android Gradle plugins K declarative one I am planning to upstream your K Android extra stuff I just had a look and the UI handling would be very useful And there's also Q Android intent in Qt, which you now rewrote better Are you planning to upstream those things to Qt? Right what to do is that I think would be one topic for the For the Android both it might make sense to put that into Qt Android extras If that is desirable upstream It might make sense to have a K Android extras add-on framework for for this The stuff that's in there might not make sense at all right so that This was a some experimentation to get rid of the This heavy string based Super error prone genie thing with something that at least has some basic compile time checking But yeah, I would I was hoping to get some feedback during during academy on all of this makes sense How we can improve it and then where to put it? Yes The question has already been asked anything else Just one and then we'll be done Are you aware of the fact that Java has Methods that can be annotated native that way you don't necessarily need to do the evil C++ Hacker e2 register methods at runtime But you can use the Java tooling to generate the right headers for you and just implement those Yeah, I've I've looked at the Java age generator, right? I Couldn't get it to produce anything that was Well, not good enough, but was was remotely close to what I was needing So I probably was using this wrongly I mean, I'm I'm not an expert in this Java Android stuff, right? I had to look into that to get Katie. I generate to Android But yeah, that's exactly the kind of feedback. I'm hoping for so what can we do to improve this? If there's a way to to integrate that in the build system properly and and generate the headers that would be very welcome Yeah All right last one. I Was asking myself basically the same question as he was and I flipped into it and basically what Android does it adds a tiny layer of abstraction around the GNI stuff Which actually makes it less painful I think and I think this kind of abstraction that acute has doesn't really Match the the Java age stuff anymore from an abstraction level. So in these cases might not be applicable That wasn't really a question Nonetheless, thank you and thank you Volker for another interesting talk. Let's give Volker a hand