 Thank you, Alison. Hello, everyone. We are going to look at how to package, release and deploy our applications on Android and specifically the recent work in that area. When talking about Android, I mean both the completely free software, Google-free variants like Line address, as well as the proprietary variants like most commonly the Google Android. From our application point of view, those two are essentially the same. We don't use any of the proprietary extensions anyway. What motivated that recent work is some of the problems that we have a number of our applications that actually work on Android and would provide value there, but they are simply not available. In parts, that is largely our problem because we don't have the situation like on Linux where we have distributors taking care of this. In this case, we are the distributor ourselves, which means we have to do all the work. That work is a bit more than just adding a tech in-kit. First of all, we need to build actual release packages. They need to be optimized for size because the target platform is mobile and size and transfer volume is constrained there. We need to build from release StarVolts to have the translations included. We end up bundling a whole lot of third-party dependencies, which means we have to look after their licenses as well as the licensing of our own software. We need to have our packages in the corresponding app stores as site loading on Android is disabled by default and heavily discouraged. You have to be in the app store to be available. In order to be in the app store, we need the application metadata, the logos, screenshots, translated description text, and all of that. If you're looking at all that list, remember that we have nine KDE releases a year, at least 12,000 mobile releases a year, times number of applications in parts, times of number of translations. That quickly gets out of hand, so we need to automate as much as possible of that in order for it to be sustainable. The current situation, where current refers to early April when I wrote the talk proposal, there is very few of our applications actually available on Android. For example, KDE Connect, Treta, and MGComfree, they all use their own custom solution for building, packaging, and distributing in parts because they have very special requirements, but in other parts simply due to the lack of a better solution. Next to that, we have the nightly build system on Binary Factory. So then we have about 25 apps that get daily builds based on the latest developments and have those put into a dedicated asteroid repository. That system is heavily optimized for low maintenance and the low barrier of entry. At the cost, there is very little there in terms of our ability to customize the packages. Dependencies are all to determine from the dependency metadata. There is no way to customize build flags or select which version or version of a dependency gets included. So that's not ideal for polished these packages. It is based on the Android Docker SDK that we also recommend for local development and using in parts the same tools. So that makes it very easy to use and the results you see locally are very, very similar to the results you see in that system, which also helps to work with it. And then if you look beyond Android, the standard solution we have for the other platforms there is crap. And then, of course, there is immediately the question, can we use that for Android as well? That will allow us to reuse all the existing package definitions and build instructions for pretty much all our applications. They are already present for Windows, MacOS, and Linux app image. And not just reuse that and sharing the entire build definitions going forward, which would be a big plus. Craft is also much more tuned towards building actual packages. So you have a lot more control over what exactly goes into the package. That starts with building from release tables. We get translations. You can apply patches to that if necessary. You can pin dependency versions. You have full control of all the build flags and so on. On the other hand, there is the problem that craft has no notion of cost compilation. And that is something we need for Android. We are not building on an Android system. We are building on, say, a Linux system for an Android target. And the other problem is that craft is used to decide itself what goes into the final package. And drive that process while on Android that is done by the application build system. About two months ago, we nevertheless managed to get that to work. By cheating a bit, we work around the cost compilation problem by assuming that everything that needs to be built for the host system, say, mock for Qt or config compiler for frameworks, are already present on the host system. And we can make that assumption because the Android Docker SDK image provides all the host tools already. So the only thing craft still needs to do is build for Android. And for that, we just pretend towards craft it is building on Android and behind its back implement that as cost compilation. So it doesn't even realize it's doing cost compilation. And that actually works quite well for any package that is using a standard build system that is largely transparent. And especially for our own stuff, the most you usually need to adjust is maybe three dependencies a little. On Android, you might not want to have a given dependency. But that is very straightforward. There is more fun to be had with dependencies that use their own custom build systems. But at least the crucial ones, so the dependencies of Qt and so on, they are already covered. And we have that deployed on binary factory alongside the existing system for the other platforms. And you can enable Android builds there for your application using exactly the same mechanism. So the enabled projects YAML file, you just put your project in there and then select which Android architectures you want to have covered. There's currently four of them supported, x86 and ARM, both in 32 and 64 bits. And then your package gets built and it's running through basically the same pipeline that we also have for the existing 90 build system, which means transferring the package to a secure system, getting it signed with the official KD key and then put into a separate FDroid repository for that. So you can immediately test the result in your phone. There's two build modes supported, release and likely. Release builds the latest release table and thus also gets you translations included. Nightly builds the latest development from Qt. That gives us the option to replace the old nightly build system with that system as well. That will have the advantage that we have unified everything on craft and we only have a single system to maintain. On the other hand, as I mentioned, the old system has the advantage of having a very low barrier of entry. That isn't the case on the same level for craft. So there is a bit more complexity to learn in order to get started with this. During the past days, we discussed ways to simplify this and to improve the documentation. So we might get to the point where we can actually replace the old system with the craft-based nightly builds as well. But that is still under discussion. Okay. So now we have the package built and it hopefully contains everything we need. That isn't good to go yet though. The problem is that while there's everything in there we need, there is actually quite a lot more than that in it. If you have ever looked at the nightly build packages we have so far, they are all quite large. So we need to turn them down. And as with any optimization problem, the first thing we need is a way to measure what we are changing. There's two useful tools for that in the Android SDK, the APK Analyzer Command Line Tool, and the corresponding UI for that in Android Studio. If you just open one APK in there, you get an overview on which parts contribute how much to the needed space. But more importantly, it's able to compare two different APKs of the same application and then you can nicely see how things changed if you applied some of the following mechanisms to it. And then we get to ways to actually optimize the content. And the first thing to look into is do not install anything you don't need. And that goes both for your application as well as for all of your dependencies. From an example, main pages might be nice to have on a Linux system. They are utterly useless in an APK. So look out for built options to exclude stuff like that. If a dependency doesn't provide them, consider adding them. And if it's about stuff that will never be useful on Android, and if not, Android conditional around the install commands might be good enough already. And that anything that isn't installed will never make it into the package. So that is the easiest way. The second thing to look at is do not link in stuff you don't need. And that also is something that goes both for your application and for your dependencies. And that is the common offender for that is Qt Widgets. That is a fairly large library. And it's something where a lot of other libraries have optional dependencies on. So just by being present, they end up linking against it. We have meanwhile addressed that for Qt SVG, for Qt Quick Controls, and for K Notification. That is common dependencies of our applications. Those will no longer drag in Qt Widgets. But you might encounter that in other dependencies. And then it's usually a smaller build system change to resolve that. Then the third part to look at is plugins. The way plugins end up in the package is that the build system looks at the Android dependencies XML files of all the libraries you link against. And those files can specify which plugins or which plugin types are supported by those libraries. And then all those plugins get pulled in. The common examples in there for things that you might not need are the QML tooling plugins, some of the more exotic image formats, and the biggest ones usually are additional Qt Quick Control styles. Especially the asset heavy ones based on images. Fusion, Imagine, and Universal. So excluding those is often useful. The way to do that is using the packaging options exclude list in your build.gradle file. If you do not have a build.gradle file in your application, there's actually a default one shipped with Qt that is being used. So copy that next to your Android manifest and adjust it. And finally, there is a similar exclusion mechanism for asset files. That is basically anything that goes into user share on Linux. So all kinds of data files. And anything you couldn't get rid of in step one, maybe because it's very application specific, is something you can handle here. Say translation catalogs for a dependency where you're sure you're not using the translated messages, then you could remove that in this way. I mean, translation catalogs are usually very small, but they multiply by many, many different languages. So that can be worse. A slight problem with that is that the asset ignore pattern, unlike the plugin ignore pattern, uses a very design limited syntax and needs to be squeezed in a single line. I have a link to a blog post on the last slide with some more details on that. And all that actually allows you to trim down the package quite a bit. As an example, KDE itinerary started around 40 megabytes before all of that without translations. And we are now scratching on 20 megabytes, including translations. There's still more room for improvement there, but that is quite reasonable already. Okay. So now we have the size optimized package. Now we need to get it into the store. And for that, we first need the application metadata. So that is translated descriptions, screenshots, logos, et cetera. The canonical source for that is the AppStream file that I think most of our applications have that are used for numerous other purposes already. The Android Toolchain in ECM comes with a script that can convert the AppStream file into the fast lane format, which is the format that the FTOID store is consuming directly and that the fast lane supply tool uses, which is the tool to talk to the Play Store automatically. You have the ability to customize the output by putting partial fast lane data into your repository. And then the script will just fill in the gaps of anything not specified there yet. So if you want to have different screenshots for Android, that is easily possible in this way, for example. And this is how the standard looks like. On the left, we have the FTOID app on the phone. On the right, we have the Google Play Store website. The screenshots are taken with an English language. If you switch the system language, you also get other translations there. On the FTOID site, you see this banner graphic that is something that isn't modeled in AppStream. So that is using this fast lane customization mechanism to get that into the metadata as well. And everything you see in there is coming through that automatic process. There's no manual entry there. This conversion runs both in local builds and on binary factories. So if you look on binary factory, you will see next to the APK also a zip file with the generated metadata. So if you want to fine-tune anything in there, you can inspect that both locally and on binary factory. Right. And then we need to get this into the AppStores. Let's first look at FTOID. So FTOID is actually less of a store and much more similar to what you might know from a Linux distribution. The app is more of a package manager and there are multiple repositories with the packages you can install and update from. There's official repository provided by FTOID itself and there can be arbitrary many third-party ones. Like I mentioned before, we have a few third-party FTOID repositories for all the binary factory output. Those you would need to add as a user manually though, so that is not ideal for discoverability. Better would be to be present in the main repository of FTOID. That, however, requires that FTOID builds the package themselves. They don't accept random binaries thrown at them, which makes sense from a security and reviewability and reproducibility point of view. Their system, however, is very much built around the usual Android technology stack, so the Java and Kotlin. If we show up there with 30 C++ libraries that need to be built for multiple architectures, that doesn't really work that well. Mico has managed to do it once for KTrip, but this is a very lengthy and painful process, so that still requires more work together with the FTOID people on streamlining this and finding a way how we can manage that more sustainably. As a stopgap measure, we might want to look into getting at least our release repository added by default to the FTOID client. Then as a user, you still need to set the checkbox to enable that, but at least you don't have to enter the long URL for that. And then we have the other store, Google Play, that has also its own pain points just in different places. So to get started here, you need a Google account and get that registered with the KDEV store account. That is something Alesh can help you with. And then you need to once go through the entire setup process manually. That involves filling in a bunch of forms. Most of them don't really apply to us. They are about to properly register for all the evil stuff you can do, but we don't want to scam someone out of their money or trick them into online gambling or whatnot. So this is usually just taking no, no, no, no, no on all the forms. This process, however, requires review and approval steps from Google, and that can take a day or two. So that process takes time, even if it doesn't take a whole lot of work. Once that is done and everything got approved, we have the ability to automatically interface with the Play store using the fast lane supply tool. This isn't deployed on Binary Factory yet. I have a working prototype for the metadata, but that still needs some work because currently it triggers a manual review of the image assets each time we run it, and that takes one or two days. And if we run that process every 24 hours, we end up with something that just spams Google and will never finish. So that needs a bit more clever scripting to detect if we have changes in the image assets. But the screenshots I showed you earlier, that is already fully filled just by the automatic interface. And that's nice because that means we get translations from the upstream data into the Play store fully automatic via Binary Factory eventually. And the second part to look at is automatically uploading the resulting APKs at least to the better channel on Play store. That's possible by the same mechanism, but that also still needs work in terms of automating it. The really unpleasant part is the next bit. Starting in August, the Play store is said to require AAP packages at least for new applications. And that has two problems. One is we have so far we can't build those packages, and that potentially requires larger changes to how we do that because they include all the different architectures, not just one. And we built them separately. And the second part is it requires handing over your signing key to Google. That's, of course, something we don't want to do for the existing one, as it would compromise the F thread repositories. On the other hand, you can't arbitrarily change signing keys because that will break updating existing installations. So that still needs some work in looking into. Yeah, there are a few more things to look into going forward. It will, of course, be nice to have more apps and application maintainers participate in this and find the new system. To some extent that has happened with the fellow browsers applying this to some of the past mobile apps. As I said, there is more we can look into for further minimizing the packages, full static builds, for example, or minifying the QML code. There is the whole discussion that we had in the past few days as well on the QA process and the QA process automation. That also applies to all other platforms. That's something that matters for Android as well, of course. For license compliance, there is some interesting work going on from the KDE EndLife people. They're working on extending K about data and all standard about dialogues to also cover third-party dependencies. That would go a long way in addressing that part. There is the crash reporting feature in the Play Store to look into. Usable crash reports would, of course, good to have, but that will require that we generate the corresponding symbol files and deliver them as well. Then finally, once we have polished release packages available, the question should they cost money in the Play Store? It's a similar discussion than what we had in the past days as well for the Microsoft Store on Windows. Only in the Play Store, of course, not in the free Afterword Store and in order to support the KDEB. If you're interested in a topic, we will have or will have had above last Tuesday. There is the KDE Android Matrix channel and mailing list that you might want to join. That's it. Do we have any questions? Yep, we do have questions. Hello, Volker. Thanks for your contribution. I guess that this topic is going to be very, very important for the near future. From the questions, first one is from Fabian. He's asking, have you tried to compile a custom Qt build with disabled feature? For example, dash no feature, quick controls to imagine instead of later removing files at the ground level? Yeah, we are doing this currently still very defensively. I mean, we are stripping out some of the Qt location back ends, for example, that way. We are probably also going to enable that for the quick control styles. The problem is that whatever we or that configuration is shared between all applications. So if we remove something that somebody relies on, that is a problem, right? We initially started with not even having Qt widgets, but that caused trouble for some apps that rely on Qt action, which in Qt 5 is still in Qt widget and only Qt 6 actually moves to Qt 3. So we had to bring Qt widget back. So it's a bit about finding the right balance on what can we do generically and which parts need to be per application. We also had the craft of yesterday where HANA had some good ideas on how we can move even more of that stuff to a generic level. And we'd use one more of the stuff that applications need to do individually. So that's certainly a goal, but it requires a bit of a balance. I see. Okay, the second question for now, there is just another question. Just if you attended the academy in the first part on Saturday and Sunday, you already know that you need to check the Qt widget in the chat room, in the chat room of the talk to be able to add questions. Or you can also, from time to time, the other chat moderator will link the place, the URL, so where you can add the questions if you have troubles with the widget. The second question is a bit not exactly technical, is where does the banner image, not the application icon on the Play Store come from? You mean this one? I mean, this one is, well, I color painted that together from the icon and the KDE icon and put that into the fast lane override folder. So that's injected in the metadata, as that's something that we don't have in AppStream. That is to my, I mean, Google Play wants that as well, but I haven't found where it's using that. So far, I've only seen it in FTOID. The image on Google Play is just a large version of the application icon. That actually also is, it needs to be a very large PNG, something that we don't have in our usual icons. So that might also be something that you actually need to specifically create for Android. But if you have an SVG icon, that is very easy to do. Okay. In the meantime, we have another question asking about making apps paid in the Play Store. Are you aware that once an app is made available free on the Play Store, you can change it to being paid or only by making a new entry? Yeah. As I said, this is an ongoing discussion on how we want to handle that at all. There are various possible ideas with having a free version and a for-pay version or having the pay as an additional upgrade. I also think we will end up experimenting with different models for the different apps and see what works. The monetization of this is a nice to have feature for getting more money into KDEV. But it's not something that is absolutely crucial that we need to get right from the beginning. But yeah, I'm aware that there's certain restrictions on the App Store and they keep changing and we need to work with this. Okay. Thanks. So I don't see other questions coming. So if you're interested, where can people find you? Apart from going back in time as someone was suggesting on the chat and go to the booth. Yeah. I think the best place for that is the KDE Android Matrix channel and the KDE Android mailing list. The people involved hang out. Thanks again for this effort. We're going to have a short break and we'll start in six minutes with the next speaker.