More Calligra Active on Android

As I posted the last time I blogged (which I really should do more often), I had some problems with Calligra Active on Android and the number of shared libraries it requires (various versions of android have different, but low, fixed maximums for the number of .so files that can be loaded in a single process). Since then I did several things to resolve that. One option would have been to go the "libkok" route, like we did when we developed/ported calligra/koffice to Maemo and the Nokia N900 and N9. There we basically rewrote the kdelibs cmake files to just build those files that we really need, and build it all into one big library. The big problem was that approach was that it was completely unmaintainable, which meant that we were basically stuck with whatever snapshot kdelibs version we chose to base that on. So instead of doing that I got out the CMake manual, and came up with some relatively simple cmake code that basically combines several existing targets into one new target. The downside to this is that it still has to build all the individual targets as well, so build times basically doubled, but other than that it gives me a nice "libkall.so" that contains all of kdelibs that Calligra Active depends on, combining 11 .so files into one. See here if you're interested in the CMake code I came up with. I did something similar for the libraries Calligra itself provides reducing the number of .so files even more. (I had some problems to combine the various kdelibs libraries together because of the way automoc works. Basically when you have several source files with the same filename but different directores they will overwrite eachothers .moc file if they are built in the same target. To get around that I renamed some files).

Besides libraries, plugins are another major contributor to the number of .so files. Combining these is a lot harder though since plugin entry points and things like that result in lots of symbol clashes. So instead of trying to work around that, for now I decided to just not include several sets of plugins that are not strictly necesary. In this case that means not including any filters (and thus my current Calligra Active build is limited to odf files, but then most filters didn't seem to quite work correctly yet anyway), and also not including the various spreadsheet function plugins. Most spreadsheet applications store the result of calculations in their ods files as well as the formula, so instead of recalculating everything we can just show those values.

So with that out of the way, I now have a version of Calligra Active for Android that should work on any android device with android version 2.2 and newer. However I only have a device with android 4.x, so for testing older versions I have used the emulator. I have managed to successfully run this version in a 2.2 emulator, however on actual devices running that version there unfortunately seems to be a problem while loading the combined kdelibs .so, giving a very unhelpfull dlopen error (dlopen on android 2.2 seems to only be capable of returning "file not found" regardless of what the actual linking problem was).

I invite people to try it out anyway. You can find my latest build at heap.kogmbh.net/mek/CalligraActive-debug.apk. There are a couple of issues with this that I'm already aware of. For one, Calligr Active was never designed with phone form factors in mind, therefore the entire UI doesn't really work/scale very well to these kinds of screen/resolutions. Secondly the 3 big buttons on the home screen currently don't do anything, since they depend on some kind of metadata/nepomuk/soprano like system afaik, which does not exist on Android, so currently I commented out all bits of qml that do anything for that (I probably should have also commented out the actual buttons). Also startup (especially the first time after installing) is very very slow. The first time you start Calligra Active it will unzip several megabytes of icons/plasma themes/other misc files, but also other startup code is pretty slow. When it actually has started performance should be pretty good (at least I hope, I've never tested it on less powerfull hardware). (sorry for the big wall of text)